Programa de Estudio - Probador Certificado de ISTQB® - V4.0 PDF

Probador Certificado de ISTQB® Programa de Estudio Nivel Básico Versión ES V01.01 Traducción realizada por Spanish Software Testing Qualifications Board con el apoyo de Hispanic America Software Testing Board Traducción del Programa de Estudio “ISTQB® Certified Tester - Foundation Level, Version V4.0” International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board Nota sobre Derechos de Propiedad Intelectual Nota sobre Derechos de Propiedad Intelectual (Copyright) © International Software Testing Qualifications Board (en adelante denominado ISTQB®). ISTQB® es una marca registrada del International Software Testing Qualifications Board. Nota sobre Derechos de Propiedad Intelectual (Copyright) © International 2023 los autores del programa de estudio de nivel básico v4.0: Renzo Cerquozzi, Wim Decoutere, Klaudia Dussa-Zieger, Jean-François Riverin, Arnika Hryszko, Martin Klonk, Michaël Pilaeten, Meile Posthuma, Stuart Reid, Eric Riou du Cosquer (presidente), Adam Roman, Lucjan Stapp, Stephanie Ulrich (vicepresidente), Eshraka Zakaria. Nota sobre Derechos de Propiedad Intelectual (Copyright) © International 2019 los autores de la actualización 2019 Klaus Olsen (presidente), Meile Posthuma y Stephanie Ulrich. Nota sobre Derechos de Propiedad Intelectual (Copyright) © International 2018 los autores de la actualización 2018 Klaus Olsen (presidente), Tauhida Parveen (vicepresidenta), Rex Black (director del proyecto), Debra Friedenberg, Matthias Hamburg, Judy McKay, Meile Posthuma, Hans Schaefer, Radoslaw Smilgin, Mike Smith, Steve Toms, Stephanie Ulrich, Marie Walsh y Eshraka Zakaria. Nota sobre Derechos de Propiedad Intelectual (Copyright) © International 2011 los autores para la actualización 2011 Thomas Müller (presidente), Debra Friedenberg, y el ISTQB WG Foundation Level. Nota sobre Derechos de Propiedad Intelectual (Copyright) © International 2010 los autores de la actualización 2010 Thomas Müller (presidente), Armin Beer, Martin Klonk y Rahul Verma. Nota sobre Derechos de Propiedad Intelectual (Copyright) © International 2007 los autores para la actualización 2007 Thomas Müller (presidente), Dorothy Graham, Debra Friedenberg y Erik van Veenendaal. Nota sobre Derechos de Propiedad Intelectual (Copyright) © International 2005 los autores Thomas Müller (presidente), Rex Black, Sigrid Eldh, Dorothy Graham, Klaus Olsen, Maaret Pyhäjärvi, Geoff Thompson y Erik van Veenendaal. Todos los derechos reservados. Por la presente, los autores ceden los derechos de autor al ISTQB®. Los autores (como actuales titulares de los derechos de autor) y el ISTQB® (como futuro titular de los derechos de autor) han acordado las siguientes condiciones de uso: Se podrán copiar extractos de este documento, para uso no comercial, siempre que se cite la fuente. Cualquier Proveedor de Formación Acreditado puede utilizar este programa de estudio como fuente para un curso de formación si los autores y el ISTQB® son reconocidos como fuente y propietarios de los derechos de autor del programa de estudio y siempre que cualquier anuncio de dicho curso de formación pueda mencionar el programa de estudio sólo después de haber recibido la acreditación oficial de los materiales de formación por parte de un Comité Miembro reconocido por el ISTQB®. Cualquier persona o grupo de personas puede utilizar este programa de estudio como fuente de artículos y libros, si los autores y el ISTQB® son reconocidos como la fuente y los propietarios de los derechos de autor del programa de estudio. Cualquier otro uso de este programa de estudio está prohibido sin la aprobación previa por escrito del ISTQB®. Cualquier Comité Miembro reconocido por el ISTQB® puede traducir este programa de estudio siempre y cuando reproduzca el mencionado Nota de Derechos de Propiedad Intelectual (Copyright) en la versión traducida del programa de estudio. Versión 4.0 Página 2 de 87 21 de abril de 2023 © International Software Testing Qualifications Board International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board Historial de Revisiones Versión Fecha Observaciones CTFL v4.0 21.04.2023 CTFL v4.0 – General release version CTFL v3.1.1 01.07.2021 CTFL v3.1.1 – Copyright and logo update CTFL v3.1 11.11.2019 CTFL v3.1 – Maintenance release with minor updates ISTQB 2018 27.04.2018 CTFL v3.0 – Candidate general release version ISTQB 2011 1.04.2011 CTFL Syllabus Maintenance Release ISTQB 2010 30.03.2010 CTFL Syllabus Maintenance Release ISTQB 2007 01.05.2007 CTFL Syllabus Maintenance Release ISTQB 2005 01.07.2005 Certified Tester Foundation Level Syllabus v1.0 ASQF Syllabus Foundation Level Version v2.2 “Lehrplan ASQF V2.2 07.2003 Grundlagen des Software-testens“ ISEB V2.0 25.02.1999 ISEB Software Testing Foundation Syllabus v2.0 Versión 4.0 Página 3 de 87 21 de abril de 2023 © International Software Testing Qualifications Board International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board Tabla de Contenidos Nota sobre Derechos de Propiedad Intelectual........................................................................................... 2 Historial de Revisiones............................................................................................................................... 3 Tabla de Contenidos................................................................................................................................... 4 Agradecimientos......................................................................................................................................... 7 Notas de la Versión en Idioma Español...................................................................................................... 9 0 Introducción...................................................................................................................................... 10 0.1 Objetivo de este Programa de Estudio.................................................................................... 10 0.2 El Nivel Básico de Probador Certificado en la Prueba de Software......................................... 10 0.3 Carrera Profesional para Probadores...................................................................................... 10 0.4 Resultados de Negocio............................................................................................................ 11 0.5 Objetivos de Aprendizaje y Niveles de Conocimiento Evaluables........................................... 11 0.6 El Examen de Certificación...................................................................................................... 12 0.7 Acreditación............................................................................................................................. 12 0.8 Tratamiento de Estándares...................................................................................................... 12 0.9 Actualización............................................................................................................................ 12 0.10 Nivel de Detalle........................................................................................................................ 12 0.11 Organización de este Programa de Estudio............................................................................ 13 1 Fundamentos del Proceso de Prueba - 180 minutos....................................................................... 14 1.1 ¿Qué es Probar?..................................................................................................................... 16 1.1.1 Objetivos de Prueba............................................................................................................ 16 1.1.2 Probar y Depurar................................................................................................................. 17 1.2 ¿Por qué es Necesario Probar?.............................................................................................. 18 1.2.1 Contribuciones de la prueba al éxito................................................................................... 18 1.2.2 Prueba y Aseguramiento de la Calidad (AC)....................................................................... 18 1.2.3 Errores, Defectos, Fallos y Causas Raíz............................................................................. 18 1.3 Principios de la Prueba............................................................................................................ 20 1.4 Actividades de Prueba, Productos de Prueba y Roles de Prueba........................................... 21 1.4.1 Actividades y Tareas de Prueba.......................................................................................... 21 1.4.2 El Proceso de Prueba en Contexto..................................................................................... 22 1.4.3 Productos de Prueba........................................................................................................... 23 1.4.4 Trazabilidad entre Bases de Prueba y Productos de Prueba.............................................. 24 1.4.5 Roles en la Prueba.............................................................................................................. 24 1.5 Competencias Esenciales y Buenas Prácticas de la Prueba................................................... 25 1.5.1 Competencias Genéricas Necesarias para Probar.............................................................. 25 1.5.2 Enfoque de Equipo Completo.............................................................................................. 25 1.5.3 Independencia de la Prueba................................................................................................ 26 2 Prueba a lo Largo del Ciclo de Vida de Desarrollo de Software - 130 minutos................................ 27 2.1 La Prueba en el Contexto de un Ciclo de Vida de Desarrollo de Software.............................. 29 2.1.1 Impacto del Ciclo de Vida de Desarrollo de Software en la Prueba.................................... 29 2.1.2 Ciclo de Vida de Desarrollo de Software y Buenas Prácticas de Prueba............................ 29 2.1.3 La Prueba como Impulsor del Desarrollo de Software........................................................ 30 2.1.4 DevOps y la Prueba............................................................................................................ 30 2.1.5 Enfoque “Desplazamiento a la Izquierda”............................................................................ 31 2.1.6 Retrospectivas y Mejora de Proceso................................................................................... 32 2.2 Niveles de Prueba y Tipos de Prueba...................................................................................... 33 2.2.1 Niveles de Prueba............................................................................................................... 33 2.2.2 Tipos de Prueba.................................................................................................................. 34 2.2.3 Prueba de Confirmación y Prueba de Regresión................................................................ 35 Versión 4.0 Página 4 de 87 21 de abril de 2023 © International Software Testing Qualifications Board International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board 2.3 Prueba de Mantenimiento........................................................................................................ 36 3 Prueba Estática - 80 minutos........................................................................................................... 37 3.1 Prueba Estática - Fundamentos.............................................................................................. 38 3.1.1 Productos de Trabajo Susceptibles de Ser Examinados Mediante Prueba Estática........... 38 3.1.2 Valor de la Prueba Estática................................................................................................. 38 3.1.3 Diferencias entre la Prueba Estática y la Prueba Dinámica................................................ 39 3.2 Retroalimentación y Proceso de Revisión............................................................................... 41 3.2.1 Beneficios de una Retroalimentación Temprana y Frecuente de los Implicados................ 41 3.2.2 Actividades del Proceso de Revisión................................................................................... 41 3.2.3 Roles y Responsabilidades en las Revisiones.................................................................... 42 3.2.4 Tipos de Revisión................................................................................................................ 42 3.2.5 Factores de Éxito de las Revisiones.................................................................................... 43 4 Análisis y Diseño de la Prueba - 390 minutos.................................................................................. 44 4.1 Introducción a las Técnicas de Prueba.................................................................................... 46 4.2 Técnicas de Prueba de Caja Negra......................................................................................... 47 4.2.1 Partición de Equivalencia.................................................................................................... 47 4.2.2 Análisis del Valor Frontera................................................................................................... 48 4.2.3 Prueba de Tabla de Decisión.............................................................................................. 48 4.2.4 Prueba de Transición de Estado......................................................................................... 49 4.3 Técnicas de Prueba de Caja Blanca........................................................................................ 51 4.3.1 Prueba de Sentencia y Cobertura de Sentencia.................................................................. 51 4.3.2 Prueba de Rama y Cobertura de Rama.............................................................................. 51 4.3.3 El valor de la Prueba de Caja Blanca.................................................................................. 51 4.4 Técnicas de Prueba Basadas en la Experiencia...................................................................... 53 4.4.1 Predicción de Errores.......................................................................................................... 53 4.4.2 Prueba Exploratoria............................................................................................................. 53 4.4.3 Prueba basada en Lista de Comprobación......................................................................... 54 4.5 Enfoques de Prueba Basados en la Colaboración.................................................................. 55 4.5.1 Redacción Colaborativa de Historias de Usuario................................................................ 55 4.5.2 Criterios de Aceptación....................................................................................................... 56 4.5.3 Desarrollo Guiado por Prueba de Aceptación (DGPA)........................................................ 56 5 Gestión de las Actividades de Prueba - 335 minutos....................................................................... 58 5.1 Planificación de la Prueba....................................................................................................... 60 5.1.1 Propósito y Contenido de un Plan de Prueba...................................................................... 60 5.1.2 Contribución del Probador a la planificación de la Iteración y de la Entrega....................... 60 5.1.3 Criterios de Entrada y Criterios de Salida............................................................................ 61 5.1.4 Técnicas de Estimación....................................................................................................... 61 5.1.5 Priorización de Casos de Prueba........................................................................................ 62 5.1.6 Pirámide de Prueba............................................................................................................. 63 5.1.7 Cuadrantes de Prueba........................................................................................................ 63 5.2 Gestión del Riesgo................................................................................................................... 65 5.2.1 Definición del Riesgo y Atributos del Riesgo....................................................................... 65 5.2.2 Riesgos de Proyecto y Riesgos de Producto....................................................................... 65 5.2.3 Análisis del Riesgo de Producto.......................................................................................... 66 5.2.4 Control del Riesgo de Producto........................................................................................... 66 5.3 Monitorización de la Prueba, Control de la Prueba y Compleción de la Prueba...................... 68 5.3.1 Métricas Utilizadas en la Prueba......................................................................................... 68 5.3.2 Propósito, Contenido y Audiencia de los Informes de Prueba............................................. 69 5.3.3 Comunicación del Estado de la Prueba............................................................................... 70 5.4 Gestión de la Configuración..................................................................................................... 71 5.5 Gestión de Defectos................................................................................................................ 72 6 Herramientas de Prueba - 20 minutos.............................................................................................. 73 Versión 4.0 Página 5 de 87 21 de abril de 2023 © International Software Testing Qualifications Board International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board 6.1 Herramientas de Apoyo a la Prueba........................................................................................ 74 6.2 Ventajas y Riesgos de la Automatización de la Prueba........................................................... 75 7 Referencias...................................................................................................................................... 77 6.3 Estándares............................................................................................................................... 77 6.4 Libros....................................................................................................................................... 77 6.5 Artículos y Páginas Web.......................................................................................................... 79 6.6 Libros y Artículos..................................................................................................................... 79 8 Apéndice A - Objetivos de Aprendizaje/Nivel Cognitivo de Conocimiento....................................... 81 9 Apéndice B - Matriz de Trazabilidad de los Resultados de Negocio con respecto a los Objetivos de Aprendizaje............................................................................................................................................... 82 Versión 4.0 Página 6 de 87 21 de abril de 2023 © International Software Testing Qualifications Board International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board Agradecimientos Este documento ha sido hecho público formalmente por la Asamblea General del ISTQB® el 21 de abril de 2023. Fue elaborado por un equipo del "ISTQB joint Foundation Level & Agile Working Groups": Laura Albert, Renzo Cerquozzi (vicepresidente), Wim Decoutere, Klaudia Dussa-Zieger, Chintaka Indikadahena, Arnika Hryszko, Martin Klonk, Kenji Onishi, Michaël Pilaeten (copresidente), Meile Posthuma, Gandhinee Rajkomar, Stuart Reid, Eric Riou du Cosquer (copresidente), Jean-François Riverin, Adam Roman, Lucjan Stapp, Stephanie Ulrich (vicepresidenta), Eshraka Zakaria. El equipo agradece a Stuart Reid, Patricia McQuaid y Leanne Howard su revisión técnica y al equipo revisor y a los Comités Miembro sus sugerencias y aportaciones. Las siguientes personas participaron en la revisión, aportando comentarios y votando este programa de estudio: Adam Roman, Adam Scierski, Ágota Horváth, Ainsley Rood, Ale Rebon Portillo, Alessandro Collino, Alexander Alexandrov, Amanda Logue, Ana Ochoa, André Baumann, André Verschelling, Andreas Spillner, Anna Miazek, Armin Born, Arnd Pehl, Arne Becher, Attila Gyúri, Attila Kovács, Beata Karpinska, Benjamin Timmermans, Blair Mo, Carsten Weise, Chinthaka Indikadahena, Chris Van Bael, Ciaran O'Leary, Claude Zhang, Cristina Sobrero, Dandan Zheng, Dani Almog, Daniel Säther, Daniel van der Zwan, Danilo Magli, Darvay Tamás Béla, Dawn Haynes, Dena Pauletti, Dénes Medzihradszky, Doris Dötzer, Dot Graham, Edward Weller, Erhardt Wunderlich, Eric Riou Du Cosquer, Florian Fieber, Fran O'Hara, François Vaillancourt, Frans Dijkman, Gabriele Haller, Gary Mogyorodi, Georg Sehl, Géza Bujdosó, Giancarlo Tomasig, Giorgio Pisani, Gustavo Márquez Sosa, Helmut Pichler, Hongbao Zhai, Horst Pohlmann, Ignacio Trejos, Ilia Kulakov, Ine Lutterman, Ingvar Nordström, Iosif Itkin, Jamie Mitchell, Jan Giesen, Jean-Francois Riverin, Joanna Kazun, Joanne Tremblay, Joëlle Genois, Johan Klintin, John Kurowski, Jörn Münzel, Judy McKay, Jürgen Beniermann, Karol Frühauf, Katalin Balla, Kevin Kooh, Klaudia Dussa- Zieger, Klaus Erlenbach, Klaus Olsen, Krisztián Miskó, Laura Albert, Liang Ren, Lijuan Wang, Lloyd Roden, Lucjan Stapp, Mahmoud Khalaili, Marek Majernik, Maria Clara Choucair, Mark Rutz, Markus Niehammer, Martin Klonk, Márton Siska, Matthew Gregg, Matthias Hamburg, Mattijs Kemmink, Maud Schlich, May Abu-Sbeit, Meile Posthuma, Mette Bruhn-Pedersen, Michal Tal, Michel Boies, Mike Smith, Miroslav Renda, Mohsen Ekssir, Monika Stocklein Olsen, Murian Song, Nicola De Rosa, Nikita Kalyani, Nishan Portoyan, Nitzan Goldenberg, Ole Chr. Hansen, Patricia McQuaid, Patricia Osorio, Paul Weymouth, Pawel Kwasik, Peter Zimmerer, Petr Neugebauer, Piet de Roo, Radoslaw Smilgin, Ralf Bongard, Ralf Reissing, Randall Rice, Rik Marselis, Rogier Ammerlaan, Sabine Gschwandtner, Sabine Uhde, Salinda Wickramasinghe, Salvatore Reale, Sammy Kolluru, Samuel Ouko, Stephanie Ulrich, Stuart Reid, Surabhi Bellani, Szilard Szell, Tamás Gergely, Tamás Horváth, Tatiana Sergeeva, Tauhida Parveen, Thaer Mustafa, Thomas Eisbrenner, Thomas Harms, Thomas Heller, Tobias Letzkus, Tomas Rosenqvist, Werner Lieblang, Yaron Tsubery, Zhenlei Zuo y Zsolt Hargitai. "ISTQB Working Group Foundation Level" (Edición 2018): Klaus Olsen (presidente), Tauhida Parveen (vicepresidente), Rex Black (director de proyecto), Eshraka Zakaria, Debra Friedenberg, Ebbe Munk, Hans Schaefer, Judy McKay, Marie Walsh, Meile Posthuma, Mike Smith, Radoslaw Smilgin, Stephanie Ulrich, Steve Toms, Corne Kruger, Dani Almog, Eric Riou du Cosquer, Igal Levi, Johan Klintin, Kenji Onishi, Rashed Karim, Stevan Zivanovic, Sunny Kwon, Thomas Müller, Vipul Kocher, Yaron Tsubery y a todos los Comités Miembro por sus sugerencias. "ISTQB Working Group Foundation Level" (Edición 2018): Klaus Olsen (presidente), Tauhida Parveen (vicepresidente), Rex Black (director de proyecto), Eshraka Zakaria, Debra Friedenberg, Ebbe Munk, Hans Schaefer, Judy McKay, Marie Walsh, Meile Posthuma, Mike Smith, Radoslaw Smilgin, Stephanie Ulrich, Steve Toms, Corne Kruger, Dani Almog, Eric Riou du Cosquer, Igal Levi, Johan Klintin, Kenji Onishi, Rashed Karim, Stevan Zivanovic, Sunny Kwon, Thomas Müller, Vipul Kocher, Yaron Tsubery y a todos los Comités Miembro por sus sugerencias. Versión 4.0 Página 7 de 87 21 de abril de 2023 © International Software Testing Qualifications Board International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board "ISTQB Working Group Foundation Level" (Edición 2011): Thomas Müller (presidente), Debra Friedenberg. El equipo central agradece al equipo revisor (Dan Almog, Armin Beer, Rex Black, Julie Gardiner, Judy McKay, Tuula Pääkkönen, Eric Riou du Cosquier Hans Schaefer, Stephanie Ulrich, Erik van Veenendaal), y a todos los Comités Miembro por las sugerencias para la versión actual del programa de estudio. "ISTQB Working Group Foundation Level" (Edición 2005): Thomas Müller (presidente), Rex Black, Sigrid Eldh, Dorothy Graham, Klaus Olsen, Maaret Pyhäjärvi, Geoff Thompson y Erik van Veenendaal. El equipo principal da las gracias al equipo revisor y a todos los Comités Miembro por sus sugerencias. Versión 4.0 Página 8 de 87 21 de abril de 2023 © International Software Testing Qualifications Board International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board Notas de la Versión en Idioma Español Spanish Software Testing Qualifications Board (SSTQB) ha llevado a cabo la traducción del Programa de Estudio de “ISTQB® Certified Tester, Foundation Level” versión 4.0. Este Programa de Estudio se denomina, en idioma español, “Probador Certificado de ISTQB® de Nivel Básico” versión 4.0. El equipo de traducción y revisión para este programa de estudio es el siguiente (por orden alfabético): Responsable de la traducción: Gustavo Márquez Sosa (España) Revisora: Luisa Morales Gómez Tejedor (España) El Comité Ejecutivo del SSTQB agradece especialmente las aportaciones de los revisores. En una siguiente versión se podrán incorporar aportaciones adicionales. El SSTQB considera conveniente mantener abierta la posibilidad de realizar cambios en el “Programa de Estudio”. Madrid, 25 de julio de 2023 Versión 4.0 Página 9 de 87 21 de abril de 2023 © International Software Testing Qualifications Board International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board 0 Introducción 0.1 Objetivo de este Programa de Estudio Este programa de estudio constituye la base para la formación como Probador Certificado del ISTQB® de Nivel Básico. El ISTQB proporciona este programa de estudio en los siguientes términos: 1. A los comités miembro, para traducir a su idioma local y para acreditar a los proveedores de formación. Los Comités Miembro pueden adaptar el programa de estudio a sus necesidades lingüísticas particulares y añadir referencias para adaptarlo a sus publicaciones locales. 2. A los organismos de certificación, para elaborar las preguntas del examen en su lengua local adaptadas a los objetivos de aprendizaje de este programa de estudio. 3. A los proveedores de formación, para desarrollar material didáctico y determinar los métodos de enseñanza adecuados. 4. A los candidatos a la certificación, para que preparen el examen de certificación (ya sea como parte de un curso de formación o de forma independiente). 5. A la comunidad internacional de ingeniería de software y sistemas, para avanzar en la profesión de prueba del software y sistemas, y como fuente de libros y artículos. El ISTQB puede permitir que otras entidades utilicen este programa de estudio para otros fines, siempre y cuando soliciten y obtengan permiso previo y por escrito por parte del ISTQB. 0.2 El Nivel Básico de Probador Certificado en la Prueba de Software La certificación de Nivel Básico está dirigida a cualquier persona que se encuentre involucrada en la prueba de software. Incluidas las personas que asumen los roles de probadores, analistas de prueba, ingenieros de prueba, consultores de prueba, jefes de prueba, probadores que participan en la prueba de aceptación y desarrolladores de software. Esta cualificación de nivel básico también es apropiada para cualquier persona que desee una comprensión básica de la prueba de software, como jefes de proyecto, responsables de calidad, propietarios de producto, jefes de desarrollo de software, analistas de negocio, directores de TI y consultores de gestión. Los titulares del Certificado Básico podrán acceder a las certificaciones de nivel superior en la prueba de software. 0.3 Carrera Profesional para Probadores El esquema ISTQB® proporciona apoyo a los profesionales de la prueba en todas las etapas de su carrera ofreciendo tanto amplitud como profundidad de conocimientos. Las personas que hayan obtenido la certificación de la Fundación ISTQB® también pueden estar interesadas en el nivel avanzado troncal (analista de prueba, analista de pruebas técnicas y jefe de prueba) y a partir de esa certificación el nivel experto (Gestión de la Prueba o Mejora del Proceso de Prueba). Cualquiera persona que busque desarrollar competencias en prácticas de prueba en un entorno Ágil podría considerar las certificaciones de Probador Técnico Ágil o Liderazgo de Prueba Ágil a Escala. La corriente de Especialista ofrece una inmersión profunda en áreas que tienen enfoques de prueba específicos y actividades de prueba (por ejemplo, en automatización de la prueba, prueba de IA, prueba basada en modelos, prueba de aplicaciones móviles), que están relacionadas con áreas de prueba específicas (por ejemplo, prueba de rendimiento, prueba de usabilidad, prueba de aceptación, prueba de seguridad), o que agrupan conocimientos de prueba para ciertos dominios de la industria (por ejemplo, automoción o juegos). Visite www.istqb.org para obtener la información más reciente sobre el programa de probadores certificados de ISTQB. Versión 4.0 Página 10 de 87 21 de abril de 2023 © International Software Testing Qualifications Board International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board 0.4 Resultados de Negocio En esta sección se enumeran los 14 resultados de negocio que se esperan de una persona que haya obtenido la certificación de nivel básico. Un probador certificado de nivel básico puede... FL - BO - 01 Comprender qué es probar y por qué es beneficioso FL - BO - 02 Comprender los conceptos fundamentales de la prueba de software Identificar el enfoque de prueba y las actividades que se deben implementar en función FL - BO - 03 del contexto de prueba FL - BO - 04 Evaluar y mejorar la calidad de la documentación FL - BO - 05 Aumentar la efectividad y eficiencia de la prueba FL - BO - 06 Alinear el proceso de prueba con el ciclo de vida de desarrollo de software FL - BO - 07 Comprender los principios de gestión de la prueba FL - BO - 08 Redactar y comunicar informes de defectos claros y comprensibles Comprender los factores que influyen en las prioridades y esfuerzos relacionados con FL - BO - 09 la prueba FL - BO - 10 Trabajar como parte de un equipo interfuncional FL - BO - 11 Conocer los riesgos y beneficios relacionados con la automatización de la prueba FL - BO - 12 Identificar las competencias esenciales necesarias para probar FL - BO - 13 Comprender el impacto del riesgo en las pruebas FL - BO - 14 Informar eficazmente sobre el avance y la calidad de la prueba 0.5 Objetivos de Aprendizaje y Niveles de Conocimiento Evaluables Los objetivos de aprendizaje son la base para los resultados de negocio y se utilizan para crear los exámenes de Probador Certificado del ISTQB® de Nivel Básico. En general, todos los contenidos de los capítulos 1-6 de este programa de estudio son evaluables a un nivel K1. Es decir, se puede pedir al candidato que reconozca o recuerde una palabra clave o un concepto mencionado en cualquiera de los seis capítulos. Los niveles específicos de los objetivos de aprendizaje se muestran al principio de cada capítulo y se clasifican de la siguiente manera: K1: recordar. K2: entender. K3: aplicar. En el Apéndice A se ofrecen más detalles y ejemplos de objetivos de aprendizaje. Las definiciones de todos los términos identificados como palabras clave, enumerados a continuación de los títulos de los capítulos, deben ser recordadas (K1) aunque no se mencione de forma explícita en los objetivos de aprendizaje. Versión 4.0 Página 11 de 87 21 de abril de 2023 © International Software Testing Qualifications Board International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board 0.6 El Examen de Certificación El examen de certificación de nivel básico se basa en este programa de estudio. Las respuestas a las preguntas del examen pueden requerir el uso de material basado en más de una sección de este programa de estudio. Todas las secciones del programa de estudio son objeto de examen, excepto la Introducción y los Apéndices. Los estándares y libros se incluyen como referencias (capítulo 7), pero su contenido no es evaluable, más allá de lo que se resume en el propio programa de estudio a partir de dichos estándares y libros. Consulte el documento "Foundation Level Examination Structures and Rules". 0.7 Acreditación Un Comité Miembro de ISTQB® puede acreditar a los proveedores de formación cuyo material de curso siga este programa de estudio. Los proveedores de formación deberán obtener las directrices de acreditación del Comité Miembro u organismo que realice la acreditación. Un curso acreditado es reconocido como conforme a este programa de estudio, y se le permite tener un examen ISTQB® como parte del curso. Las directrices de acreditación para este programa de estudio siguen las "Accreditation Guidelines" generales publicadas por el "Processes Management and Compliance Working Group". 0.8 Tratamiento de Estándares Existen estándares a los que se hace referencia en el programa de estudio básico (por ejemplo, estándares IEEE o ISO). Estas referencias proporcionan un marco (como en las referencias a la norma ISO 25010 relativa a las características de calidad) o para proporcionar una fuente de información adicional si así lo desea el lector. Los documentos estándar no están pensados para ser objeto de examen. Consulte el capítulo 7 para obtener más información sobre los estándares. 0.9 Actualización La industria del software cambia rápidamente. Para hacer frente a estos cambios y proporcionar a los implicados acceso a información relevante y actualizada, los grupos de trabajo del ISTQB han creado enlaces en la página web www.istqb.org, que hacen referencia a la documentación de apoyo y a los cambios en los estándares. Esta información no es objeto de evaluación bajo el Programa de Estudio de Nivel Básico. 0.10 Nivel de Detalle El nivel de detalle de este programa de estudio permite la realización de cursos y exámenes consistentes a nivel internacional. Para lograr este objetivo, el programa de estudio se compone de: Objetivos didácticos generales que describen el propósito del Nivel Básico. Una lista de términos (palabras clave) que los alumnos deben ser capaces de recordar. Objetivos de aprendizaje para cada área de conocimiento, que describen los resultados cognitivos del aprendizaje que se deben alcanzar. Una descripción de los conceptos clave, incluyendo referencias a fuentes reconocidas. El contenido del programa de estudio no es una descripción de todo el área de conocimiento de la prueba de software; refleja el nivel de detalle que debe cubrirse en los cursos de formación de nivel básico. Se concentra en conceptos y técnicas de prueba que pueden aplicarse a todos los proyectos de software independientemente del CVDS empleado. Versión 4.0 Página 12 de 87 21 de abril de 2023 © International Software Testing Qualifications Board International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board 0.11 Organización de este Programa de Estudio Hay seis capítulos con contenido que puede ser objeto de examen. El encabezamiento de nivel superior de cada capítulo especifica el tiempo de formación del mismo. No se proporciona cronología por debajo del nivel del capítulo. Para los cursos de formación acreditados, el programa de estudio exige un mínimo de 1135 minutos (18 horas y 55 minutos) de formación, distribuidos en los seis capítulos de la siguiente manera: Capítulo 1: Fundamentos del Proceso de Prueba (180 minutos) o El alumno aprende los principios básicos relacionados con la prueba, las razones por las que es necesario probar y cuáles son los objetivos de la prueba. o El alumno comprende el proceso de prueba, las principales actividades de prueba y el producto de prueba. o El alumno comprende las competencias esenciales para probar. Capítulo 2: Prueba a lo Largo del Ciclo de Vida de Desarrollo de Software (130 minutos) o El alumno aprende cómo se incorpora la prueba a los diferentes enfoques de desarrollo. o El alumno aprende los conceptos de los enfoques de probar primero, así como DevOps. o El alumno aprende sobre los diferentes niveles de prueba, tipos de prueba y prueba de mantenimiento. Capítulo 3: Prueba Estática (80 minutos) o El alumno aprende los fundamentos de la prueba estática, el proceso de retroalimentación y revisión. Capítulo 4: Análisis y Diseño de la Prueba (390 minutos) o El alumno aprende a aplicar técnicas de caja negra, caja blanca y prueba basada en la experiencia para obtener casos de prueba a partir de diversos productos software. o El alumno aprende sobre el enfoque de prueba basado en la colaboración. Capítulo 5: Gestión de la Prueba (335 minutos) o El alumno aprende a planificar las pruebas en general y a estimar el esfuerzo de la prueba. o El alumno aprende cómo los riesgos pueden influir en el alcance de la prueba. o El alumno aprende a monitorizar y controlar las actividades de prueba. o El alumno aprende cómo la gestión de la configuración apoya la prueba. o El alumno aprende a informar de los defectos de forma clara y comprensible. Capítulo 6: Soporte de Herramientas para el Proceso de Prueba (20 minutos) o El alumno aprende a clasificar las herramientas y a comprender los riesgos y las ventajas de la automatización de la prueba. Versión 4.0 Página 13 de 87 21 de abril de 2023 © International Software Testing Qualifications Board International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board 1 Fundamentos del Proceso de Prueba - 180 minutos Duración: 180 minutos Palabras Clave1 Español Inglés cobertura coverage depurar debugging defecto defect error error fallo failure calidad quality aseguramiento de la calidad quality assurance causa raíz root cause análisis de prueba test analysis base de prueba test basis caso de prueba test case compleción de la prueba test completion condición de prueba test condition control de la prueba test control datos de prueba test data diseño de la prueba test design ejecución de prueba test execution implementación de prueba test implementation monitorización de la prueba test monitoring objeto de prueba test object objetivo de prueba test objective planificación de prueba test planning procedimiento de prueba test procedure resultado de prueba test result prueba testing producto de prueba testware 1 Las palabras clave se encuentran ordenadas por orden alfabético de los términos en inglés. Versión 4.0 Página 14 de 87 21 de abril de 2023 © International Software Testing Qualifications Board International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board validación validation verificación verification Objetivos de Aprendizaje para “Capítulo 1” 1.1 ¿Qué es Probar? FL-1.1.1 (K1) Identificar objetivos de prueba característicos. FL-1.1.2 (K2) Diferenciar entre probar y depurar. 1.2 ¿Por qué es Necesario Probar? FL-1.2.1 (K2) Aportar ejemplos de por qué es necesario realizar pruebas. FL-1.2.2 (K1) Recordar la relación entre prueba y aseguramiento de la calidad. FL-1.2.3 (K2) Distinguir entre causa raíz, error, defecto y fallo. 1.3 Principios de la Prueba FL-1.3.1 (K2) Explicar los siete principios de la prueba. 1.4 Actividades de Prueba, Productos de Prueba y Roles de Prueba FL-1.4.1 (K2) Resumir las diferentes actividades y tareas de prueba. FL-1.4.2 (K2) Explicar el impacto del contexto en el proceso de prueba. FL-1.4.3 (K2) Diferenciar el producto de prueba que soporta las actividades de prueba. FL-1.4.4 (K2) Explicar el valor de mantener la trazabilidad. FL-1.4.5 (K2) Comparar los diferentes roles en la prueba. 1.5. Competencias Esenciales y Buenas Prácticas en la Prueba FL-1.5.1 (K2) Dar ejemplos de las competencias genéricas necesarias para probar. FL-1.5.2 (K1) Recordar las ventajas del enfoque de equipo completo. FL-1.5.3 (K2) Distinguir las ventajas e inconvenientes de la independencia de la prueba. Versión 4.0 Página 15 de 87 21 de abril de 2023 © International Software Testing Qualifications Board International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board 1.1 ¿Qué es Probar? Los sistemas de software son parte integrante de nuestra vida cotidiana. La mayoría de la gente ha tenido experiencias con software que no funcionaba como se esperaba. Un software que no funciona correctamente puede acarrear muchos problemas, como pérdidas económicas, de tiempo o de reputación empresarial y, en casos extremos, incluso lesiones o la muerte. La prueba de software evalúa la calidad del software y ayuda a reducir el riesgo de fallo del software en operación. La prueba de software es un conjunto de actividades para descubrir defectos y evaluar la calidad de los artefactos de software. Cuando se prueban, estos artefactos se conocen como objetos de prueba. Un concepto erróneo habitual sobre la prueba es que sólo consiste en ejecutar pruebas (es decir, ejecutar el software y comprobar los resultados de las pruebas). Sin embargo, la prueba del software también incluye otras actividades y debe estar alineada con el ciclo de vida de desarrollo del software (véase el capítulo 2). Otro concepto erróneo habitual sobre la prueba es que ésta se concentra por completo en la verificación del objeto de prueba. Aunque la prueba implica verificación, es decir, comprobar si el sistema cumple los requisitos especificados, también implica validación, lo que significa comprobar si el sistema satisface las necesidades de los usuarios y otros implicados en su entorno operativo. La prueba puede ser dinámica o estática. La prueba dinámica implica la ejecución del software, mientras que la prueba estática no. La prueba estática incluye revisiones (véase el capítulo 3) y análisis estático. La prueba dinámica utiliza distintos tipos de técnicas de prueba y enfoques de prueba para obtener casos de prueba (véase el capítulo 4). Probar no es sólo una actividad técnica. También necesita que se planifique, gestione, estime, monitorice y controle de forma adecuada (véase el capítulo 5). Los probadores utilizan herramientas (véase el capítulo 6), pero es importante recordar que la prueba es en gran medida una actividad intelectual, que requiere que los probadores tengan conocimientos especializados, utilicen competencias analíticas y apliquen el pensamiento crítico y el pensamiento sistémico (Myers 2011, Roman 2018). El estándar ISO/IEC/IEEE 29119-1 proporciona más información sobre los conceptos de prueba de software. 1.1.1 Objetivos de Prueba Los objetivos de prueba característicos son: Evaluar productos de trabajo como requisitos, historias de usuario, diseños y código. Provocar fallos y encontrar defectos. Asegurar la cobertura necesaria de un objeto de prueba. Reducir el nivel de riesgo asociado a una calidad inadecuada del software. Verificar si se han cumplido los requisitos especificados. Verificar que un objeto de prueba cumple los requisitos contractuales, legales y normativos. Proporcionar información a los implicados para que puedan tomar decisiones informadas. Generar confianza en la calidad del objeto de prueba. Validar si el objeto de prueba está completo y funciona como esperan los implicados. Versión 4.0 Página 16 de 87 21 de abril de 2023 © International Software Testing Qualifications Board International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board Los objetivos de prueba pueden variar en función del contexto, que incluye el producto de trabajo que se está probando, el nivel de prueba, los riesgos, el ciclo de vida de desarrollo del software (SDLC) que se está siguiendo y los factores relacionados con el contexto del negocio, por ejemplo, la estructura corporativa, las consideraciones relativas a la competencia o el tiempo de comercialización. 1.1.2 Probar y Depurar Probar y depurar son actividades distintas. Probar puede desencadenar fallos causados por defectos en el software (prueba dinámica) o puede, de forma directa, encontrar defectos en el objeto de prueba (prueba estática). Cuando una prueba dinámica (véase el capítulo 4) desencadena un fallo, la depuración se ocupa de encontrar las causas de este fallo (defectos), analizar estas causas y eliminarlas. En este caso, el proceso típico de depuración implica: Reproducción del fallo. Diagnóstico (hallazgo de la causa raíz). Corrección de la causa. La prueba de confirmación posterior comprueba si las correcciones han resuelto el problema. Preferiblemente, la prueba de confirmación la realiza la misma persona que llevó a cabo la prueba inicial. También se puede llevar a cabo una prueba de regresión posterior, para comprobar si las correcciones están causando fallos en otras partes del objeto de prueba (véase la sección 2.2.3 para más información sobre la prueba de confirmación y la prueba de regresión). Cuando la prueba estática identifica un defecto, la depuración se ocupa de eliminarlo. No se necesita reproducción ni diagnóstico, ya que la prueba estática encuentra directamente los defectos y no puede provocar fallos (véase el capítulo 3). Versión 4.0 Página 17 de 87 21 de abril de 2023 © International Software Testing Qualifications Board International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board 1.2 ¿Por qué es Necesario Probar? Probar, como forma de control de la calidad, ayuda a alcanzar los objetivos acordados dentro del alcance, el tiempo, la calidad y las limitaciones presupuestarias establecidos. La contribución de la prueba al éxito no debe limitarse a las actividades del equipo de prueba. Cualquier implicado puede utilizar sus competencias en materia de prueba para contribuir al éxito del proyecto. Probar componentes, sistemas y la documentación asociada ayuda a identificar defectos en el software: 1.2.1 Contribuciones de la prueba al éxito Probar proporciona un medio rentable de detectar defectos. Estos defectos pueden eliminarse posteriormente (mediante la depuración, una actividad ajena a la prueba), por tanto, la prueba contribuye indirectamente a lograr objetos de prueba de mayor calidad. La prueba proporciona medios para evaluar directamente la calidad de un objeto de prueba en varias etapas del ciclo de vida de desarrollo software CVDS. Estas mediciones se utilizan como parte de una actividad de gestión de proyectos más amplia, contribuyendo a las decisiones para pasar a la siguiente etapa del SDLC, como por ejemplo la decisión de entrega. Probar proporciona a los usuarios una representación indirecta en el proyecto de desarrollo. Los probadores aseguran que se tiene en cuenta la comprensión de las necesidades de los usuarios a lo largo de todo el ciclo de vida de desarrollo. La alternativa es implicar a un conjunto representativo de usuarios como parte del proyecto de desarrollo, lo que no suele ser posible debido a los elevados costes y a la falta de disponibilidad de usuarios adecuados. También puede ser necesario realizar pruebas para cumplir requisitos contractuales o legales, o para ajustarse a los estándares reglamentarios. 1.2.2 Prueba y Aseguramiento de la Calidad (AC) Aunque a menudo se utilizan indistintamente los términos "prueba" y "aseguramiento de la calidad" (AC) , prueba y AC no son lo mismo. La prueba es una forma de control de la calidad (CC. El CC es un enfoque correctivo orientado al producto que se concentra en aquellas actividades que contribuyen a la consecución de unos niveles de calidad adecuados. La prueba es una de las principales formas de control de la calidad, mientras que otras incluyen métodos formales (comprobación de modelo y prueba de corrección), simulación y creación de prototipos. El aseguramiento de la calidad es un enfoque preventivo orientado a los procesos que se concentra en la implementación y mejora de los mismos. Funciona sobre la base de que, si un buen proceso se sigue correctamente, entonces generará un buen producto. La garantía de calidad se aplica tanto al proceso de desarrollo como al de prueba, y es responsabilidad de todos los que participan en un proyecto. Los resultados de la prueba son utilizados por el Aseguramiento de la Calidad (AC) y el Control de la Calidad (CC). En el control de calidad se utilizan para corregir defectos, mientras que en la garantía de calidad proporcionan retroalimentación sobre el rendimiento de los procesos de desarrollo y prueba. 1.2.3 Errores, Defectos, Fallos y Causas Raíz Los seres humanos cometen errores (equivocaciones), que producen defectos, que a su vez pueden dar lugar a fallos. Los seres humanos cometen errores por diversas razones, como la presión por razones de tiempo, la complejidad de los productos de trabajo, los procesos, la infraestructura o las interacciones, o simplemente porque están cansados o carecen de la formación adecuada. Versión 4.0 Página 18 de 87 21 de abril de 2023 © International Software Testing Qualifications Board International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board Los defectos pueden encontrarse en la documentación, como una especificación de requisitos o un guion de prueba, en el código fuente o en un artefacto de apoyo como un archivo de construcción. Los defectos en los artefactos producidos al principio del CVDS, si no se detectan, suelen dar lugar a artefactos defectuosos más adelante en el ciclo de vida. Si se ejecuta un defecto en el código, el sistema puede fallar al hacer lo que debería hacer, o hacer algo que no debería, provocando un fallo. Algunos defectos siempre darán lugar a un fallo si se ejecutan, mientras que otros sólo darán lugar a un fallo en circunstancias específicas, y algunos puede que nunca den lugar a un fallo. Los errores y los defectos no son la única causa de los fallos. Los fallos también pueden deberse a condiciones ambientales, como cuando la radiación o el campo electromagnético provocan defectos en el firmware. Una causa raíz es una razón fundamental por la que se produce un problema (por ejemplo, una situación que conduce a un error). Las causas raíz se identifican mediante el análisis de la causa raíz, que suele realizarse cuando se produce un fallo o se identifica un defecto. Se cree que pueden evitarse otros fallos o defectos similares o reducirse su frecuencia tratando la causa raíz, por ejemplo, eliminándola. Versión 4.0 Página 19 de 87 21 de abril de 2023 © International Software Testing Qualifications Board International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board 1.3 Principios de la Prueba A lo largo de los años se han sugerido una serie de principios de prueba que ofrecen directrices generales aplicables a todas las pruebas. En este programa de estudio se describen siete de estos principios. 1. La prueba muestra la presencia de defectos, no su ausencia. La prueba puede mostrar que hay defectos en el objeto de prueba, pero no puede demostrar que no los haya (Buxton 1970). La prueba reduce la probabilidad de que queden defectos por descubrir en el objeto de prueba, pero aunque no se encuentren defectos, la prueba no puede demostrar la corrección del objeto de prueba. 2. La prueba exhaustiva es imposible. Probarlo todo no es factible salvo en casos triviales (Manna 1978). En lugar de intentar probar exhaustivamente, deberían utilizarse técnicas de prueba (véase el capítulo 4), priorización de casos de prueba (véase el apartado 5.1.5) y pruebas basadas en el riesgo (véase el apartado 5.2), para concentrar los esfuerzos de prueba. 3. La prueba temprana ahorra tiempo y dinero. Los defectos que se eliminan al principio del proceso no causarán defectos posteriores en los productos de trabajo derivados. El coste de la calidad se reducirá, ya que se producirán menos fallos más adelante en el CVDS (Boehm 1981). Para encontrar defectos en una fase temprana, tanto las pruebas estáticas (véase el capítulo 3) como las pruebas dinámicas (véase el capítulo 4) deben iniciarse lo antes posible. 4. Los defectos se agrupan. Un pequeño número de componentes del sistema suelen contener la mayoría de los defectos descubiertos o son responsables de la mayoría de los fallos operativos (Enders 1975). Este fenómeno es una ilustración del principio de Pareto. Las agrupaciones de defectos previstas, y las agrupaciones de defectos reales observadas durante la prueba o en operación, son una entrada importante para la prueba basada en el riesgo (véase la sección 5.2). 5. Las pruebas se desgastan. Si las pruebas se repiten muchas veces, se vuelven cada vez más ineficaces para detectar nuevos defectos (Beizer 1990). Para superar este efecto, puede que sea necesario modificar las pruebas y los datos de prueba existentes, y que haya que escribir nuevas pruebas. Sin embargo, en algunos casos, la repetición de las mismas pruebas puede tener un resultado beneficioso, por ejemplo, en las pruebas de regresión automatizadas (véase la sección 2.2.3). 6. La prueba depende del contexto. No existe un único enfoque de prueba aplicable universalmente. La prueba se realiza de forma diferente en distintos contextos (Kaner 2011). 7. Falacia de la ausencia de defectos. Es una falacia (es decir, una idea equivocada) esperar que la verificación del software asegure el éxito de un sistema. Probar a fondo todos los requisitos especificados y arreglar todos los defectos encontrados podría seguir produciendo un sistema que no satisface las necesidades y expectativas de los usuarios, que no ayuda a conseguir los objetivos de negocio del cliente y que es inferior en comparación con otros sistemas de la competencia. Además de la verificación, también debe llevarse a cabo la validación (Boehm 1981). Versión 4.0 Página 20 de 87 21 de abril de 2023 © International Software Testing Qualifications Board International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board 1.4 Actividades de Prueba, Productos de Prueba y Roles de Prueba La prueba depende del contexto, pero, a un alto nivel, existen conjuntos comunes de actividades de prueba sin los cuales es menos probable que la prueba alcance los objetivos de prueba. Estos conjuntos de actividades de prueba forman un proceso de prueba. El proceso de prueba puede adaptarse a una situación determinada en función de diversos factores. Qué actividades de prueba se incluyen en este proceso de prueba, cómo se implementan y cuándo tienen lugar se decide normalmente como parte de la planificación de prueba para la situación específica (véase la sección 5.1). Las siguientes secciones describen los aspectos generales de este proceso de prueba en términos de actividades y tareas de prueba, el impacto del contexto, el material de prueba, la trazabilidad entre la base de prueba y el material de prueba, y los roles de prueba. El estándar ISO/IEC/IEEE 29119-2 proporciona más información sobre los procesos de prueba. 1.4.1 Actividades y Tareas de Prueba Un proceso de prueba suele constar de los principales grupos de actividades que se describen a continuación. Aunque puede parecer que muchas de estas actividades siguen una secuencia lógica, a menudo se implementan de forma iterativa o en paralelo. Estas actividades de prueba suelen necesitar adaptarse al sistema y al proyecto. Planificación de la Prueba. La planificación de la prueba consiste en definir los objetivos de la prueba y, a continuación, seleccionar el enfoque que mejor permita alcanzar los objetivos dentro de las limitaciones impuestas por el contexto general. La planificación de la prueba se explica con más detalle en la sección 5.1. Monitorización y Control de la Prueba. La monitorización de la prueba implica la comprobación continua de todas las actividades de la prueba y la comparación del avance real con el plan. El control de prueba implica la adopción de las medidas necesarias para cumplir los objetivos de la prueba. La monitorización de prueba y el control de prueba se explican con más detalle en la sección 5.3. Análisis de la Prueba. El análisis de la prueba incluye el análisis de la base de prueba para identificar las prestaciones que pueden ser objeto de prueba y para definir y priorizar las condiciones de prueba asociadas, junto con los riesgos y niveles de riesgo relacionados (véase la sección 5.2). La base de prueba y los objetos de prueba también se evalúan para identificar los defectos que pueden contener y valorar su capacidad de ser probados. El análisis de prueba suele apoyarse en el uso de técnicas de prueba (véase el capítulo 4). El análisis de la prueba responde a la pregunta "¿qué hay que probar?" en términos de criterios de cobertura medibles. Diseño de la Prueba. El diseño de prueba incluye la elaboración de las condiciones de prueba en casos de prueba y otros productos de prueba (por ejemplo, contratos de prueba). Esta actividad suele implicar la identificación de elementos de cobertura, que sirven de referencia para especificar las entradas de los casos de prueba. Las técnicas de prueba (véase el capítulo 4) pueden servir de apoyo a esta actividad. El diseño de pruebas también incluye la definición de los requisitos de datos de prueba, el diseño del entorno de prueba y la identificación de cualquier otra infraestructura y herramientas necesarias. El diseño de prueba responde a la pregunta "¿cómo llevar a cabo la prueba?". Versión 4.0 Página 21 de 87 21 de abril de 2023 © International Software Testing Qualifications Board International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board Implementación de la Prueba. La implementación de prueba incluye la creación o la adquisición de los productos de prueba necesarios para la ejecución de prueba (por ejemplo, los datos de prueba). Los casos de prueba pueden organizarse en procedimientos de prueba y suelen reunirse en conjuntos de prueba. Se crean guiones de prueba manuales y automatizados. Se priorizan los procedimientos de prueba y se organizan dentro de un calendario de ejecución de prueba para una ejecución de prueba eficiente (véase la sección 5.1.5). Se construye el entorno de prueba y se verifica que está configurado correctamente. Ejecución de la Prueba. La ejecución de la prueba incluye la realización de las pruebas de acuerdo con el calendario de ejecución de prueba (ejecuciones de pruebas). La ejecución de una prueba puede ser manual o automatizada. La ejecución de prueba puede adoptar muchas formas, incluidas la prueba continua o sesiones de prueba en pareja. Los resultados de prueba reales se comparan con los resultados esperados. Se registran los resultados de la prueba. Las anomalías se analizan para identificar sus causas probables. Este análisis permite informar de las anomalías en función de los fallos observados (véase el apartado 5.5). Compleción de la Prueba. Las actividades de compleción de la prueba suelen producirse en los hitos del proyecto (por ejemplo, la entrega, el final de una iteración, la compleción del nivel de prueba) para cualquier defecto no resuelto, solicitud de cambio o elemento de lista de trabajo acumulado del producto que se haya creado. Cualquier producto de prueba que pueda ser útil en el futuro se identifica y se archiva o se entrega a los equipos adecuados. Se desactiva el entorno de prueba hasta un estado acordado. Se analizan las actividades de prueba para identificar las lecciones aprendidas y las mejoras para futuras iteraciones, entregas o proyectos (véase la sección 2.1.6). Se crea un informe de compleción de la prueba y se comunica a los implicados. 1.4.2 El Proceso de Prueba en Contexto La prueba no se realiza de forma aislada. Las actividades de prueba son parte integrante de los procesos de desarrollo que se llevan a cabo en una organización. La prueba también está sufragada por los implicados y su objetivo final es ayudar a satisfacer las necesidades de negocio de los implicados. Por lo tanto, la forma en que se lleve a cabo la prueba dependerá de una serie de factores contextuales entre los que se incluyen: Implicados (necesidades, expectativas, requisitos, voluntad de cooperación, etc.) Miembros del equipo (competencias, conocimientos, nivel de experiencia, disponibilidad, necesidades de formación, etc.) Dominio del negocio (criticidad del objeto de prueba, riesgos identificados, necesidades del mercado, normativa legal específica, etc.) Factores técnicos (tipo de software, arquitectura del producto, tecnología utilizada, etc.) Restricciones del proyecto (alcance, tiempo, presupuesto, recursos, etc.) Factores organizativos (estructura organizativa, políticas existentes, prácticas utilizadas, etc.) Ciclo de vida de desarrollo del software (prácticas de ingeniería, métodos de desarrollo, etc.) Herramientas (disponibilidad, usabilidad, cumplimiento, etc.) Versión 4.0 Página 22 de 87 21 de abril de 2023 © International Software Testing Qualifications Board International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board Estos factores influirán en muchos asuntos relacionados con la prueba, entre ellos: la estrategia de prueba, las técnicas de prueba utilizadas, el grado de automatización de la prueba, el nivel de cobertura requerido, el nivel de detalle de la documentación de prueba, el suministro de información, etc. 1.4.3 Productos de Prueba El software de prueba se crea como producto de salida de las actividades de prueba descritas en la sección 1.4.1. Existe una variación significativa en la forma en que las distintas organizaciones producen, conforman, nombran, organizan y gestionan sus productos de trabajo. Una gestión de la configuración adecuada (véase la sección 5.4) asegura la consistencia y la integridad de los productos de trabajo. La siguiente lista de productos de trabajo no es exhaustiva: Productos del Trabajo de Planificación de la Prueba o Entre los productos del trabajo de planificación de la prueba se incluyen: el plan de prueba, el calendario de prueba, el registro de riesgos y los criterios de entrada y salida (véase la sección 5.1). El registro de riesgos es una lista de riesgos junto con la probabilidad del riesgo, el impacto del riesgo e información sobre la mitigación del riesgo (véase la sección 5.2). El calendario de prueba, el registro de riesgos y los criterios de entrada y salida suelen formar parte del plan de prueba. Productos de Trabajo de Monitorización y Control de la Prueba o Los productos de trabajo de monitorización y control de la prueba incluyen: informes del avance de la prueba (véase el apartado 5.3.2), documentación de las directivas de control (véase el apartado 5.3) e información sobre los riesgos (véase el apartado 5.2). Productos del Trabajo de Análisis de la Prueba o Los productos del trabajo de análisis de la prueba incluyen: condiciones de prueba (priorizadas) (por ejemplo, criterios de aceptación, véase la sección 4.5.2), e informes de defectos relativos a los defectos en la base de prueba (si no se solucionan directamente). Productos del Trabajo del Diseño de la Prueba o Los productos de trabajo del diseño de prueba incluyen: casos de prueba (priorizados), contratos de prueba, elementos de cobertura, requisitos de datos de prueba y requisitos del entorno de prueba. Productos del Trabajo de Implementación de la Prueba o Los productos de trabajo de implementación de prueba incluyen: procedimientos de prueba, guiones de prueba automatizados, juegos de prueba, datos de prueba, calendario de ejecución de la prueba y elementos del entorno de prueba. Algunos ejemplos de elementos del entorno de pruebas son: stubs, controladores, simuladores y virtualizaciones de servicios. Productos del Trabajo de Ejecución de la Prueba o Los productos de trabajo de la ejecución de la prueba incluyen: registros en bitácora de prueba e informes de defectos (véase la sección 5.5). Productos del Trabajo de Compleción de la Prueba o Los productos de trabajo de la compleción de la prueba incluyen: informe de compleción de la prueba (véase la sección 5.3.2), elementos de acción para la mejora de proyectos o iteraciones posteriores, lecciones aprendidas documentadas y solicitudes de cambio (por ejemplo, como elementos de la lista de trabajo acumulado del producto). Versión 4.0 Página 23 de 87 21 de abril de 2023 © International Software Testing Qualifications Board International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board 1.4.4 Trazabilidad entre Bases de Prueba y Productos de Prueba Para implementar una monitorización y un control efectivos de la prueba, es importante establecer y mantener la trazabilidad a lo largo del proceso de prueba entre los elementos de la base de prueba, los productos de prueba asociados a estos elementos (por ejemplo, las condiciones de la prueba, los riesgos, los casos de prueba), los resultados de la prueba y los defectos detectados. Una trazabilidad precisa soporta la evaluación de la cobertura, por lo que es muy útil que se definan criterios de cobertura medibles en la base de prueba. Los criterios de cobertura pueden funcionar como indicadores clave de rendimiento para impulsar las actividades que muestran hasta qué punto se han alcanzado los objetivos de la prueba (véase la sección 1.1.1). Por ejemplo: La trazabilidad de los casos de prueba a los requisitos puede verificar que los requisitos están cubiertos por los casos de prueba. La trazabilidad de los resultados de prueba a los riesgos puede utilizarse para evaluar el nivel de riesgo residual en un objeto de prueba. Además de evaluar la cobertura, una buena trazabilidad permite determinar el impacto de los cambios, facilita las auditorías de la prueba y ayuda a cumplir los criterios de gobernanza de TI. Una buena trazabilidad también facilita la comprensión de los informes de avance y compleción de la prueba al incluir el estado de los elementos de la base de prueba. Esto también puede ayudar a comunicar los aspectos técnicos de la prueba a los implicados de forma comprensible. La trazabilidad proporciona información para evaluar la calidad del producto, la capacidad del proceso y el avance del proyecto con respecto a los objetivos de negocio. 1.4.5 Roles en la Prueba En este programa de estudio se tratan dos roles principales en la prueba: un rol de gestión de prueba y un rol de prueba. Las actividades y tareas asignadas a estos dos roles dependen de factores como el contexto del proyecto y del producto, las competencias de las personas que desempeñan los roles y la organización. El rol de gestión de prueba asume la responsabilidad general del proceso de prueba, del equipo de prueba y de la dirección de las actividades de prueba. El rol de gestión de prueba se concentra principalmente en las actividades de planificación de prueba, monitorización y control de prueba y compleción de la prueba. La forma en que se lleva a cabo el rol de gestión de pruebas varía en función del contexto. Por ejemplo, en el desarrollo ágil de software, algunas de las tareas de gestión de pruebas pueden correr a cargo del equipo ágil. Las tareas que abarcan a varios equipos o a toda la organización pueden ser realizadas por jefes de prueba ajenos al equipo de desarrollo. El rol de prueba asume la responsabilidad general del aspecto asociado a la ingeniería (técnica) de la prueba. El rol de prueba se concentra principalmente en las actividades de análisis de prueba, diseño de prueba, implementación de prueba y ejecución de prueba. Diferentes personas pueden asumir estos roles en diferentes momentos. Por ejemplo, el rol de gestión de la prueba puede ser desempeñado por un jefe de equipo, por un jefe de prueba, por un jefe de desarrollo, etc. También es posible que una misma persona asuma los roles de prueba y gestión de prueba al mismo tiempo. Versión 4.0 Página 24 de 87 21 de abril de 2023 © International Software Testing Qualifications Board 1.5 Competencias Esenciales y Buenas Prácticas de la Prueba La competencia es la capacidad de hacer algo bien que proviene del conocimiento, la práctica y la aptitud de cada uno. Los buenos probadores deben poseer algunas competencias esenciales para hacer bien su trabajo. Los buenos probadores deben ser jugadores de equipo eficaces y deben ser capaces de realizar pruebas en diferentes niveles de independencia de la prueba. 1.5.1 Competencias Genéricas Necesarias para Probar A pesar de ser genéricas, las siguientes competencias son especialmente relevantes para los probadores: Conocimiento en materia de prueba (para aumentar la efectividad de la prueba, por ejemplo, mediante el uso de técnicas de prueba). Minuciosidad, cuidado, curiosidad, atención a los detalles, ser metódico (para identificar defectos, especialmente los difíciles de encontrar). Buena competencia en el ámbito de la comunicación escucha activa, ser un jugador de equipo (para interactuar eficazmente con todos los implicados, transmitir información a los demás, hacerse entender e informar y discutir los defectos). Pensamiento analítico, pensamiento crítico, creatividad (para aumentar la efectividad de las pruebas). Conocimientos técnicos (para aumentar la eficiencia de las pruebas, por ejemplo, utilizando herramientas de prueba adecuadas). Conocimientos del dominio (para poder comprender y comunicarse con los usuarios finales/representantes de negocio). A menudo, los probadores son los portadores de las malas noticias. Es un rasgo humano común culpar al portador de malas noticias. Esto hace que las competencias de comunicación sean cruciales para los probadores. Comunicar los resultados de prueba puede percibirse como una crítica al producto y a su autor. El sesgo de confirmación puede dificultar la aceptación de información que discrepa de las creencias actuales. Algunas personas pueden percibir las pruebas como una actividad destructiva, a pesar de que contribuyen en gran medida al éxito del proyecto y a la calidad del producto. Para intentar mejorar esta opinión, la información sobre defectos y fallos debe comunicarse de forma constructiva. 1.5.2 Enfoque de Equipo Completo Una de las competencias importantes para un probador es la capacidad de trabajar eficazmente en un contexto de equipo y de contribuir positivamente a los objetivos del mismo. El enfoque de equipo completo - una práctica procedente de la Programación Extrema (véase la sección 2.1) - se basa en esta competencia. En el enfoque de equipo completo, cualquier miembro del equipo con los conocimientos y competencias necesarios puede realizar cualquier tarea, y todos son responsables de la calidad. Los miembros del equipo comparten el mismo espacio de trabajo (físico o virtual), ya que la ubicación común facilita la comunicación y la interacción. El enfoque de equipo completo mejora la dinámica de equipo, potencia la comunicación y la colaboración dentro del equipo y crea sinergia al permitir que los diversos conjuntos de competencias dentro del equipo se aprovechen en beneficio del proyecto. Los probadores trabajan en estrecha colaboración con otros miembros del equipo para asegurar que se alcanzan los niveles de calidad deseados. Esto incluye colaborar con los representantes de negocio para ayudarles a crear pruebas de aceptación adecuadas y trabajar con los desarrolladores para acordar la estrategia de prueba y decidir los enfoques de automatización de la prueba. De este modo, los probadores pueden transferir conocimientos sobre la prueba a otros miembros del equipo e influir en el desarrollo del producto. International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board Dependiendo del contexto, el enfoque de equipo completo puede no ser siempre apropiado. Por ejemplo, en algunas situaciones, como las críticas para la seguridad, puede necesitarse un alto nivel de independencia en la prueba. 1.5.3 Independencia de la Prueba Un cierto grado de independencia hace que el probador sea más eficaz a la hora de encontrar defectos debido a las diferencias entre los sesgos cognitivos del autor y del probador (cf. Salman 1995). Sin embargo, la independencia no sustituye a la familiaridad; por ejemplo, los desarrolladores pueden encontrar eficazmente muchos defectos en su propio código. Los productos del trabajo pueden ser probados por su autor (sin independencia), por los compañeros del autor del mismo equipo (cierta independencia), por probadores ajenos al equipo del autor pero dentro de la organización (alta independencia), o por probadores ajenos a la organización (independencia muy alta). Para la mayoría de los proyectos, suele ser mejor llevar a cabo las pruebas con varios niveles de independencia (por ejemplo, que los desarrolladores realicen las pruebas de integración de componentes, que el equipo de pruebas realice las pruebas de integración de sistemas y sistemas, y que los representantes de negocio realicen las pruebas de aceptación). La principal ventaja de la independencia de la prueba es que es probable que los probadores independientes reconozcan diferentes tipos de fallos y defectos en comparación con los desarrolladores debido a sus diferentes antecedentes, perspectivas técnicas y sesgos. Además, un probador independiente puede verificar, cuestionar o refutar las suposiciones realizadas por los implicados durante la especificación e implementación del sistema. Sin embargo, también existen algunos inconvenientes. Los probadores independientes pueden estar aislados del equipo de desarrollo, lo que puede provocar una falta de colaboración, problemas de comunicación o una relación de confrontación con el equipo de desarrollo. Los desarrolladores pueden perder el sentido de la responsabilidad por la calidad. Los probadores independientes pueden ser vistos como un cuello de botella o culpables de los retrasos en la entrega. Versión 4.0 Página 26 de 87 21 de abril de 2023 © International Software Testing Qualifications Board 2 Prueba a lo Largo del Ciclo de Vida de Desarrollo de Software - 130 minutos Duración: 130 minutos Palabras Clave2 Español Inglés prueba de aceptación acceptance testing prueba de caja negra black-box testing prueba de integración de componentes component integration testing prueba de componentes component testing prueba de confirmación confirmation testing prueba funcional functional testing prueba de integración integration testing prueba de mantenimiento maintenance testing prueba no funcional non-functional testing prueba no funcional regression testing desplazamiento a la izquierda shift-left prueba de integración de sistemas system integration testing prueba de sistema system testing nivel de prueba test level objeto de prueba test object tipo de prueba test type prueba de caja blanca white-box testing Objetivos de Aprendizaje para “Capítulo 2” 2.1 La prueba en el Contexto de un Ciclo de Vida de Desarrollo de Software FL-2.1.1 (K2) Explicar el impacto del ciclo de vida de desarrollo de software elegido en la prueba. Recordar las buenas prácticas de prueba que se aplican a todos los ciclos de vida FL-2.1.2 (K1) de desarrollo del software. FL-2.1.3 (K1) Recordar los ejemplos de enfoques de prueba primero para el desarrollo. FL-2.1.4 (K2) Resumir cómo DevOps puede tener un impacto en la prueba. FL-2.1.5 (K2) Explicar el enfoque de desplazamiento a la izquierda. 2 Las palabras clave se encuentran ordenadas por orden alfabético de los términos en inglés. International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board Explicar cómo se pueden utilizar las retrospectivas como mecanismo para la mejora FL-2.1.6 (K2) del proceso. 2.2 Niveles de Prueba y Tipos de Prueba FL-2.2.1 (K2) Distinguir los diferentes niveles de prueba. FL-2.2.2 (K2) Distinguir los diferentes tipos de prueba. FL-2.2.3 (K2) Distinguir la prueba de confirmación de la prueba de regresión. 2.3 Prueba de Mantenimiento FL-2.3.1 (K2) Resumir la prueba de mantenimiento y sus desencadenantes. Versión 4.0 Página 28 de 87 21 de abril de 2023 © International Software Testing Qualifications Board International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board 2.1 La Prueba en el Contexto de un Ciclo de Vida de Desarrollo de Software Un modelo de ciclo de vida de desarrollo de software (CVDS) es una representación abstracta y de alto nivel del proceso de desarrollo de software. Un modelo CVDS define cómo se relacionan entre sí, tanto lógica como cronológicamente, las diferentes fases de desarrollo y los tipos de actividades que se realizan dentro de este proceso. Algunos ejemplos de modelos de CVDS son: los modelos de desarrollo secuencial (por ejemplo, el modelo en cascada, el modelo V), los modelos de desarrollo iterativo (por ejemplo, el modelo en espiral, el prototipado) y los modelos de desarrollo incremental (por ejemplo, el Proceso Unificado). Algunas actividades de los procesos de desarrollo de software también pueden describirse mediante métodos de desarrollo de software más detallados y prácticas Ágiles. Algunos ejemplos son: el desarrollo guiado por pruebas de aceptación (DGPA), el desarrollo guiado por el comportamiento (DGC), el diseño guiado por dominios (DGD), la programación extrema (XP), el desarrollo guiado por prestaciones (DGP), Kanban, Lean IT, Scrum y el desarrollo guiado por pruebas (DGP). 2.1.1 Impacto del Ciclo de Vida de Desarrollo de Software en la Prueba La prueba debe adaptarse al CVDS para tener éxito. La elección del CVDS repercute en: Alcance y cronología de las actividades de prueba (por ejemplo, niveles de prueba y tipos de prueba). Nivel de detalle de la documentación de prueba. Elección de técnicas de prueba y enfoque de prueba. Alcance de la automatización de la prueba. Rol y responsabilidades de un probador. En las fases iniciales de los modelos de desarrollo secuencial, los probadores suelen participar en la revisión de requisitos, el análisis de prueba y el diseño de prueba. El código ejecutable suele crearse en las fases posteriores, por lo que normalmente la prueba dinámica no puede realizarse al principio del CVDS. En algunos modelos de desarrollo iterativo e incremental, se supone que cada iteración entrega un prototipo funcional o un incremento del producto. Esto implica que en cada iteración se puede probar tanto estática como dinámicamente en todos los niveles de prueba. La entrega frecuente de incrementos requiere una retroalimentación rápida y pruebas de regresión extensivas. El desarrollo de software Ágil asume que pueden producirse cambios a lo largo de todo el proyecto. Por lo tanto, en los proyectos ágiles se favorece una documentación de producto de trabajo ligera y una amplia automatización de la prueba para facilitar la prueba de regresión. Además, la mayor parte de las pruebas manuales suelen realizarse mediante técnicas de prueba basadas en la experiencia (véase la sección 4.4) que no requieren un análisis y diseño de prueba previos exhaustivos. 2.1.2 Ciclo de Vida de Desarrollo de Software y Buenas Prácticas de Prueba Las buenas prácticas de prueba, independientemente del modelo de CVDS elegido, incluyen los siguientes elementos: Cada actividad de desarrollo de software tiene su correspondiente actividad de prueba, de modo que todas las actividades de desarrollo están sujetas a un control de la calidad. Versión 4.0 Página 29 de 87 21 de abril de 2023 © International Software Testing Qualifications Board International Probador Certificado del ISTQB ® Software Testing Programa de Estudio – Nivel Básico Qualifications Board Cada nivel de prueba (véase el capítulo 2.2.1) tiene objetivos de prueba específicos y diferentes, lo que permite que las pruebas sean lo suficientemente comprensivas a la vez que se evita la redundancia. El análisis y diseño de prueba para un nivel de prueba determinado comienza durante la fase de desarrollo correspondiente del CVDS, para que la prueba pueda atenerse al principio de prueba temprana (véase la sección 1.3). Los probadores participan en la revisión de los productos de trabajo tan pronto como están disponibles los borradores de esta documentación, para que esta prueba temprana y la detección de defectos puedan apoyar la estrategia de desplazamiento a la izquierda (véase la sección 2.1.5). 2.1.3 La Prueba como Impulsor del Desarrollo de Software Desarrollo guiado por prueba (DGP), desarrollo guiado por prueba de aceptación (DGPA) y desarrollo guiado por el comportamiento (DGC son enfoques de desarrollo similares, en los que las pruebas se definen como un medio para conducir el desarrollo. Cada uno de estos enfoques aplica el principio de la prueba temprana (véase el apartado 1.3) y sigue un planteamiento de desplazamiento a la izquierda (véase el apartado 2.1.5), ya que las pruebas se definen antes de escribir el código. Apoyan un modelo de desarrollo iterativo. Estos enfoques se caracterizan por lo siguiente: Desarrollo Guiado por Prueba (DGP): Dirige la codificación mediante casos de prueba (en lugar de un diseño extensivo del software) (Beck 2003). Primero se redactan las pruebas, luego se elabora el código para que satisfaga las pruebas y, por último, se refactorizan las pruebas y el código. Desarrollo Guiado por Prueba de Aceptación (DGPA) (véase el apartado 4.5.3): Obtiene pruebas a partir de criterios de aceptación como parte del proceso de diseño del sistema (Gärtner 2011). Las pruebas se redactan antes de que la parte de la aplicación se desarrolle para satisfacer las pruebas. Desarrollo Guiado por Comportamiento (DGC): Expresa el comportamiento deseado de una aplicación con casos de prueba escritos en una forma sencilla de lenguaje natural, que es fácil de entender por los implicados - normalmente utilizando el formato Dado/Cuando/Entonces (“Given/When/Then”). (Chelimsky 2010) A continuación, los casos de prueba se traducen automáticamente en pruebas ejecutables. En todos los enfoques anteriores, las prueba

Programa de Estudio - Probador Certificado de ISTQB® - V4.0 PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue