ISTQB CTFL v 4.0 by GeekQA.net

1. 1. Fundamentos del Proceso de prueba

1.1. 1.1 ¿Qué es probar?

1.1.1. 1.1.0 Que es probar?

1.1.1.1. Las prueba nos ayudan a evaluar la calidad del software y a reducir el riesgo de fallo del software en operación.

1.1.1.1.1. Un producto erroneo causa muchos problemas, perdida de dinero, reputación, tiempo, lesiones o muerte

1.1.1.2. La prueba de software es un conjunto de actividades para descubrir defectos y evaluar la calidad de los artefactos de software

1.1.1.3. Las pruebas no solo se centran en la verificación de requisitos, tambien implica la validación de si el sistema es capaz de satisfacer las necesidades del usuario

1.1.1.4. Formas de probar

1.1.1.4.1. Las pruebas dinámicas implican la ejecución del componente o sistema que se esta probando

1.1.1.4.2. Las pruebas estáticas no implican ejecución (ejm. revisiones)

1.1.1.5. Probar no es sólo una actividad técnica.

1.1.1.5.1. También necesita que se planifique, gestione, estime, monitorice y controle de forma adecuada

1.1.1.5.2. No solo se utilizan herramientas, se trata de una actividad intelectual, analiticas y pensamiento critico

1.1.2. 1.1.1 Objetivos de la prueba

1.1.2.1. Evaluar productos de trabajo tales como requisitos,historias de usuario, diseño y codigo

1.1.2.2. Verificar el cumplimiento de todos los requisitos especificados

1.1.2.3. Validar si el objeto de prueba está completo y funciona como los usuarios y otros implicados esperen

1.1.2.4. Generar confianza en el nivel de calidad del objeto de prueba.

1.1.2.5. Prevenir defectos***

1.1.2.6. Encontrar fallos y defectos.

1.1.2.7. Proporcionar suficiente información a los implicados para que puedan tomar decisiones informadas

1.1.2.8. Reducir el nivel de riesgo de calidad del software

1.1.2.9. Cumplir con requisitos o normas contractuales, legales o reglamentarias

1.1.3. 1.1.2 Probar y depurar

1.1.3.1. Las Pruebas pueden mostrar fallos causados por defectos en el software.

1.1.3.2. La Depuración es la actividad de desarrollo que encuentra, analiza y corrige dichos defectos

1.2. 1.2 ¿Por qué es Necesario Probar?

1.2.1. 1.2.1 Contribuciones de la Prueba al Éxito

1.2.1.1. Eficiencia en la Detección de Defectos:

1.2.1.1.1. La prueba es un medio rentable para identificar defectos en objetos de prueba.

1.2.1.1.2. La depuración posterior elimina estos defectos, mejorando indirectamente la calidad de los objetos de prueba.

1.2.1.2. Evaluación de Calidad en Diferentes Etapas:

1.2.1.2.1. Las pruebas permiten evaluar directamente la calidad en diversas etapas del ciclo de vida del desarrollo de software (CVDS).

1.2.1.3. Representación Indirecta de Usuarios:

1.2.1.3.1. Los probadores aseguran la consideración de las necesidades de los usuarios a lo largo del desarrollo.

1.2.1.3.2. La prueba proporciona una alternativa eficaz a implicar a usuarios, evitando costos y problemas de disponibilidad.

1.2.1.4. Cumplimiento de Requisitos y Estándares:

1.2.1.4.1. Las pruebas pueden ser necesarias para cumplir requisitos contractuales, legales o estándares reglamentarios en el proyecto.

1.2.2. 1.2.2 Prueba y Aseguramiento de la Calidad (AC)

1.2.2.1. Diferencia entre Prueba y Aseguramiento de la Calidad (AC):

1.2.2.1.1. Aunque a menudo se usan indistintamente, prueba y AC no son equivalentes.

1.2.2.1.2. La prueba se clasifica como una forma de Control de Calidad (CC), siendo un enfoque correctivo orientado al producto.

1.2.2.2. Enfoques de Control de Calidad y Aseguramiento de la Calidad:

1.2.2.2.1. El Control de Calidad (CC) se centra en corregir defectos para alcanzar niveles de calidad, utilizando diversas formas, como la prueba y métodos formales.

1.2.2.2.2. El Aseguramiento de la Calidad (AC) es preventivo, concentrándose en la implementación y mejora de procesos para generar un buen producto.

1.2.2.3. Aplicación de la Garantía de Calidad:

1.2.2.3.1. La Garantía de Calidad se aplica tanto al proceso de desarrollo como al de prueba, siendo responsabilidad de todos los participantes.

1.2.2.3.2. Los resultados de la prueba se utilizan en el CC para corregir defectos y en el AC para proporcionar retroalimentación sobre el rendimiento de los procesos de desarrollo y prueba.

1.2.3. 1.2.3 Errores, Defectos y Fallos

1.2.3.1. Los errores humanos son inevitables y conducen a la creación de defectos en el trabajo.

1.2.3.1.1. Desarrollador se equivoca en el codigo , esta haciendo la operacion multiplicacion para una calculadora y en vez de poner operador * pone el de division / en el codigo (equivocacion)

1.2.3.2. Los errores ocurren debido a factores como la presión de tiempo, la complejidad de los productos o procesos, la infraestructura, las interacciones y la falta de formación.

1.2.3.3. Los defectos resultantes de errores pueden generar fallos, afectando la calidad del trabajo o productos.

1.2.3.3.1. La calculadora se daña cuando un usuario intenta multiplicar 5 *0 y en vez de esto la calculadora hace 5/0 lo cual genera un falla. (Efecto)

1.3. 1.3 Principios de la Prueba

1.3.1. 1. La prueba muestra la presencia de defectos, no su ausencia

1.3.1.1. Yo pruebo una app y encuentro defectos, pero si no los encuentro nada no puedo afirmar que no hay

1.3.2. 2. La prueba exhaustiva es imposible

1.3.2.1. ejemplo: 1+1 , 1+2 , 1+3 ,....

1.3.2.2. Probarlo todo no es factible, en vez de eso se debe priorizar casos o hacer pruebas basadas en riesgo

1.3.3. 3. La prueba temprana ahorra tiempo y dinero

1.3.3.1. Los defectos que se eliminan al principio del proceso no causarán defectos posteriores en los productos de trabajo derivados

1.3.4. 4. Los defectos se agrupan

1.3.4.1. 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. Ley de pareto 80/20

1.3.5. 5. Las pruebas se desgastan. (paradoja del pesticida)

1.3.5.1. Si las pruebas se repiten muchas veces, se vuelven cada vez más ineficaces para detectar nuevos defectos

1.3.6. 6. La prueba depende del contexto

1.3.6.1. No existe un único enfoque de prueba aplicable universalmente.

1.3.7. 7. La ausencia de errores es una falacia

1.3.7.1. es falso esperar que la verificación del software asegure el éxito de un sistema

1.4. 1.4 Actividades de prueba, productos y roles

1.4.1. 1.4.1 Actividades y Tareas de pruebas

1.4.1.1. Planificacion de la prueba

1.4.1.1.1. Objetivos , enfoque de la prueba, restricciones (tiempo, recursos etc)

1.4.1.2. Monitorizacion de la prueba

1.4.1.2.1. Avance con respecto al plan de pruebas

1.4.1.2.2. Evaluación de criterios de salida (DoD)

1.4.1.3. Analisis de la prueba

1.4.1.3.1. Que vamos a probar?, especificaciones, interfaces, bases de datos , riesgos

1.4.1.4. Diseño de la prueba

1.4.1.4.1. ¿cómo llevar a cabo la prueba?".

1.4.1.4.2. Diseño de casos y test suites

1.4.1.4.3. Identificar datos de prueba

1.4.1.4.4. Diseñar entorno de pruebas

1.4.1.5. Implementación y ejecución de la prueba

1.4.1.5.1. Esta todo listo para probar?

1.4.1.5.2. Comparacion de resultados reales vs esperados

1.4.1.5.3. Analizar anomalias y reportar bugs

1.4.1.5.4. Registrar resultado de las pruebas

1.4.1.6. Compleción de las pruebas

1.4.1.6.1. Consolidar resultados, informe de cierre, # de bugs encontrados etc

1.4.1.6.2. Verificar todos los bugs estan cerrados

1.4.1.6.3. Notificar a los involucrados de los resultados de las pruebas

1.4.1.6.4. Almacenar la informacion recopilada para uso futuro y mejora de todo el proceso de pruebas

1.4.2. 1.4.2 El Proceso de Prueba en Contexto

1.4.2.1. la forma en que se lleve a cabo la prueba dependerá de una serie de factores contextuales entre los que se incluyen:

1.4.2.1.1. Implicados

1.4.2.1.2. Miembros del equipo (competencias, conocimientos, nivel de experiencia, disponibilidad, necesidades de formación, etc.)

1.4.2.1.3. Dominio del negocio (

1.4.2.1.4. Factores técnicos

1.4.2.1.5. Restricciones del proyecto

1.4.2.1.6. Factores organizativos

1.4.2.1.7. Ciclo de vida de desarrollo del software

1.4.2.1.8. Herramientas

1.4.3. 1.4.3 Productos de Prueba (artefactos)

1.4.3.1. **Producto de Planeación:** Uno o mas planes de prueba

1.4.3.2. **Producto de Monitoreo **: Informes de avance,

1.4.3.3. **Producto de analisis** :criterios de aceptación

1.4.3.4. **Producto de diseño:** casos de prueba, requisitos de datos de prueba etc.

1.4.3.5. **Producto de Implementacion y Ejecucion:** Suites de prueba, resultados de prueba, reportes de prueba, reporte de defectos y documentación

1.4.3.6. **Producto de ejecucion:** informe de defectos

1.4.3.7. **Producto de compleción:** informa de cierre

1.4.4. 1.4.4 Trazabilidad entre Bases de Prueba y Productos de Prueba

1.4.4.1. La implementación efectiva de monitoreo y control en las pruebas requiere establecer y mantener una trazabilidad precisa entre los elementos de la base de prueba, productos de prueba, resultados y defectos detectados.

1.4.4.2. La trazabilidad facilita la evaluación de la cobertura

1.4.4.3. Además de evaluar la cobertura, una buena trazabilidad permite evaluar el impacto de cambios, facilita auditorías, cumple criterios de gobernanza de TI y mejora la comprensión de informes, proporcionando información valiosa para evaluar la calidad del producto y el progreso del proyecto.

1.4.5. 1.4.5 Roles de prueba

1.4.5.1. Gestion de prueba

1.4.5.1.1. actividades de planificación de pruebas

1.4.5.1.2. monitorización y control de prueba

1.4.5.1.3. puede ser realizado por el jefe del equipo, jefe de dllo etc

1.4.5.2. Rol de prueba

1.4.5.2.1. parte tecnica de la prueba

1.4.5.2.2. analisis de prueba, diseño, implementación y ejecución

1.5. 1.5 Competencias de las pruebas y buenas practicas

1.5.1. 1.5.1 Competencias Genéricas Necesarias para Probar

1.5.1.1. Conocimientos en testing

1.5.1.2. Curiosidad, atencion a detalles

1.5.1.3. Pensamiento analitico

1.5.1.4. conocimientos técnicos

1.5.1.5. conocimientos del dominio

1.5.2. 1.5.2 Enfoque de Equipo Completo

1.5.2.1. todos en el equipo agíl son responsables de la calidad!

1.5.2.2. los QAs trabajan estrechamente con todos los miembros del equipos para alcanzar los niveles deseados

1.5.2.2.1. UAT testers

1.5.2.2.2. desarrolladores

1.5.2.2.3. BAs

1.5.3. 1.5.3 Independencia de la Prueba

1.5.3.1. el software pueden ser probados por su autor

1.5.3.2. software puede ser probado por los compañeros del autor del mismo equipo

1.5.3.3. puede ser probado por probadores ajenos al equipo

2. 2. Prueba a lo largo del Ciclo de vide desarrollo de software. SDLC

2.1. 2.1 La Prueba en el Contexto de un Ciclo de Vida de Desarrollo de Software

2.1.1. 2.1.1 Impacto del Ciclo de Vida de Desarrollo de Software en la Prueba

2.1.1.1. La prueba debe adaptarse al SDLC para tener éxito.

2.1.1.1.1. repercuten en

2.1.1.1.2. en modelos secuenciales

2.1.1.1.3. en modelos iterativos

2.1.2. 2.1.2 Ciclo de Vida de Desarrollo de Software y Buenas Prácticas de Prueba

2.1.2.1. buenas practicas

2.1.2.1.1. Cada actividad de desarrollo de software tiene su correspondiente actividad de prueba

2.1.2.1.2. Cada nivel de prueba tiene objetivos de prueba específicos y diferentes

2.1.2.1.3. El análisis y diseño de prueba para un nivel de prueba determinado comienza durante la fase de desarrollo correspondiente

2.1.2.1.4. Los probadores participan en la revisión de los productos de trabajo tan pronto como están disponibles los borradores de esta documentación,

2.1.3. 2.1.3 La Prueba como Impulsor del Desarrollo de Software

2.1.3.1. Desarrollo Guiado por Prueba (TDD)

2.1.3.1.1. Dirige la codificación mediante casos de prueba

2.1.3.1.2. 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.

2.1.3.2. Desarrollo Guiado por Prueba de Aceptación

2.1.3.2.1. Obtiene pruebas a partir de criterios de aceptación como parte del proceso de diseño del sistema

2.1.3.3. Desarrollo Guiado por Comportamiento (BDD)

2.1.3.3.1. 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

2.1.3.3.2. A continuación, los casos de prueba se traducen automáticamente en pruebas ejecutables

2.1.4. 2.1.4 DevOps y la Prueba

2.1.4.1. permite a los equipos construir, probar y entregar codigo de alta calidad mas rapidamente.

2.1.4.2. ventajas de devops en testing

2.1.4.2.1. Rápida retroalimentación sobre la calidad del código y

2.1.4.2.2. La integración continua IC promueve un enfoque de desplazamiento a la izquierda

2.1.4.2.3. Promueve procesos automatizados como CI/CD que facilitan el establecimiento de entornos de prueba estables.

2.1.4.2.4. Aumenta la visión sobre las características de calidad no funcionales

2.1.4.2.5. La automatización a través de un canal de entrega reduce la necesidad de pruebas manuales repetitivas.

2.1.4.2.6. El riesgo en la regresión se minimiza gracias a la escala y el alcance de las pruebas de regresión automatizadas.

2.1.5. 2.1.5 Enfoque “Desplazamiento a la Izquierda”

2.1.5.1. El principio de prueba temprana

2.1.5.1.1. Utilizar integración continua (IC) e incluso mejor entrega continua

2.1.5.1.2. Completar el análisis estático del código fuente antes de la prueba dinámica, o como parte de un proceso automatizado.

2.1.5.1.3. Realizar pruebas no funcionales empezando en el nivel de prueba de componente,

2.1.5.2. Un enfoque de desplazamiento a la izquierda puede dar lugar a formación, esfuerzo y/o costes adicionales al principio del proceso, pero se espera que ahorre esfuerzos y/o costes con posterioridad.

2.1.6. 2.1.6 Retrospectivas y Mejora de Proceso

2.1.6.1. Las retrospectivas son fundamentales para el éxito de la implementación de la mejora continua y es importante que se haga un seguimiento de cualquier mejora recomendada.

2.1.6.1.1. beneficios

2.2. 2.2 Niveles de Prueba y tipos de prueba

2.2.1. 2.2.1 Niveles de prueba

2.2.1.1. Prueba de Componente (unitarias)

2.2.1.1.1. Objetivo especifico

2.2.1.2. Prueba de Integración

2.2.1.2.1. Objetivo de las pruebas

2.2.1.3. Prueba de Sistema

2.2.1.3.1. Objetivos de la Prueba de Sistema

2.2.1.4. Prueba de Aceptación

2.2.1.4.1. Objetivos de la Prueba de Aceptación

2.2.2. 2.2.2 Tipos de Prueba

2.2.2.1. Prueba Funcional

2.2.2.1.1. Evalúan las funciones que el sistema debe realizar

2.2.2.1.2. Se deben realizar en todos los niveles de prueba

2.2.2.1.3. Utiliza técnicas de caja negra

2.2.2.2. Prueba No Funcional

2.2.2.2.1. Evalúa las características de los sistemas y software (Que tan bien se comporta)

2.2.2.2.2. Se deben realizar tan pronto como sea posible

2.2.2.2.3. El estándar ISO/IEC 25010 clasifica las caracteristicas de calidad e producto de software

2.2.2.3. Pruebas de caja negra

2.2.2.3.1. El objetivo principal de la prueba de caja negra es comprobar el comportamiento del sistema frente a sus especificaciones.

2.2.2.4. Prueba de Caja Blanca

2.2.2.4.1. Pruebas basadas en la estructura interna del sistema

2.2.2.4.2. El objetivo principal de la prueba de caja blanca es que las pruebas cubran la estructura subyacente hasta un nivel aceptable.

2.2.2.5. Los cuatro tipos de prueba mencionados pueden aplicarse a todos los niveles de prueba, aunque el enfoque será diferente en cada nivel.

2.2.3. 2.2.3 Prueba de Confirmación y Prueba de Regresión

2.2.3.1. Prueba de confirmación

2.2.3.1.1. Confirma que el defecto original se ha solucionado de forma satisfactoria

2.2.3.2. Prueba de regresión

2.2.3.2.1. Las regresiones son efectos secundarios no deseados debido a los cambios (codigo, entorno, base de datos)

2.2.3.2.2. Fuerte candidato para la automatización

2.2.3.3. Consideraciones

2.2.3.3.1. Se necesita una prueba de confirmación y/o una prueba de regresión para el objeto de prueba en todos los niveles de prueba si se corrigen defectos y/o se realizan cambios en estos niveles de prueba.

2.3. 2.3 Prueba de Mantenimiento

2.3.1. Análisis de Impacto para el mantenimiento

2.3.1.1. Identifica el impacto de un cambio en las pruebas existentes

2.3.1.2. Identifica las áreas del sistema que se veran afectadas por el cambio

2.3.2. Activadores para pruebas de Mantenimiento

2.3.2.1. Modificación

2.3.2.1.1. Mejoras planificadas

2.3.2.1.2. Cambios correctivos

2.3.2.1.3. Cambios de emergencia

2.3.2.2. Actualizaciones o Migraciones

2.3.2.2.1. De una plataforma a otra

2.3.2.2.2. De datos

2.3.2.3. Retirada

2.3.2.3.1. Comprobación de la migración de datos

2.3.2.3.2. Procedimientos de restauración/recuperación

3. 3. Prueba Estática

3.1. 3.1 Fundamentos

3.1.1. Introducción

3.1.1.1. Revisiones - evaluación manual de los producto de trabajo

3.1.1.2. Análisis Estático - evaluación basada en herramientas del codigo

3.1.2. 3.1.1 Productos de Trabajo que Pueden ser evaluados por pruebas estaticas

3.1.2.1. Especificaciones, incluidos requisitos de negocio, requisitos funcionales y requisitos de seguridad

3.1.2.2. Épicas, historias de usuarios y criterios de aceptación

3.1.2.3. Especificaciones de arquitectura y diseño

3.1.2.4. Código.

3.1.2.5. Contratos, planes de proyecto, calendarios y presupuestos

3.1.3. 3.1.2 Valor de la Prueba Estática

3.1.3.1. Detección y corrección de defectos de forma más eficiente y antes de la ejecucion de la prueba dinamica

3.1.3.2. Identificar defectos que no se encuentran facilmente mediante prueba dinamica

3.1.3.3. Incrementar la productividad de desarrollo

3.1.3.4. Reducir el coste y el tiempo de desarrollo

3.1.4. 3.1.3 Diferencias entre la Prueba Estática y dinamica

3.1.4.1. La prueba estática detecta defectos en los productos de trabajo directamente en lugar de identificar los fallos

3.1.4.2. La prueba estática puede ser capaz de encontrar el defecto con un esfuerzo mucho menor

3.1.4.3. Defectos tipicos

3.1.4.3.1. Defectos en los requisitos

3.1.4.3.2. Defectos de diseño

3.1.4.3.3. Defectos de codificación

3.1.4.3.4. Desviaciones con respecto a estándares

3.1.4.3.5. Vulnerabilidades de seguridad

3.2. 3.2 Retroalimentación y Proceso de Revisión

3.2.1. 3.2.1 Beneficios de una Retroalimentación Temprana y Frecuente de los Implicados

3.2.1.1. permite la comunicación temprana de posibles problemas de calidad

3.2.1.2. Requiere comprosimo por parte de los implicados en las definiciones

3.2.1.3. evitar malentendidos sobre los requisitos

3.2.1.4. Corregir e Informar

3.2.2. 3.2.2 Actividades del Proceso de Revisión

3.2.2.1. planificación

3.2.2.2. inicia revisión

3.2.2.3. revisión individual

3.2.2.4. comunicación y analisis de cuestiones

3.2.2.5. corregir e informar

3.2.3. 3.2.3 Roles y Responsabilidades en una revison formal

3.2.3.1. Gestor

3.2.3.2. Autor

3.2.3.3. Moderador

3.2.3.4. Escriba

3.2.3.5. Revisor

3.2.3.6. Lider de la revisión

3.2.4. 3.2.4 Tipos de Revisión

3.2.4.1. Revisión Informal

3.2.4.1.1. no siguen un proceso definido,objetivo es detectar anomalías

3.2.4.2. Revisión Guiada

3.2.4.2.1. Objetivos principales: detectar defectos, mejorar el producto software, considerar implementaciones alternativas

3.2.4.3. Revisión Técnica

3.2.4.3.1. Los revisores deben ser pares técnicos del autor y expertos tecnicos en la misma u otra disciplina

3.2.4.4. Inspección

3.2.4.4.1. revision muy formal, sigue un proceso generico completo.

3.2.5. 3.2.5 Factores de Éxito para las Revisiones

3.2.5.1. La definición de objetivos claros y criterios de salida medibles.

3.2.5.2. Elegir el tipo de revisión adecuado para alcanzar los objetivos fijados

3.2.5.3. Realizar las revisiones en pequeños fragmentos, para que los revisores no pierdan la concentración durante una revisión individual

3.2.5.4. Proporcionar retroalimentación de las revisiones a los implicados y a los autores para que puedan mejorar el producto y sus actividades

3.2.5.5. Proporcionar tiempo suficiente a los participantes para prepararse para la revisión.

4. 4. Análisis y Diseño de la Prueba

4.1. 4.1 Introducción a las Técnicas de Prueba

4.1.1. Elección de Técnicas de Prueba

4.1.1.1. Factores

4.1.1.1.1. Tipo de componente o sistema

4.1.1.1.2. Complejidad del componente

4.1.1.1.3. Estándares de regulación

4.1.1.1.4. Niveles de riesgo

4.1.1.1.5. Documentación disponible

4.1.1.1.6. Herramientas disponibles

4.1.1.1.7. Modelo de ciclo de vida de desarrollo de software

4.1.2. Se clasifican en

4.1.2.1. Técnicas de prueba de la caja negra (basadas en la especificación)

4.1.2.1.1. Base de prueba

4.1.2.2. Técnicas de prueba de caja blanca (basadas en la estructura)

4.1.2.2.1. Base de prueba

4.1.2.3. Técnicas de prueba basadas en la experiencia

4.1.2.3.1. Base de prueba

4.2. 4.2 Técnicas de Prueba de Caja Negra

4.2.1. 4.2.1 Partición de Equivalencia

4.2.1.1. Divide los datos en particiones

4.2.1.2. Existen particiones de equivalencia tanto para valores validos como no validos

4.2.2. 4.2.2 Análisis de Valores Frontera (AVF)

4.2.2.1. Extensión de la partición de equivalencia

4.2.2.2. Solo si la partición consiste en datos numéricos o secuenciales

4.2.2.3. Los valores mínimo y máximo de una partición son sus valores frontera

4.2.2.4. El comportamiento en las fronteras de las particiones de equivalencia es más probable que sea incorrecto que el comportamiento dentro de las particiones

4.2.3. 4.2.3 Técnica de Tabla de Decisión

4.2.3.1. Útiles para probar la implementación de requisitos de sistema que especifican cómo diferentes combinaciones de condiciones generan diferentes resultados

4.2.3.2. el probador identifica las condiciones (a menudo entradas) y las acciones resultantes (a menudo salidas)

4.2.3.3. Una tabla de decisión completa tiene suficientes columnas para cubrir cada combinación de condiciones

4.2.4. 4.3.4 Técnica de Transición de Estado

4.2.4.1. Elementos

4.2.4.1.1. Estado:

4.2.4.1.2. Transicion

4.2.4.1.3. Evento

4.2.4.1.4. Accion

4.2.4.2. Un diagrama de transición de estado muestra

4.2.4.2.1. Los posibles estados del software,

4.2.4.2.2. La forma en que el software entra, sale y realiza las transiciones entre estados

4.2.4.3. Una tabla de transición de estado muestra

4.2.4.3.1. Todas las transiciones válidas

4.2.4.3.2. las transiciones potencialmente inválidas entre estados

4.2.4.3.3. Los eventos

4.2.4.3.4. Condiciones de guarda

4.2.4.3.5. Las acciones resultantes para las transiciones válidas

4.2.4.4. Utilización

4.2.4.4.1. Cobertura: % del Número de estados o transiciones identificados probados, dividido por el número total de estados o transiciones identificados en el objeto de prueba

4.3. 4.3 Técnicas de Prueba de Caja Blanca

4.3.1. 4.3.0 Caracteristicas

4.3.1.1. Se basan en la estructura interna del objeto de prueba

4.3.1.2. Se pueden utilizar en todos los niveles de prueba

4.3.2. 4.3.1 Prueba de Sentencia y Cobertura de Sentencia

4.3.2.1. Practica las sentencias ejecutables en el código

4.3.2.2. cobertura : % de número de sentencias ejecutadas por las pruebas dividido por el número total de sentencias ejecutables en el objeto de prueba

4.3.2.3. Ejemplo

4.3.3. 4.3.2 Prueba de Rama y Cobertura de Rama

4.3.3.1. los elementos de cobertura son las ramas y el objetivo es diseñar casos de prueba que permitan practicar las ramas del código hasta alcanzar un nivel de cobertura aceptable

4.3.3.2. Los casos de prueba siguen los flujos de control que se producen desde un punto de decisión

4.3.3.3. Cobertura:% del número de resultados de decisión ejecutados por las pruebas dividido por el número total de resultados de decisión en el objeto de prueba

4.3.4. 4.3.3 El valor de la Prueba de Caja Blanca

4.3.4.1. puntos fuertes

4.3.4.1.1. durante las pruebas se tiene en cuenta toda la implementación del software, lo que facilita la detección de defectos incluso cuando la especificación del software es vaga, obsoleta o incompleta

4.3.4.2. puntos debiles

4.3.4.2.1. si el software no implementa uno o más requisitos, la prueba de caja blanca puede no detectar los defectos de omisión resultantes

4.4. 4.4 Técnicas de Prueba Basadas en la Experiencia

4.4.1. 4.4.1 Predicción de Errores

4.4.1.1. Utilizada para anticipar la ocurrencia de errores, defectos y fallos, basada en el conocimiento del probador

4.4.1.2. Las pruebas se diseñan en base a una lista creada de posibles errores, defectos y fallos.

4.4.2. 4.4.2 Prueba Exploratoria

4.4.2.1. Se diseñan, ejecutan, registran y evalúan de forma dinámica pruebas informales (no predefinidas) durante la ejecución de la prueba

4.4.2.2. Se utiliza la prueba basada en sesiones para estructurar la actividad

4.4.2.3. Puede incorporar el uso de otras técnicas de caja negra, caja blanca y basadas en la experiencia

4.4.3. 4.4.3 Prueba Basada en Listas de Comprobación

4.4.3.1. Los probadores diseñan, implementan y ejecutan pruebas para cubrir las condiciones de prueba que se encuentran en una lista de comprobación

4.4.3.2. Las listas de comprobación pueden elaborarse basándose en la experiencia

4.4.3.3. Dan soporte pruebas funcionales y no funcionales

4.4.3.4. Proporciona directrices y un cierto grado de consistencia a falta de casos de prueba

4.5. 4.5 Enfoques de Prueba Basados en la Colaboración

4.5.1. se concentran también en evitar defectos mediante la colaboración y la comunicación

4.5.2. 4.5.1 Redacción Colaborativa de Historias de Usuario

4.5.2.1. Las buenas historias de usuario deben ser: Independientes, Negociables, Valiosas, Estimables, Pequeñas y Comprobables (INVEST)

4.5.3. 4.5.2 Criterios de Aceptación

4.5.3.1. • Definir el alcance de la historia de usuario.

4.5.3.2. Alcanzar un consenso entre los implicados.

4.5.3.3. • Describir escenarios positivos y negativos.

4.5.3.4. Permitir una planificación y estimación precisas.

4.5.4. 4.5.3 Desarrollo Guiado por Prueba de Aceptación

4.5.4.1. Los casos de prueba se crean antes de la implementación de la historia de usuario.

4.5.4.2. Los casos de prueba pueden ejecutarse de forma manual o automatizada

5. 5 Gestión de las Actividades de Prueba

5.1. 5.1 Planificación de la Prueba

5.1.1. 5.1.1 Propósito y Contenido de un Plan de Prueba

5.1.1.1. Un plan de prueba describe los objetivos, los recursos y los procesos de un proyecto de prueba.

5.1.1.2. plan de prueba incluye

5.1.1.2.1. Contexto de la prueba (por ejemplo, alcance, objetivos de la prueba, restricciones, base de prueba).

5.1.1.2.2. Supuestos y restricciones del proyecto de prueba.

5.1.1.2.3. Implicados (por ejemplo, roles, responsabilidades, relevancia para las pruebas, necesidades de contratación y formación).

5.1.1.2.4. Comunicación (por ejemplo, formas y frecuencia de la comunicación, plantillas de documentación).

5.1.1.2.5. Registro de riesgos (por ejemplo, riesgos de producto, riesgos de proyecto).

5.1.1.2.6. Enfoque de prueba (por ejemplo, niveles de prueba, tipos de prueba, técnicas de prueba, entregables de prueba, criterios de entrada y criterios de

5.1.2. 5.1.2 Contribución del Probador a la planificación de la Iteración y de la Entrega

5.1.2.1. Planificacion de la prueba

5.1.2.1.1. define y redefine la lista de trabajo acumulado del producto y puede implicar refinar las historias de usuario más grandes en un conjunto de historias de usuario más pequeñas.

5.1.2.1.2. También sirve de base para el enfoque de prueba y el plan de prueba de todas las iteraciones.

5.1.2.2. planificación de la iteracion

5.1.2.2.1. se ocupa de la lista de trabajo acumulado de la iteración

5.1.3. 5.1.3 Criterios de Entrada y Criterios de Salida

5.1.3.1. criterios de entrada

5.1.3.1.1. disponibilidad de recursos (por ejemplo, personas, herramientas, entornos

5.1.3.1.2. datos de prueba

5.1.3.1.3. tiempo

5.1.3.1.4. historias de usuario,

5.1.3.2. criterios de salida

5.1.3.2.1. densidad de defectos

5.1.3.2.2. número de casos de prueba fallidos)

5.1.3.2.3. se han automatizado todas las pruebas de regresión

5.1.3.2.4. DoD

5.1.4. 5.1.4 Técnicas de Estimación

5.1.4.1. Estimación basada en proporciones.

5.1.4.1.1. se recopilan cifras de proyectos anteriores de la organización, lo que permite obtener proporciones "estándar"

5.1.4.2. Extrapolación

5.1.4.2.1. el equipo puede extrapolar el esfuerzo de prueba en la próxima iteración como el esfuerzo medio de las tres últimas iteraciones.

5.1.4.3. Delphi de Banda Ancha.

5.1.4.3.1. iterativa basada en la experiencia, los expertos realizan estimaciones basadas en la experiencia

5.1.4.3.2. El póker de planificación es una variante del Delphi de Banda Ancha

5.1.4.4. Estimación de tres puntos.

5.1.4.4.1. técnica basada en expertos, éstos realizan tres estimaciones

5.1.5. 5.1.5 Priorización de Casos de Prueba

5.1.5.1. Priorización basada en el riesgo,

5.1.5.2. Priorización basada en la cobertura

5.1.5.3. Priorización basada en requisitos

5.1.6. 5.1.6 Pirámide de Prueba

5.1.6.1. El modelo de pirámide de prueba apoya al equipo en la automatización de la prueba y en la asignación del esfuerzo

5.1.6.2. Cuanto más alta es la capa, menor es la granularidad de la prueba

5.1.6.3. Las pruebas de la capa inferior son pequeñas, aisladas, rápidas y comprueban una pequeña parte de la funcionalidad

5.1.7. 5.1.7 Cuadrantes de Prueba

5.1.7.1. agrupan los niveles de prueba con los tipos de prueba, actividades, técnicas de prueba y productos de trabajo

5.1.7.1.1. Cuadrante Q1 (orientado a la tecnología, apoya al equipo).

5.1.7.1.2. Cuadrante Q2 (de cara al negocio, apoya al equipo)

5.1.7.1.3. Cuadrante Q3 (de cara al negocio, critica al producto).

5.1.7.1.4. Cuadrante Q4 (de cara a la tecnología, critica al producto).

5.2. 5.2 Gestión del Riesgo

5.2.1. 5.2.1 Definición del Riesgo y Atributos del Riesgo

5.2.1.1. El riesgo es un acontecimiento, peligro, amenaza o situación potencial cuya ocurrencia causa un efecto adverso

5.2.2. 5.2.2 Riesgos de Proyecto y Riesgos de Producto

5.2.2.1. Riesgo de Producto

5.2.2.1.1. relacionados con las características de calidad del producto

5.2.2.1.2. ejemplos

5.2.2.2. Riesgo de Proyecto

5.2.2.2.1. cuando se producen, pueden repercutir en el calendario, el presupuesto o el alcance del proyecto,

5.2.2.2.2. ejemplos

5.2.3. 5.2.3 Análisis del Riesgo de Producto

5.2.3.1. el objetivo del análisis del riesgo de producto es proporcionar una conciencia del riesgo de producto para concentrar el esfuerzo de prueba de forma que se minimice el nivel residual de riesgo.

5.2.3.1.1. Identificación del riesgo

5.2.3.1.2. la evaluación del riesgo.

5.2.4. 5.2.4 Control del Riesgo de Producto

5.2.4.1. Mitigarlos

5.2.4.1.1. implementación de las acciones propuestas en la evaluación del riesgo para reducir el nivel de riesgo

5.2.4.2. Monitorizarlos

5.2.4.2.1. asegurar que las acciones de mitigación son efectivas

5.3. 5.3 Monitorización y Control de la Prueba

5.3.1. 5.3.1 Métricas Utilizadas en la Prueba

5.3.1.1. Que Evaluan?

5.3.1.1.1. Avance con respecto al calendario y presupuesto previstos

5.3.1.2. Metricas comunes

5.3.1.2.1. Métricas de avance del proyecto

5.3.1.2.2. Métricas de avance de la prueba

5.3.1.2.3. Métricas de calidad de producto

5.3.1.2.4. Métricas de defectos

5.3.1.2.5. Métricas de riesgo

5.3.1.2.6. Métricas de cobertura

5.3.1.2.7. Métricas de coste

5.3.2. 5.3.2 Propósito, Contenido y Audiencia de los Informes de Prueba

5.3.2.1. Objetivo

5.3.2.1.1. resume y comunica la información de prueba durante y después de la prueba.

5.3.2.2. Informe de avance

5.3.2.2.1. Periodo de prueba.

5.3.2.2.2. Avance de la prueba

5.3.2.2.3. Obstáculos para la prueba y sus soluciones

5.3.2.2.4. Métricas de prueba

5.3.2.2.5. Riesgos nuevos y modificados dentro del periodo de prueba

5.3.2.2.6. Prueba planificada para el siguiente periodo

5.3.2.3. informe compleción de prueba

5.3.2.3.1. Resumen de la prueba.

5.3.2.3.2. Evaluación de la prueba y de la calidad del producto basada en el plan de prueba original

5.3.2.3.3. Desviaciones del plan de prueba

5.3.2.3.4. Obstáculos y soluciones a las pruebas.

5.3.2.3.5. Métricas de prueba basadas en los informes del avance de la prueba.

5.3.2.3.6. Riesgos no mitigados, defectos no solucionados.

5.3.3. 5.3.3 Comunicación del Estado de la Prueba

5.3.3.1. Comunicación verbal con los miembros del equipo y otros implicados.

5.3.3.2. Cuadros de mando (por ejemplo, paneles de control de CI/CD, tableros de tareas y gráficos de quemado).

5.3.3.3. Canales de comunicación electrónica (por ejemplo, correo electrónico, chat).

5.3.3.4. Documentación en línea.

5.4. 5.4 Gestión de la Configuración

5.4.1. Objetivo

5.4.1.1. proporciona una disciplina para la identificación, el control y el seguimiento de productos de trabajo

5.4.1.1.1. planes de prueba

5.4.1.1.2. estrategia de prueba

5.4.1.1.3. casos de prueba

5.4.1.1.4. resultados

5.4.2. Asegurarse de

5.4.2.1. Todos los elementos de prueba

5.4.2.2. Todos los elementos de productos de prueba (testware)

5.4.2.3. Todos los documentos y elementos software identificados están referenciados de forma inequívoca en la documentación de la prueba

5.5. 5.5 Gestión de Defectos

5.5.1. Objetivos

5.5.1.1. Proporcionar a los responsables de la gestión y resolución de los defectos notificados información suficiente para resolver el problema.

5.5.1.2. Proporcionar un medio de seguimiento de la calidad del producto del trabajo.

5.5.1.3. Proporcionar ideas para la mejora de los procesos de desarrollo y prueba

5.5.2. Contenido de un Informe de Defecto

5.5.2.1. Un identificador

5.5.2.2. Un título y un breve resumen

5.5.2.3. Fecha

5.5.2.4. Identificación del objeto de prueba y del entorno de prueba.

5.5.2.5. Una descripción del defecto para permitir la reproducción y resolución

5.5.2.6. Resultados esperados y reales

5.5.2.7. Severidad del defecto

5.5.2.8. Urgencia/prioridad de la corrección

5.5.2.9. Estado del informe de defecto

5.5.2.10. Referencias

6. 6 Herramientas de Prueba

6.1. 6.1 Herramientas de Apoyo a la Prueba

6.1.1. ejemplos

6.1.1.1. Herramientas de gestión

6.1.1.1.1. aumentan la eficiencia del proceso de prueba facilitando la gestión del CVDS, los requisitos, las pruebas, los defectos y la configuración.

6.1.1.2. Herramientas de prueba estática:

6.1.1.2.1. ayudan al probador a realizar revisiones y análisis estáticos.

6.1.1.3. Herramientas de diseño de pruebas e implementación

6.1.1.3.1. facilitan la generación de casos de prueba,

6.1.1.4. Herramientas de ejecución de la prueba y de cobertura

6.1.1.4.1. facilitan la ejecución automatizada de la prueba y la medición de la cobertura.

6.1.1.5. Herramientas de pruebas no funcionales

6.1.1.5.1. permiten al probador realizar pruebas no funcionales

6.1.1.6. Herramientas DevOps

6.1.1.6.1. apoyan la canalización de entrega DevOps, el seguimiento del flujo de trabajo, los procesos de construcción automatizados, IC/EC

6.1.1.7. Herramientas de colaboración

6.1.1.7.1. facilitan la comunicación

6.1.1.8. Herramientas de apoyo a la escalabilidad y la normalización del despliegue

6.1.1.8.1. máquinas virtuales, herramientas de contenerización

6.1.1.9. Cualquier otra herramienta que ayude en las pruebas

6.1.1.9.1. una hoja de cálculo es una herramienta de prueba en el contexto de las pruebas

6.2. 6.2 Ventajas y Riesgos de la Automatización de la Prueba

6.2.1. beneficios potenciales de utilizar la automatización

6.2.1.1. Ahorro de tiempo al reducir el trabajo manual repetitivo

6.2.1.2. Prevención de errores humanos simples gracias a una mayor consistencia y repetibilidad

6.2.1.3. Evaluación más objetiva

6.2.1.4. Acceso más fácil a la información sobre pruebas para apoyar la gestión de pruebas

6.2.1.5. Tiempos de ejecución de pruebas reducidos

6.2.1.6. Más tiempo para que los probadores diseñen pruebas nuevas

6.2.2. riesgos potenciales de utilizar la automatización

6.2.2.1. Expectativas poco realistas sobre las ventajas de una herramienta

6.2.2.2. Estimaciones imprecisas del tiempo, los costes y el esfuerzo

6.2.2.3. Utilizar una herramienta de prueba cuando la prueba manual es más apropiada.

6.2.2.4. Confiar demasiado en una herramienta,

6.2.2.5. La dependencia del proveedor de la herramienta,

6.2.2.6. Utilizar un software de código abierto que puede estar abandonado,

6.2.2.7. La herramienta de automatización no es compatible con la plataforma de desarrollo.

6.2.2.8. Elección de una herramienta inadecuada que no cumpla los requisitos reglamentarios