ISTQB® CTFL 2018 by Guino Henostroza (Qualizens)

1. 5. Gestión de la Prueba

1.1. 5.1 Organización de la Prueba

1.1.1. 5.1.1 Prueba Independiente

1.1.1.1. Grados de independencia

1.1.1.1.1. No hay probadores independientes

1.1.1.1.2. Desarrolladores independientes o probadores dentro de los equipos de desarrollo

1.1.1.1.3. Equipo o grupo de prueba independiente dentro de la organización

1.1.1.1.4. Probadores independientes

1.1.1.1.5. Probadores independientes externos a la organización

1.1.1.2. Beneficios

1.1.1.2.1. Los probadores independientes reconocen diferentes tipos de fallos en comparación con los desarrolladores debido a sus diferentes contextos, perspectivas técnicas y sesgos.

1.1.1.2.2. Un probador independiente puede verificar, cuestionar o refutar las suposiciones hechas por los implicados durante la especificación e implementación del sistema

1.1.1.3. Desventajas

1.1.1.3.1. Aislamiento con respecto al equipo de desarrollo, lo que conduce a una falta de colaboración, retrasos en la retroalimentación al equipo de desarrollo o una relación de confrontación con el equipo de desarrollo.

1.1.1.3.2. Los desarrolladores pueden perder el sentido de la responsabilidad con respecto a la calidad

1.1.1.3.3. Los probadores independientes pueden ser vistos como un cuello de botella o ser culpados por los retrasos en el lanzamiento o liberación

1.1.1.3.4. Los probadores independientes pueden carecer de información importante

1.1.2. 5.1.2 Tareas de un Jefe de Prueba y un Probador

1.1.2.1. Jefe de Prueba

1.1.2.1.1. Desarrollar o revisar una política de prueba y una estrategia de prueba para la organización

1.1.2.1.2. Planificar las actividades de la prueba considerando el contexto y entendiendo los objetivos y riesgos de la prueba

1.1.2.1.3. Redactar y actualizar el/los plan(es) de prueba

1.1.2.1.4. Coordinar el/los plan(es) de prueba con los jefes de proyecto, los propietarios de producto y otros

1.1.2.1.5. Compartir las perspectivas con respecto a las pruebas con otras actividades del proyecto, como la planificación de la integración

1.1.2.1.6. Iniciar el análisis, diseño, implementación y ejecución de pruebas, monitorizar el avance y los resultados de la prueba y comprobar el estado de los criterios de salida (o definición de hecho).

1.1.2.1.7. Preparar y entregar informes de avance de la prueba e informes de resumen de prueba basados en la información recopilada

1.1.2.1.8. Adaptar la planificación en función de los resultados y avance de la prueba y tomar las medidas necesarias para el control de la prueba

1.1.2.1.9. Apoyar la implantación del sistema de gestión de defectos y una gestión de la configuración adecuada para los productos de prueba

1.1.2.1.10. Introducir métricas adecuadas para medir el avance de la prueba y evaluar la calidad de la prueba y del producto

1.1.2.1.11. Apoyar la selección e implementación de herramientas para dar soporte al proceso de prueba, incluyendo la recomendación del presupuesto para la selección de herramientas, la asignación de tiempo y esfuerzo para los proyectos piloto, y la provisión de un soporte continuo en el uso de la herramienta o herramientas.

1.1.2.1.12. Decidir sobre la implementación de los entornos de prueba

1.1.2.1.13. Promover y defender a los probadores, al equipo de prueba y a la profesión de prueba dentro de la organización

1.1.2.1.14. Desarrollar las competencias y las carreras profesionales de los probadores

1.1.2.2. Probador

1.1.2.2.1. Revisar y contribuir a los planes de prueba

1.1.2.2.2. Analizar, revisar y evaluar la base de pruebas: los requisitos, historias de usuario y criterios de aceptación, especificaciones y modelos para la capacidad de ser probado

1.1.2.2.3. Identificar y documentar las condiciones de prueba, y capturar la trazabilidad entre los casos de prueba, las condiciones de prueba y la base de prueba

1.1.2.2.4. Diseñar, preparar y verificar los entornos de prueba, a menudo en coordinación con las áreas de administración de sistemas y gestión de redes

1.1.2.2.5. Diseñar e implementar casos de prueba y procedimientos de prueba

1.1.2.2.6. Preparar y obtener datos de prueba

1.1.2.2.7. Crear el calendario de ejecución de prueba detallado

1.1.2.2.8. Ejecutar pruebas, evaluar los resultados y documentar las desviaciones de los resultados esperados

1.1.2.2.9. Utilizar herramientas apropiadas para facilitar el proceso de prueba

1.1.2.2.10. Automatizar las pruebas según sea necesario

1.1.2.2.11. Evaluar características no funcionales tales como eficiencia de desempeño, fiabilidad, usabilidad, seguridad, compatibilidad y portabilidad

1.1.2.2.12. Revisar pruebas desarrolladas por otros

1.2. 5.2 Planificación y Estimación de la Prueba

1.2.1. 5.2.1 Propósito y Contenido de un Plan de Prueba

1.2.1.1. Determinar el alcance, los objetivos y los riesgos de la prueba

1.2.1.2. Definir el enfoque general de la prueba

1.2.1.3. Integrar y coordinar las actividades de prueba en las actividades del ciclo de vida del software

1.2.1.4. Tomar decisiones sobre lo que se va a probar, las personas y otros recursos necesarios para realizar las diversas actividades de prueba, y cómo se llevarán a cabo las actividades de prueba

1.2.1.5. Establecer un calendario para las actividades de análisis, diseño, implementación, ejecución y evaluación de la prueba, ya sea en fechas particulares o en el contexto de cada iteración

1.2.1.6. Selección de métricas para monitorizar y controlar la prueba

1.2.1.7. Elaborar un presupuesto para las actividades de prueba

1.2.1.8. Determinar el nivel de detalle y la estructura de la documentación de la prueba (por ejemplo, proporcionando plantillas o documentos de ejemplo

1.2.2. 5.2.2 Estrategia y Enfoque de la Prueba

1.2.2.1. Analítica

1.2.2.1.1. Las pruebas se analizan

1.2.2.2. Basada en Modelos

1.2.2.2.1. Las pruebas se diseñan basándose en algún modelo de algún aspecto requerido del producto

1.2.2.3. Metódica

1.2.2.3.1. Se basa en el uso sistemático de un conjunto predefinido de pruebas o condiciones de prueba,

1.2.2.4. Conforme a Proceso

1.2.2.4.1. Implica el análisis, diseño e implementación de pruebas basadas en reglas y estándares externos

1.2.2.5. Dirigida (o consultiva)

1.2.2.5.1. Se basa principalmente en el asesoramiento, la orientación o las instrucciones de implicados fuera del equipo de prueba

1.2.2.6. Adversa a la Regresión

1.2.2.6.1. Estrategia motivada por el deseo de evitar la regresión de las capacidades existentes

1.2.2.6.2. Incluye

1.2.2.7. Reactiva

1.2.2.7.1. Estrategia de prueba reactiva en lugar de ser planificada con antelación

1.2.2.7.2. Las pruebas se diseñan en respuesta al conocimiento obtenido de los resultados de prueba anteriores

1.2.3. 5.2.3 Criterios de Entrada y Criterios de Salida (Definición de Preparado y Definición de Hecho)

1.2.3.1. Criterios de entrada habituales

1.2.3.1.1. Disponibilidad de requisitos, historias de usuarios y/o modelos

1.2.3.1.2. Disponibilidad de elementos de prueba que han cumplido los criterios de salida para cualquiera de los niveles de prueba anteriores

1.2.3.1.3. Disponibilidad del entorno de prueba

1.2.3.1.4. Disponibilidad de las herramientas de prueba necesarias

1.2.3.1.5. Disponibilidad de datos de prueba y otros recursos necesarios

1.2.3.2. Criterios de salida habituales

1.2.3.2.1. Las pruebas planificadas han sido ejecutadas

1.2.3.2.2. Se ha logrado un nivel de cobertura definido

1.2.3.2.3. El número de defectos no resueltos se encuentra dentro de un límite acordado

1.2.3.2.4. El número estimado de defectos restantes es suficientemente bajo

1.2.3.2.5. Los niveles de fiabilidad, eficiencia de desempeño, usabilidad, seguridad y otras características de calidad relevantes son suficientes

1.2.4. 5.2.4 Calendario de Ejecución de Prueba

1.2.4.1. Los diversos casos de prueba y procedimientos de prueba han sido desarrollados y agrupados en juegos de prueba (test suites)

1.2.4.2. Los juegos de prueba (test suites) pueden organizarse en un calendario de ejecución de prueba que define el orden en el que deben ejecutarse

1.2.4.3. Factores a tener en cuenta

1.2.4.3.1. Priorizacion

1.2.4.3.2. Dependencias

1.2.4.3.3. Pruebas de confirmación

1.2.4.3.4. Pruebas de regresión

1.2.4.3.5. Secuencia más eficaz para ejecutar las pruebas

1.2.5. 5.2.5 Factores que Influyen en el Esfuerzo de Prueba

1.2.5.1. Características del Producto

1.2.5.1.1. Los riesgos asociados al producto

1.2.5.1.2. La calidad de la base de prueba

1.2.5.1.3. El tamaño del producto

1.2.5.1.4. La complejidad del dominio del producto

1.2.5.1.5. Los requisitos para las características de calidad

1.2.5.1.6. El nivel de detalle necesario para la documentación de la prueba

1.2.5.1.7. Requisitos para el cumplimiento de normas legales y reglamentarias

1.2.5.2. Características del Proceso de Desarrollo

1.2.5.2.1. La estabilidad y madurez de la organización

1.2.5.2.2. El modelo de desarrollo en uso

1.2.5.2.3. El enfoque de prueba

1.2.5.2.4. Las herramientas utilizadas

1.2.5.2.5. El proceso de prueba

1.2.5.2.6. Presión con respecto al tiempo

1.2.5.3. Características de las Personas

1.2.5.3.1. Las competencias y la experiencia de las personas involucradas, especialmente con proyectos y productos similares

1.2.5.3.2. Cohesión y liderazgo del equipo.

1.2.5.4. Resultados de la Prueba

1.2.5.4.1. El número y la severidad de los defectos detectados

1.2.5.4.2. La cantidad de reconstrucción necesaria

1.2.6. 5.2.6 Técnicas de Estimación de la Prueba

1.2.6.1. La técnica basada en métricas

1.2.6.1.1. Estimación del esfuerzo de prueba basada en métricas de proyectos similares anteriores o en valores típicos

1.2.6.2. La técnica basada en expertos

1.2.6.2.1. Estimar el esfuerzo de la prueba basándose en la experiencia de los propietarios de las tareas de prueba o por expertos

1.3. 5.3 Monitorización y Control de la Prueba

1.3.1. 5.3.1 Métricas Utilizadas en la Prueba

1.3.1.1. Que Evaluan?

1.3.1.1.1. Avance con respecto al calendario y presupuesto previstos

1.3.1.1.2. Calidad actual del objeto de prueba

1.3.1.1.3. Adecuación del enfoque de prueba

1.3.1.1.4. Eficacia de las actividades de prueba con respecto a los objetivos

1.3.1.2. Metricas comunes

1.3.1.2.1. Porcentaje de trabajo planificado realizado en la preparación de los casos de prueba

1.3.1.2.2. Porcentaje de trabajo planificado realizado en la preparación del entorno de prueba

1.3.1.2.3. Ejecución de casos de prueba

1.3.1.2.4. Información sobre defectos

1.3.1.2.5. Cobertura de prueba con respecto a requisitos, historias de usuarios, criterios de aceptación, riesgos o código.

1.3.1.2.6. La finalización de una tarea, la asignación y uso de recursos y el esfuerzo

1.3.1.2.7. El coste de la prueba

1.3.2. 5.3.2 Objetivos, Contenidos y Audiencias de los Informes de Prueba

1.3.2.1. Objetivo

1.3.2.1.1. Resumir y comunicar la información de la actividad de prueba, tanto durante como al final de una actividad de prueba

1.3.2.2. Informe de avance

1.3.2.2.1. El estado de las actividades de prueba y el avance con respecto al plan de prueba

1.3.2.2.2. Factores que impiden el avance

1.3.2.2.3. Pruebas previstas para el próximo período objeto de informe

1.3.2.2.4. La calidad del objeto de prueba

1.3.2.3. Informe de resumen

1.3.2.3.1. Resumen de la prueba realizada

1.3.2.3.2. Información sobre lo ocurrido durante un período de prueba

1.3.2.3.3. Desviaciones con respecto al plan,

1.3.2.3.4. Estado de la prueba y calidad del producto con respecto a los criterios de salida o definición de hecho.

1.3.2.3.5. Factores que han bloqueado o continúan bloqueando el avance

1.3.2.3.6. Métricas de defectos, casos de prueba, cobertura de la prueba, avance de la actividad y consumo de recursos.

1.3.2.3.7. Riesgos residuales

1.3.2.3.8. Productos de trabajo de prueba reutilizables desarrollados

1.4. 5.4 Gestión de la Configuración

1.4.1. Objetivo

1.4.1.1. Establecer y mantener la integridad del componente o sistema, los productos de prueba y sus relaciones entre sí a lo largo del ciclo de vida del proyecto y del producto

1.4.2. Asegurarse de

1.4.2.1. Todos los elementos de prueba

1.4.2.1.1. Se identifican de forma única

1.4.2.1.2. Se controlan las versiones

1.4.2.1.3. Se hace un seguimiento de los cambios

1.4.2.1.4. Se relacionan entre sí

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

1.4.2.2.1. Se identifican de forma única

1.4.2.2.2. Se controlan las versiones

1.4.2.2.3. Se hace un seguimiento de los cambios

1.4.2.2.4. Se relacionan entre sí y se relacionan con las versiones de los elementos de prueba, de modo que se pueda mantener la trazabilidad durante todo el proceso de prueba

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

1.5. 5.5 Riesgos y Prueba

1.5.1. 5.5.1 Definición de Riesgo

1.5.1.1. Posibilidad de que ocurra un evento en el futuro que tenga consecuencias negativas

1.5.1.2. El nivel de Riesgo esta determinado por

1.5.1.2.1. La probabilidad del evento

1.5.1.2.2. El impacto (el daño) de ese evento

1.5.2. 5.5.2 Riesgos de Producto y Riesgos de Proyecto

1.5.2.1. Riesgo de Producto

1.5.2.1.1. Posibilidad de que un producto de trabajo pueda no satisfacer las necesidades legítimas de sus usuarios y/o implicados

1.5.2.1.2. Ejemplos

1.5.2.2. Riesgo de Proyecto

1.5.2.2.1. Implica situaciones que, en caso de que ocurrieran, podrían tener un efecto negativo en la capacidad de un proyecto para lograr sus objetivos

1.5.2.2.2. Ejemplos

1.5.3. 5.5.3 La Prueba Basada en el Riesgo y la Calidad de Producto

1.5.3.1. Se utilizan los resultados del análisis del riesgo de producto para

1.5.3.1.1. Determinar las técnicas de prueba que se van a utilizar

1.5.3.1.2. Determinar los niveles y tipos particulares de pruebas que se realizarán

1.5.3.1.3. Determinar el alcance de la prueba que se llevará a cabo

1.5.3.1.4. Priorizar la prueba en un intento de encontrar los defectos críticos tan pronto como sea posible

1.5.3.1.5. Determinar si se podrían realizar otras actividades además de las pruebas para reducir el riesgo

1.5.3.2. Actividades de gestión de riesgos

1.5.3.2.1. Analizar (y reevaluar regularmente) lo que puede salir mal (riesgos).

1.5.3.2.2. Determinar qué riesgos son los que es importante tratar

1.5.3.2.3. Implementar acciones para mitigar esos riesgos

1.5.3.2.4. Elaborar planes de contingencia para hacer frente a los riesgos en caso de que se conviertan enhechos reales

1.6. 5.6 Gestión de Defectos

1.6.1. Objetivos

1.6.1.1. Proporcionar a los desarrolladores y otras partes información sobre cualquier evento adverso que haya ocurrido

1.6.1.2. Proporcionar a los jefes de prueba un medio para hacer un seguimiento de la calidad del producto de trabajo y del impacto en la prueba

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

1.6.2. Contenido de un Informe de Defecto

1.6.2.1. Un identificador

1.6.2.2. Un título y un breve resumen del defecto que se está informando

1.6.2.3. Fecha del informe de defecto, organización emisora y autor

1.6.2.4. Identificación del elemento de prueba y del entorno.

1.6.2.5. La(s) fase(s) del ciclo de vida de desarrollo en la(s) que se observó el defecto

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

1.6.2.6.1. Incluyen registros (logs)

1.6.2.6.2. Capturas de pantalla

1.6.2.6.3. Volcados de bases de datos

1.6.2.6.4. Grabaciones

1.6.2.7. Resultados esperados y reales

1.6.2.8. Alcance o grado de impacto (severidad) del defecto

1.6.2.9. Urgencia/prioridad de la corrección

1.6.2.10. Estado del informe de defecto

1.6.2.11. Conclusiones, recomendaciones y aprobaciones

1.6.2.12. Cuestiones generales, tales como otras áreas que pueden verse afectadas por un cambio resultante del defecto.

1.6.2.13. Historial de cambios

1.6.2.14. Referencias, incluyendo el caso de prueba que puso en evidencia el problema

2. 6. Soporte de Herramientas para el Proceso de Prueba

2.1. 6.1 Consideraciones sobre las Herramientas de Prueba

2.1.1. 6.1.1 Clasificación de las Herramientas de Prueba

2.1.1.1. Objetivos posibles

2.1.1.1.1. Mejorar la eficiencia de las actividades de prueba

2.1.1.1.2. Mejorar la calidad de las actividades de prueba

2.1.1.1.3. Automatizar actividades que no se pueden ejecutar manualmente

2.1.1.1.4. Aumentar la fiabilidad de las pruebas

2.1.1.2. Soporte de Herramientas para la Gestión de la Prueba y Productos de Prueba

2.1.1.2.1. Herramientas de gestión de prueba y herramientas de gestión del ciclo de vida de las aplicaciones

2.1.1.2.2. Herramientas de gestión de requisitos

2.1.1.2.3. Herramientas de gestión de defectos

2.1.1.2.4. Herramientas de gestión de la configuración

2.1.1.2.5. Herramientas de integración continua

2.1.1.3. Soporte de Herramientas para la Prueba Estática

2.1.1.3.1. Herramientas de apoyo a las revisiones

2.1.1.3.2. Herramientas de análisis estático

2.1.1.4. Soporte de Herramientas para el Diseño e Implementación de Pruebas

2.1.1.4.1. Herramientas de diseño de pruebas

2.1.1.4.2. Herramientas de prueba Basada en Modelos

2.1.1.4.3. Herramientas de preparación de datos de prueba

2.1.1.4.4. Herramientas de desarrollo guiado por prueba de aceptación (ATDD)

2.1.1.4.5. Herramientas de desarrollo guiado por el comportamiento (BDD)

2.1.1.4.6. Herramientas de desarrollo guiado por pruebas (TDD)

2.1.1.5. Soporte de Herramientas para la Ejecución y el Registro de Pruebas

2.1.1.5.1. Herramientas de ejecución de pruebas (ejm. Regresion)

2.1.1.5.2. Herramientas de cobertura

2.1.1.5.3. Arneses de prueba (Test Harnesses)

2.1.1.5.4. Herramientas para el marco de trabajo de pruebas unitarias

2.1.1.6. Soporte de Herramientas para la Medición del Rendimiento y el Análisis Dinámico

2.1.1.6.1. Herramientas para la prueba de rendimiento

2.1.1.6.2. Herramientas de monitorización

2.1.1.6.3. Herramientas de análisis dinámico

2.1.1.7. Soporte de Herramientas para Necesidades de Prueba Especializadas

2.1.1.7.1. Evaluación de la calidad de los datos

2.1.1.7.2. Conversión y migración de datos

2.1.1.7.3. Prueba de usabilidad

2.1.1.7.4. Prueba de accesibilidad

2.1.1.7.5. Prueba de localización

2.1.1.7.6. Prueba de seguridad

2.1.1.7.7. Prueba de portabilidad

2.1.2. 6.1.2 Beneficios y Riesgos de la Automatización de la Prueba

2.1.2.1. Beneficios

2.1.2.1.1. Reducción del trabajo manual repetitivo lo que ahorra tiempo

2.1.2.1.2. Mayor consistencia y repetibilidad

2.1.2.1.3. Una evaluación más objetiva

2.1.2.1.4. Acceso más fácil a la información sobre las pruebas

2.1.2.2. Una nueva plataforma o tecnología puede no estar soportada por la herramienta

2.1.2.2.1. Las expectativas con respecto a la herramienta pueden ser poco realistas

2.1.2.2.2. El tiempo, costo y esfuerzo para la introducción inicial de una herramienta pueden haber sido subestimados

2.1.2.2.3. El tiempo y el esfuerzo necesarios para lograr beneficios significativos y continuos de la herramienta pueden haber sido subestimados

2.1.2.2.4. El esfuerzo requerido para mantener los activos de prueba generados por la herramienta puede haber sido subestimado.

2.1.2.2.5. Se puede confiar demasiado en la herramienta

2.1.2.2.6. El control de versiones de los activos de prueba puede ser descuidado

2.1.2.2.7. Las relaciones y las cuestiones de interoperabilidad entre las herramientas críticas pueden descuidarse

2.1.2.2.8. El proveedor de herramientas puede cerrar el negocio, retirar la herramienta o venderla a otro proveedor.

2.1.2.2.9. El proveedor puede proporcionar una respuesta deficiente para soporte, actualizaciones y correcciones de defectos.

2.1.2.2.10. Un proyecto de código abierto puede ser suspendido

2.1.2.2.11. Una nueva plataforma o tecnología puede no estar soportada por la herramienta

2.1.2.2.12. Es posible que no haya una titularidad clara de la herramienta

2.1.3. 6.1.3 Consideraciones Especiales con Respecto a las Herramientas de Ejecución y Gestión de Prueba

2.1.3.1. Herramientas de Ejecución de Prueba

2.1.3.1.1. Captura de pruebas mediante el registro de las acciones de un probador manual

2.1.3.1.2. Enfoque de prueba guiada por datos

2.1.3.1.3. Enfoque de prueba guiada por palabra clave

2.1.3.1.4. Herramientas de prueba Basada en Modelos (MBT)

2.1.3.2. Herramientas de Gestión de Prueba

2.1.3.2.1. Razones para interactuar con otras herramientas

2.2. 6.2 Uso Eficaz de las Herramientas

2.2.1. 6.2.1 Principios Básicos para la Selección de Herramientas

2.2.1.1. Evaluación de la madurez de la organización, sus fortalezas y debilidades

2.2.1.2. Identificar oportunidades para un proceso de prueba mejorado con el soporte de herramientas

2.2.1.3. Comprender las tecnologías utilizadas por el objeto u objetos de prueba, con el fin de seleccionar una herramienta que sea compatible con dicha tecnología.

2.2.1.4. Las herramientas de compilación e integración continua ya en uso dentro de la organización, con el fin de asegurar la compatibilidad e integración de las herramientas

2.2.1.5. Evaluar la herramienta con respecto a requisitos claros y criterios objetivos.

2.2.1.6. Tener en cuenta si la herramienta está disponible durante un período de prueba gratuito

2.2.1.7. Evaluar al proveedor o soporte para herramientas no comerciales

2.2.1.8. Identificar los requisitos internos para el entrenamiento y asesoramiento en el uso de la herramienta

2.2.1.9. Evaluar las necesidades de formación, teniendo en cuenta las competencias en materia de prueba (y automatización de la prueba) de quienes trabajarán directamente con la(s) herramienta(s).

2.2.1.10. Considerar los pros y contras de varios modelos de licenciamiento

2.2.1.11. Estimar la relación coste-beneficio a partir de un caso de negocio concreto (si fuera necesario).

2.2.2. 6.2.2 Proyectos Piloto para Introducir una Herramienta en una Organización

2.2.2.1. Objetivos

2.2.2.1.1. Obtener un conocimiento profundo de la herramienta, entendiendo tanto sus fortalezas como sus debilidades

2.2.2.1.2. Evaluar cómo encaja la herramienta con los procesos y prácticas existentes, y determinar qué se necesita cambiar

2.2.2.1.3. Decidir sobre las formas estándar de usar, administrar, almacenar y mantener la herramienta y los activos de prueba

2.2.2.1.4. Evaluar si los beneficios se lograrán a un coste razonable

2.2.2.1.5. Comprender las métricas que se desea que la herramienta recopile e informe, y configurar la herramienta para asegurar que estas métricas puedan ser capturadas e informadas

2.2.3. 6.2.3 Factores de Éxito para Herramientas

2.2.3.1. Despliegue de la herramienta al resto de la organización de forma incremental

2.2.3.2. Adaptar y mejorar los procesos para que se ajusten al uso de la herramienta

2.2.3.3. Proporcionar formación, entrenamiento y asesoramiento para los usuarios de la herramienta

2.2.3.4. Definición de directrices para el uso de la herramienta

2.2.3.5. Implementar una forma de recopilar información de uso a partir del uso real de la herramienta

2.2.3.6. Monitorizar el uso y los beneficios de la herramienta

2.2.3.7. Proporcionar apoyo a los usuarios de una herramienta determinada

2.2.3.8. Recopilar las lecciones aprendidas de todos los usuarios

3. A2 .Examen ISTQB CTLF 2018

3.1. #Preguntas: 40

3.2. Puntaje mínimo: 26 pts (65%)

3.3. Tiempo: 60 minutos

3.4. Preguntas por capitulo

3.4.1. 8

3.4.2. 5

3.4.3. 5

3.4.4. 11

3.4.5. 9

3.4.6. 2

3.5. Examen Ejemplo

4. A3. Glosario

4.1. Sitio web ISTQB

4.2. Glosario Español PDF SSTQB

5. A1. Estandares actualizados

5.1. ISO/IEC 25010 sustituye a la norma ISO 9126 (Evaluación de Calidad)

5.2. ISO/IEC 20246 sustituye a la norma IEEE 1028 (Revisiones y Auditorias)

5.3. ISO/IEC/IEEE 29119 sustituye a la norma IEEE 829 (Documentación de Prueba)

6. 1. Fundamentos del Proceso de Prueba

6.1. 1.1 ¿Qué es Probar?

6.1.1. 1.1.0 Introducción

6.1.1.1. Probar el software es una forma de evaluar la calidad del software y de reducir el riesgo de fallos en un entorno de operaciones o en producción.

6.1.1.2. La prueba de software es un proceso que incluye muchas actividades diferentes; la ejecución de la prueba es sólo una de estas actividades

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

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

6.1.1.5. Las pruebas implican verificacion y validacion

6.1.2. 1.1.1 Objetivos Característicos de la Prueba

6.1.2.1. Evaluar productos de trabajo tales como requisitos, historias de usuario, diseño y código

6.1.2.2. Verificar el cumplimiento de todos los requisitos especificados

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

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

6.1.2.5. Prevenir defectos

6.1.2.6. Encontrar fallos y defectos.

6.1.2.7. Proporcionar suficiente información a los implicados para que puedan tomar decisiones informadas (nivel de calidad del objeto de prueba)

6.1.2.8. Reducir el nivel de riesgo de calidad del software

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

6.1.3. 1.1.2 Prueba y Depuración

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

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

6.2. 1.2 ¿Por qué es Necesario Probar?

6.2.1. 1.2.1 Contribuciones de la Prueba al Éxito

6.2.1.1. La identificación y eliminación de defectos en los requisitos lo cual reduce el riesgo de que se desarrollen funcionalidades incorrectas o que no puedan ser probadas

6.2.1.2. Aumentar la comprensión sobre el diseño y la forma de probarlo, reduciendo el riesgo de defectos de disenio e identificando pruebas tempranamente

6.2.1.3. Puede aumentar la comprensión del código y la forma de probarlo reduciendo el riesgo de defectos dentro del código y de la prueba

6.2.1.4. Puede detectar fallos que de otro modo podrían haberse omitido aumentando la probabilidad de que el software cumpla con las necesidades de los implicados y satisfaga los requisitos.

6.2.2. 1.2.2 Aseguramiento de la Calidad y Proceso de Prueba

6.2.2.1. La gestión de la calidad incluye todas las actividades que dirigen y controlan una organización con respecto a la calidad e incluye tanto el aseguramiento de la calidad como el control de la calidad.

6.2.2.2. Aseguramiento de la calidad se centra, por lo general, en el cumplimiento de los procesos adecuados, a fin de proporcionar la confianza de que se alcanzarán los niveles de calidad adecuados.

6.2.2.3. El control de la calidad implica varias actividades, incluyendo actividades de prueba, que apoyan el logro de niveles apropiados de calidad

6.2.3. 1.2.3 Errores, Defectos y Fallos

6.2.3.1. Una persona puede cometer un error, que puede llevar a la introducción de un defecto (falta o bug) en el código software o en algún otro producto de trabajo relacionado.

6.2.3.2. Si se ejecuta un fragmento de código que contiene un defecto, esto puede causar un fallo, en circunstancias especificas que puede ocurrir rara vez o nunca.

6.2.3.3. Los errores se deben a distintas causas

6.2.3.3.1. Presión por causa de tiempo

6.2.3.3.2. Falibilidad humana

6.2.3.3.3. Participantes en el proyecto sin experiencia o poco cualificados

6.2.3.3.4. Falta de comunicación entre los participantes en el proyecto, incluida la falta de comunicación con respecto a requisitos y diseño

6.2.3.3.5. Complejidad del código, diseño, arquitectura, el problema subyacente que se debe resolver, y/o las tecnologías utilizadas

6.2.3.3.6. Malentendidos acerca de las interfaces intra e intersistemas, especialmente cuando esas interacciones intra e intersistemas son numerosas

6.2.3.3.7. Tecnologías nuevas y desconocidas

6.2.3.4. Los fallos también pueden ser causados por condiciones medioambientales

6.2.3.5. Los falsos negativos son pruebas que no detectan defectos que deberían haber detectado.

6.2.3.6. Los falsos positivos se informan como defectos, pero en realidad no son defectos.

6.2.4. 1.2.4 Defectos, Causas Raíz y Efectos

6.2.4.1. El análisis de la causa raíz puede conducir a mejoras en el proceso que previenen la introducción de un número significativo de futuros defectos

6.2.4.2. Ejemplo

6.2.4.2.1. Efecto: Reclamo de los clientes

6.2.4.2.2. Fallo: Pago de Intereses incorrecto

6.2.4.2.3. Defecto: Calculo incorrecto en el codigo

6.2.4.2.4. Causa: Ambigüedad en la HU por desconocimiento del PO

6.3. 1.3 Siete Principios de la Prueba

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

6.3.2. 2. La prueba exhaustiva es imposible

6.3.3. 3. La prueba temprana ahorra tiempo y dinero

6.3.4. 4. Los defectos se agrupan

6.3.5. 5. Cuidado con la paradoja del pesticida

6.3.6. 6. La prueba depende del contexto

6.3.7. 7. La ausencia de errores es una falacia

6.4. 1.4 Proceso de Prueba

6.4.1. 1.4.0

6.4.1.1. No existe un proceso de prueba de software único y universal

6.4.1.2. Existen conjuntos de actividades de prueba comunes para alcanzar los objetivos establecidos

6.4.2. 1.4.1 El Proceso de Prueba en Contexto

6.4.2.1. Factores que influyen

6.4.2.1.1. Modelo de ciclo de vida de desarrollo de software y metodologías de proyecto en uso

6.4.2.1.2. Niveles y tipos de prueba considerados.

6.4.2.1.3. Riesgos de producto y de proyecto

6.4.2.1.4. Dominio del negocio

6.4.2.1.5. Restricciones operativas

6.4.2.1.6. Políticas y prácticas de la organización

6.4.2.1.7. Estándares internos y externos necesarios

6.4.3. 1.4.2 (Grupos de) Actividades y Tareas de Prueba

6.4.3.1. Planificación de la Prueba

6.4.3.1.1. Actividades que definen los objetivos de la prueba y el enfoque para cumplir con los objetivos de la prueba dentro de las restricciones impuestas por el contexto

6.4.3.2. Monitorización y Control de la Prueba

6.4.3.2.1. Monitorización: Continua del avance real con respecto al plan de prueba utilizando cualquier métrica de monitorización de la prueba definida en el plan de prueba

6.4.3.2.2. Control: Tomar las medidas necesarias para cumplir los objetivos del plan de prueba

6.4.3.2.3. Se apoyan en la evaluación de los criterios de salida (o DoD)

6.4.3.3. Análisis de la Prueba

6.4.3.3.1. Se determina "Qué probar" en términos de criterios de cobertura medibles

6.4.3.3.2. Actividades principales

6.4.3.3.3. Puede producir condiciones de prueba que deben ser utilizadas como objetivos de prueba en los contratos de prueba (Charter)

6.4.3.3.4. Estas actividades tambien validan si los requisitos satisfacen adecuadamente las necesidades de los clientes, usuarios y otros implicados

6.4.3.4. Diseño de la Prueba

6.4.3.4.1. Las condiciones de prueba se transforman en casos de prueba de alto nivel, conjuntos de casos de prueba de alto nivel y otros productos de prueba

6.4.3.4.2. Responde a la pregunta "Cómo probar"

6.4.3.4.3. Actividades principales

6.4.3.5. Implementación de la Prueba

6.4.3.5.1. Se crean y/o se completan los productos de prueba necesarios para la ejecución de la prueba, incluyendo la secuenciación de los casos de prueba en procedimientos de prueba

6.4.3.5.2. Responde a la pregunta " ¿Está todo preparado para realizar la prueba?

6.4.3.5.3. Actividades principales

6.4.3.6. Ejecución de la Prueba

6.4.3.6.1. Los juegos de prueba se ejecutan de acuerdo al calendario de ejecución de la prueba

6.4.3.6.2. Actividades principales

6.4.3.7. Compleción de la Prueba

6.4.3.7.1. Recopilan datos de las actividades de prueba completadas para consolidar la experiencia, los productos de prueba y cualquier otra información relevante

6.4.3.7.2. Actividades principales

6.4.4. 1.4.3 Productos de Trabajo de Prueba

6.4.4.1. Productos de Trabajo de la Planificación de la Prueba

6.4.4.1.1. Uno o más planes de prueba

6.4.4.2. Productos de Trabajo de la Monitorización y Control de la Prueba

6.4.4.2.1. Incluyen varios tipos de informes de prueba, incluyendo informes de progreso de la prueba e informes resumen de prueba

6.4.4.2.2. Deben abordar las inquietudes de la gestión del proyecto, tales como la compleción de tareas, la asignación y el uso de recursos, y el esfuerzo

6.4.4.3. Productos de Trabajo del Análisis de la Prueba

6.4.4.3.1. Incluyen condiciones de prueba definidas y priorizadas

6.4.4.3.2. Para la prueba exploratoria, puede implicar la creación de contratos de prueba (Charters)

6.4.4.4. Productos de Trabajo del Diseño de la Prueba

6.4.4.4.1. Resulta en casos de prueba y conjuntos de casos de prueba para practicar las condiciones de prueba definidas en el análisis de la prueba

6.4.4.4.2. También da lugar al diseño y/o la identificación de los datos de prueba necesarios, el diseño del entorno de prueba y la identificación de la infraestructura y las herramientas

6.4.4.5. Productos de Trabajo de la Implementación de la Prueba

6.4.4.5.1. Incluyen

6.4.4.5.2. En algunos casos puede ser virtualización de servicios y los guiones de prueba automatizados

6.4.4.5.3. puede resultar en la creación y verificación de los datos de la prueba y el entorno de prueba

6.4.4.5.4. En la prueba exploratoria, se pueden crear algunos productos de trabajo de diseño e implementación de la prueba durante la ejecución de la misma

6.4.4.6. Productos de Trabajo de la Ejecución de la Prueba

6.4.4.6.1. Documentación sobre el estado de casos de prueba individuales o procedimientos de prueba

6.4.4.6.2. Informes de defecto

6.4.4.6.3. Documentación sobre el o los elemento(s), objeto(s), herramienta(s) y productos de prueba involucrados en la prueba

6.4.4.7. Productos de Trabajo de la Compleción de la Prueba

6.4.4.7.1. Informes de resumen de la prueba

6.4.4.7.2. Elementos de acción para la mejora de proyectos o iteraciones subsiguientes

6.4.4.7.3. Solicitudes de cambio o elementos de la cartera del producto

6.4.4.7.4. Productos de prueba finalizados.

6.4.5. 1.4.4 Trazabilidad entre la Base de Prueba y los Productos de Trabajo de la Prueba

6.4.5.1. Nos permite

6.4.5.1.1. Analizar el impacto de cambios

6.4.5.1.2. Hacer que la prueba pueda ser auditada

6.4.5.1.3. Cumplimiento de los criterios de gobernanza de TI

6.4.5.1.4. Mejorar la comprensión de los informes de avance de la prueba y de los informes resumen de prueba para incluir el estado de los elementos de la base de prueba

6.4.5.1.5. Relacionar los aspectos técnicos de la prueba con los implicados en términos que éstos puedan entender.

6.4.5.1.6. Aportar información para evaluar la calidad de los productos, la capacidad de los procesos y el avance de los proyectos en relación con los objetivos de negocio

6.5. 1.5 La Psicología del Proceso de Prueba

6.5.1. 1.5.1 Psicología Humana y el Proceso de Prueba

6.5.1.1. El sesgo de confirmación puede dificultar la aceptación de información que esté en desacuerdo con las creencias actuales

6.5.1.2. Algunas personas pueden percibir al proceso de prueba como una actividad destructiva

6.5.1.3. La información sobre defectos y fallos debe ser comunicada de manera constructiva

6.5.1.4. Se necesitan tener buenas competencias interpersonales para poder comunicarse eficazmente sobre defectos, fallos, pruebas, etc.

6.5.1.5. Ejemplos de una Comunicación adecuada

6.5.1.5.1. Comenzar con colaboración en lugar de batallas

6.5.1.5.2. Enfatizar los beneficios de la prueba.

6.5.1.5.3. Comunicar los resultados de las pruebas y otros hallazgos de manera neutral y centrada en los hechos sin criticar personas.

6.5.1.5.4. Tratar de entender cómo se siente la otra persona

6.5.1.5.5. Confirmar que el interlocutor ha entendido lo que se ha dicho y viceversa

6.5.2. 1.5.2 Formas de Pensar del Probador y del Desarrollador

6.5.2.1. La mentalidad de un probador debe incluir

6.5.2.1.1. Curiosidad

6.5.2.1.2. Pesimismo profesional

6.5.2.1.3. Sentido crítico

6.5.2.1.4. Atención al detalle

6.5.2.1.5. Una motivación para una comunicación y relaciones buenas y positivas.

6.5.2.2. El Desarrollador exitoso

6.5.2.2.1. Está más interesado en el diseño y la construcción de soluciones

6.5.2.2.2. Tiene menos contemplación de lo que podría estar mal en esas soluciones

6.5.2.2.3. El "sesgo de confirmación" le hace dificil encontrar errores en su propio trabajo

6.5.2.3. Con la mentalidad correcta, los desarrolladores pueden probar su propio código

6.5.2.4. Los probadores independientes aportan una perspectiva diferente a la de los autores (diferente sesgo cognitivo) lo que aumenta la eficacia de la detección de defectos

7. 2. Prueba a lo largo del Ciclo de Vida de Desarrollo de Software

7.1. 2.1 Modelos de Ciclo de Vida del Desarrollo de Software

7.1.1. 2.1.1 Desarrollo de Software y Prueba de Software

7.1.1.1. Características de las pruebas en cualquier modelo de ciclo de vida

7.1.1.1.1. Para cada actividad de desarrollo, hay una actividad de prueba asociada

7.1.1.1.2. Cada nivel de prueba tiene objetivos de prueba específicos para ese nivel

7.1.1.1.3. El análisis y diseño de la prueba para un nivel de prueba dado comienza durante la actividad de desarrollo correspondiente

7.1.1.1.4. Los probadores participan en discusiones para definir y refinar los requisitos y el diseño, y están involucrados en la revisión de los productos de trabajo

7.1.1.2. El principio de "Prueba temprana" se aplica en cualquier ciclo de vida

7.1.1.3. Modelos de ciclo de vida de desarrollo

7.1.1.3.1. Modelos de desarrollo secuencial

7.1.1.3.2. Modelos de desarrollo iterativos e incrementales

7.1.2. 2.1.2 Modelos de Ciclo de Vida del Desarrollo de Software en Contexto

7.1.2.1. Se adaptan en función del objetivo del proyecto, el tipo de producto que se está desarrollando, las prioridades del negocio, y los riesgos de producto y de proyecto identificados

7.1.2.2. Puede ser necesario combinar o reorganizar los niveles de prueba y/o las actividades de prueba. Ej Integracion entre Sistemas.

7.1.2.3. Se pueden combinar los propios modelos de ciclo de vida de desarrollo de software. Modelo V para Back-End, Agil para Front-End.

7.1.2.4. Modelos de ciclo de vida de desarrollo de software separados para cada objeto en IoT

7.2. 2.2 Niveles de Prueba

7.2.1. 2.2.1 Prueba de Componente

7.2.1.1. Objetivos de la Prueba de Componente

7.2.1.1.1. Reducir el riesgo

7.2.1.1.2. Verificar que los comportamientos funcionales y no funcionales del componente son los diseñados y especificados

7.2.1.1.3. Generar confianza en la calidad del componente

7.2.1.1.4. Encontrar defectos en el componente

7.2.1.1.5. Prevenir la propagación de defectos a niveles de prueba superiores

7.2.1.2. Bases de Prueba

7.2.1.2.1. Diseño detallado

7.2.1.2.2. Código.

7.2.1.2.3. Modelo de datos

7.2.1.2.4. Especificaciones de los componentes

7.2.1.3. Objetos de Prueba

7.2.1.3.1. Componentes, unidades o módulos

7.2.1.3.2. Código y estructuras de datos

7.2.1.3.3. Clases

7.2.1.3.4. Módulos de base de datos

7.2.1.4. Defectos y Fallos Característicos

7.2.1.4.1. Funcionamiento incorrecto

7.2.1.4.2. Problemas de flujo de datos

7.2.1.4.3. Código y lógica incorrectos

7.2.1.5. Enfoques y Responsabilidades Específicos

7.2.1.5.1. El desarrollador que escribió el código realiza la prueba de componente

7.2.1.5.2. La redacción de casos de prueba de componente automatizados puede preceder a la redacción del código de la aplicación.

7.2.1.5.3. Enfoque "Prueba primero" como TDD.

7.2.2. 2.2.2 Prueba de Integración

7.2.2.1. Objetivos de la Prueba de Integración

7.2.2.1.1. Reducir el riesgo.

7.2.2.1.2. Verificar que los comportamientos funcionales y no funcionales de las interfaces sean los diseñados y especificados

7.2.2.1.3. Generar confianza en la calidad de las interfaces

7.2.2.1.4. Encontrar defectos

7.2.2.1.5. Prevenir la propagación de defectos a niveles de prueba superiores

7.2.2.1.6. Dos Niveles

7.2.2.2. Bases de Prueba

7.2.2.2.1. Diseño de software y sistemas

7.2.2.2.2. Diagramas de secuencia

7.2.2.2.3. Especificaciones de interfaz y protocolos de comunicación

7.2.2.2.4. Casos de uso.

7.2.2.2.5. Arquitectura a nivel de componente o de sistema

7.2.2.2.6. Flujos de trabajo.

7.2.2.2.7. Definiciones de interfaces externas

7.2.2.3. Objetos de Prueba

7.2.2.3.1. Subsistemas.

7.2.2.3.2. Bases de datos

7.2.2.3.3. Infraestructura.

7.2.2.3.4. Interfaces.

7.2.2.3.5. Interfaces de programación de aplicaciones (API)

7.2.2.3.6. Microservicios.

7.2.2.4. Defectos y Fallos Característicos (Integración de Componentes)

7.2.2.4.1. Datos incorrectos, datos faltantes o codificación incorrecta de datos

7.2.2.4.2. Secuenciación o sincronización incorrecta de las llamadas a la interfaz

7.2.2.4.3. Incompatibilidad de la interfaz

7.2.2.4.4. Fallos en la comunicación entre componentes

7.2.2.4.5. Fallos de comunicación entre componentes no tratados o tratados de forma incorrecta

7.2.2.4.6. Suposiciones incorrectas sobre el significado, las unidades o las fronteras de los datos que se transmiten entre componentes

7.2.2.5. Defectos y Fallos Característicos (Integración de Sistemas)

7.2.2.5.1. Estructuras de mensajes inconsistentes entre sistemas

7.2.2.5.2. Datos incorrectos, datos faltantes o codificación incorrecta de datos

7.2.2.5.3. Incompatibilidad de la interfaz.

7.2.2.5.4. Fallos en la comunicación entre sistemas

7.2.2.5.5. Fallos de comunicación entre sistemas no tratados o tratados de forma incorrecta

7.2.2.5.6. Incumplimiento de las normas de seguridad obligatorias

7.2.2.6. Enfoques y Responsabilidades Específicos

7.2.2.6.1. La prueba debe centrarse en la comunicación entre los módulos (o sistemas), no en la funcionalidad de los módulos individuales

7.2.2.6.2. En general es responsabilidad de los probadores

7.2.2.6.3. Estrategias de integracion

7.2.3. 2.2.3 Prueba de Sistema

7.2.3.1. Objetivos de la Prueba de Sistema

7.2.3.1.1. Reducir el riesgo.

7.2.3.1.2. Verificar que los comportamientos funcionales y no funcionales del sistema son los diseñados y especificados

7.2.3.1.3. Validar que el sistema está completo y que funcionará como se espera

7.2.3.1.4. Generar confianza en la calidad del sistema considerado como un todo

7.2.3.1.5. Encontrar defectos

7.2.3.1.6. Prevenir la propagación de defectos a niveles de prueba superiores o a producción

7.2.3.2. Bases de Prueba

7.2.3.2.1. Especificaciones de requisitos del sistema y del software (funcionales y no funcionales).

7.2.3.2.2. Informes de análisis de riesgo

7.2.3.2.3. Casos de uso

7.2.3.2.4. Épicas e historias de usuario

7.2.3.2.5. Modelos de comportamiento del sistema

7.2.3.2.6. Diagramas de estado

7.2.3.2.7. Manuales del sistema y del usuario

7.2.3.3. Objetos de Prueba

7.2.3.3.1. Aplicaciones.

7.2.3.3.2. Sistemas hardware/software

7.2.3.3.3. Sistemas operativos

7.2.3.3.4. Sistema sujeto a prueba

7.2.3.3.5. Configuración del sistema y datos de configuración

7.2.3.4. Defectos y Fallos Característicos

7.2.3.4.1. Cálculos incorrectos

7.2.3.4.2. Comportamiento funcional o no funcional del sistema incorrecto o inesperado

7.2.3.4.3. Control y/o flujos de datos incorrectos dentro del sistema

7.2.3.4.4. Incapacidad para llevar a cabo, de forma adecuada y completa, las tareas funcionales extremo a extremo

7.2.3.4.5. Fallo del sistema para operar correctamente en el/los entorno/s de producción

7.2.3.4.6. Fallo del sistema para funcionar como se describe en los manuales del sistema y de usuario

7.2.3.5. Enfoques y Responsabilidades Específicos

7.2.3.5.1. Debe centrarse en el comportamiento global y extremo a extremo del sistema en su conjunto, tanto funcional como no funcional

7.2.3.5.2. Los probadores independientes, en general, llevan a cabo la prueba de sistema.

7.2.4. 2.2.4 Prueba de Aceptación

7.2.4.1. Objetivos de la Prueba de Aceptación

7.2.4.1.1. Establecer confianza en la calidad del sistema en su conjunto

7.2.4.1.2. Validar que el sistema está completo y que funcionará como se espera

7.2.4.1.3. Verificar que los comportamientos funcionales y no funcionales del sistema sean los especificados

7.2.4.1.4. Los defectos pueden encontrarse durante las prueba de aceptación, pero encontrar defectos no suele ser un objetivo

7.2.4.2. Tipos

7.2.4.2.1. Prueba de Aceptación de Usuario (UAT por sus siglas en inglés)

7.2.4.2.2. Prueba de Aceptación Operativa

7.2.4.2.3. Prueba de Aceptación Contractual y Normativa

7.2.4.2.4. Pruebas Alfa y Beta

7.2.4.3. Base de Prueba

7.2.4.3.1. Procesos de negocio

7.2.4.3.2. Requisitos de usuario o de negocio

7.2.4.3.3. Normativas, contratos legales y estándares

7.2.4.3.4. Casos de uso

7.2.4.3.5. Requisitos de sistema

7.2.4.3.6. Documentación del sistema o del usuario

7.2.4.3.7. Procedimientos de instalación.

7.2.4.3.8. Informes de análisis de riesgo

7.2.4.4. Productos de Trabajo utilizados

7.2.4.4.1. Procedimientos de copia de seguridad y restauración

7.2.4.4.2. Procedimientos de recuperación de desastres

7.2.4.4.3. Requisitos no funcionales

7.2.4.4.4. Documentación de operaciones

7.2.4.4.5. Instrucciones de despliegue e instalación

7.2.4.4.6. Objetivos de rendimiento

7.2.4.4.7. Paquetes de base de datos

7.2.4.4.8. Estándares o reglamentos de seguridad

7.2.4.5. Objetos de Prueba Característicos

7.2.4.5.1. Sistema sujeto a prueba

7.2.4.5.2. Configuración del sistema y datos de configuración

7.2.4.5.3. Procesos de negocio para un sistema totalmente integrado

7.2.4.5.4. Sistemas de recuperación y sitios críticos

7.2.4.5.5. Procesos operativos y de mantenimiento

7.2.4.5.6. Formularios.

7.2.4.5.7. Informes.

7.2.4.5.8. Datos de producción existentes y transformados

7.2.4.6. Defectos y Fallos Característicos

7.2.4.6.1. Los flujos de trabajo del sistema no cumplen con los requisitos de negocio o de usuario

7.2.4.6.2. Las reglas de negocio no se implementan de forma correcta

7.2.4.6.3. El sistema no satisface los requisitos contractuales o reglamentarios

7.2.4.6.4. Fallos no funcionales (Seguridad, Rendimiento)

7.2.4.7. Enfoques y Responsabilidades Específicos

7.2.4.7.1. Responsabilidad de los clientes, usuarios de negocio, propietarios de producto u operadores de un sistema,

7.2.4.7.2. Último nivel de prueba en un ciclo de vida de desarrollo secuencial

7.2.4.7.3. En el desarrollo iterativo se pueden emplear varias formas de prueba de aceptación

7.3. 2.3 Tipos de Prueba

7.3.1. 2.3.1 Prueba Funcional

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

7.3.1.2. Se deben realizar en todos los niveles de prueba

7.3.1.3. Observa el comportamiento del software

7.3.1.4. Utiliza técnicas de caja negra

7.3.1.5. Se puede medir a través de la cobertura funcional

7.3.1.6. Implica conocimiento del problema de negocio específico que resuelve el software

7.3.2. 2.3.2 Prueba No Funcional

7.3.2.1. Evalúa las características de los sistemas y software. "Que tan bien" se comporta.

7.3.2.2. El estándar ISO/IEC 25010 clasifica las características de calidad de producto software

7.3.2.3. Se pueden y, a menudo, se deben realizar pruebas no funcionales en todos los niveles de prueba

7.3.2.4. Se deben realizar tan pronto como sea posible

7.3.2.5. Se puede medir través de la cobertura no funcional

7.3.2.6. Implica competencias o conocimientos como las debilidades inherentes a un diseño o tecnología o la base de usuarios concreta

7.3.3. 2.3.3 Prueba de Caja Blanca

7.3.3.1. Pruebas basadas en la estructura interna del sistema o en su implementación

7.3.3.1.1. Codigo

7.3.3.1.2. Arquitectura

7.3.3.1.3. Flujos de trabajo

7.3.3.1.4. Flujos de datos

7.3.3.2. Se puede medir a través de la cobertura estructural

7.3.3.2.1. Cobertura de código

7.3.3.2.2. Cobertura estructural

7.3.3.3. Implicar competencias o conocimientos como la forma en que se construye el código o como se almacenan los datos.

7.3.4. 2.3.4 Prueba Asociada al Cambio

7.3.4.1. Prueba de confirmación

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

7.3.4.2. Prueba de regresión

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

7.3.4.2.2. Fuerte candidato para la automatización

7.3.4.3. Consideraciones

7.3.4.3.1. Se realizan en todos los niveles de prueba

7.3.4.3.2. Importante en Desarrollo Ágil y Sistemas IoT

7.3.5. 2.3.5 Tipos de Prueba y Niveles de Prueba

7.3.5.1. Es posible realizar cualquiera de los tipos de prueba mencionados anteriormente en cualquier nivel de prueba.

7.4. 2.4 Prueba de Mantenimiento

7.4.1. 2.4.1 Activadores para el Mantenimiento

7.4.1.1. Modificación

7.4.1.1.1. Mejoras planificadas

7.4.1.1.2. Cambios correctivos

7.4.1.1.3. Cambios de emergencia

7.4.1.1.4. Cambios en el S.O.

7.4.1.2. Migracion

7.4.1.2.1. De una plataforma a otra

7.4.1.2.2. De datos

7.4.1.3. Retirada

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

7.4.1.3.2. Procedimientos de restauración/recuperación

7.4.2. 2.4.2 Análisis de Impacto para el Mantenimiento

7.4.2.1. Identifica las áreas del sistema que se verán afectadas por el cambio

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

7.4.2.3. Puede ser difícil si:

7.4.2.3.1. Las especificaciones están desactualizadas o no existen

7.4.2.3.2. Los casos de prueba no están documentados o están desactualizados

7.4.2.3.3. No se ha mantenido la trazabilidad bidireccional entre las pruebas y la base de prueba

7.4.2.3.4. El soporte de herramientas es débil o inexistente

7.4.2.3.5. Las personas involucradas no tienen conocimientos de dominio y/o sistema

7.4.2.3.6. No se ha prestado suficiente atención a la mantenibilidad del software durante el desarrollo

8. 3. Prueba Estática

8.1. 3.1 Prueba Estática: Conceptos Básicos

8.1.1. 3.1.0 Introducción

8.1.1.1. La prueba estatica se basa en

8.1.1.1.1. Revisiones - evaluación manual de los productos de trabajo

8.1.1.1.2. Análisis Estático - evaluación basada en herramientas del código u otros productos de trabajo

8.1.2. 3.1.1 Productos de Trabajo que Pueden Ser Evaluados por una Prueba Estática

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

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

8.1.2.3. Especificaciones de arquitectura y diseño

8.1.2.4. Código.

8.1.2.5. Producto de prueba, incluyendo planes de prueba, casos de prueba, procedimientos de prueba y guiones de prueba automatizados

8.1.2.6. Guías de usuario

8.1.2.7. Páginas web

8.1.2.8. Contratos, planes de proyecto, calendarios y presupuestos

8.1.3. 3.1.2 Ventajas de la Prueba Estática

8.1.3.1. Detección y corrección de defectos de forma más eficiente y antes de la ejecución de la prueba dinámica

8.1.3.2. Identificar defectos que no se encuentran fácilmente mediante prueba dinámica

8.1.3.3. Prevenir defectos en el diseño o la codificación descubriendo inconsistencias, ambigüedades, contradicciones, omisiones, inexactitudes y redundancias en los requisitos

8.1.3.4. Incrementar la productividad de desarrollo

8.1.3.5. Reducir el coste y el tiempo de desarrollo

8.1.3.6. Reducir el coste y el tiempo de la prueba

8.1.3.7. Reducir el coste total de la calidad durante la vida útil del software

8.1.3.8. Mejorar la comunicación entre los miembros del equipo en el curso de la participación en revisiones

8.1.4. 3.1.3 Diferencias entre la Prueba Estática y la Prueba Dinámica

8.1.4.1. La prueba estática detecta defectos en los productos de trabajo directamente

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

8.1.4.3. La prueba estática se puede utilizar para mejorar la consistencia y la calidad interna de los productos de trabajo

8.1.4.4. Defectos tipicos

8.1.4.4.1. Defectos en los requisitos

8.1.4.4.2. Defectos de diseño

8.1.4.4.3. Defectos de codificación

8.1.4.4.4. Desviaciones con respecto a estándares

8.1.4.4.5. Especificaciones de interfaz incorrectas

8.1.4.4.6. Vulnerabilidades de seguridad

8.1.4.4.7. Deficiencias o inexactitudes en la trazabilidad o cobertura de la base de prueba

8.2. 3.2 Proceso de Revisión

8.2.1. 3.2.1 Proceso de Revisión de Productos de Trabajo

8.2.1.1. Planificación

8.2.1.1.1. Definir el alcance, que incluye el objetivo de la revisión

8.2.1.1.2. Estimar el esfuerzo y plazos

8.2.1.1.3. Identificar las características de la revisión

8.2.1.1.4. Seleccionar las personas y roles que participarán en la revisión

8.2.1.1.5. Definir los criterios de entrada y salida (revisiones formales)

8.2.1.1.6. Comprobar el cumplimiento de los criterios de entrada (revisiones formales)

8.2.1.2. Iniciar Revisión

8.2.1.2.1. Distribuir el producto de trabajo y otros materiales relacionados

8.2.1.2.2. Explicar a los participantes el alcance, los objetivos, el proceso.

8.2.1.2.3. Responder preguntas de los participantes

8.2.1.3. Revisión Individual (es decir, preparación individual)

8.2.1.3.1. Revisar todo o parte del producto de trabajo.

8.2.1.3.2. Notificar posibles defectos, recomendaciones y preguntas

8.2.1.4. Comunicación y Análisis de Cuestiones

8.2.1.4.1. Comunicar los defectos potenciales identificados

8.2.1.4.2. Analizar los posibles defectos

8.2.1.4.3. Evaluar y documentar las características de calidad

8.2.1.4.4. Evaluar los hallazgos de la revisión con respecto a los criterios de salida

8.2.1.5. Corregir e Informar

8.2.1.5.1. Elaborar informes de defecto

8.2.1.5.2. Corregir los defectos detectados

8.2.1.5.3. Comunicar defectos a la persona o equipo adecuado

8.2.1.5.4. Registrar el estado actualizado de los defectos

8.2.1.5.5. Recopilación de métricas

8.2.1.5.6. Comprobar el cumplimiento de los criterios de salida

8.2.1.5.7. Aceptar el producto de trabajo cuando se alcanzan los criterios de salida

8.2.2. 3.2.2 Roles y Responsabilidades en una Revisión Formal

8.2.2.1. Autor

8.2.2.1.1. Crea el producto de trabajo bajo revisión

8.2.2.1.2. Corrige los defectos en el producto de trabajo bajo revisión

8.2.2.2. Dirección

8.2.2.2.1. Es responsable de la planificación de la revisión

8.2.2.2.2. Decide acerca de la ejecución de las revisiones

8.2.2.2.3. Asigna personal, presupuesto y tiempo

8.2.2.2.4. Supervisa la rentabilidad en curso

8.2.2.2.5. Ejecuta las decisiones de control en caso de resultados inadecuados

8.2.2.3. Facilitador (a menudo llamado moderador)

8.2.2.3.1. Asegura el funcionamiento efectivo de las reuniones de revisión

8.2.2.3.2. Si fuera necesario, realiza una mediación entre los distintos puntos de vista

8.2.2.3.3. A menudo, es la persona de la que depende el éxito de la revisión

8.2.2.4. Líder de Revisión

8.2.2.4.1. Asume la responsabilidad general de la revisión

8.2.2.4.2. Decide quiénes estarán involucrados y organiza cuándo y dónde se llevará a cabo

8.2.2.5. Revisores

8.2.2.5.1. Pueden ser

8.2.2.5.2. Identificar posibles defectos en el producto de trabajo bajo revisión

8.2.2.5.3. Puede representar diferentes perspectivas

8.2.2.6. Escriba (o grabador)

8.2.2.6.1. Recopila los posibles defectos encontrados durante la actividad de revisión individual

8.2.2.6.2. Registra

8.2.3. 3.2.3 Tipos de Revisión

8.2.3.1. Revisión Informal (Revisión de pares)

8.2.3.1.1. Objetivo principal: detectar defectos potenciales

8.2.3.1.2. Posibles objetivos adicionales: generar nuevas ideas o soluciones, resolver de forma rápida problemas menores

8.2.3.1.3. No se basa en un proceso formal (documentado).

8.2.3.1.4. Puede no implicar una reunión de revisión

8.2.3.1.5. Puede ser realizado por un compañero de trabajo del autor o por más personas

8.2.3.1.6. Se pueden documentar los resultados.

8.2.3.1.7. Varía en utilidad dependiendo de los revisores

8.2.3.1.8. El uso de listas de comprobación es opcional

8.2.3.1.9. Utilizado con mucha frecuencia en el desarrollo Ágil

8.2.3.2. Revisión Guiada

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

8.2.3.2.2. Posibles objetivos adicionales: intercambio de ideas sobre técnicas o variaciones de estilo,

8.2.3.2.3. La preparación individual antes de la reunión de revisión es opcional

8.2.3.2.4. Normalmente, la reunión de revisión está dirigida por el autor del producto de trabajo

8.2.3.2.5. El escriba es obligatorio

8.2.3.2.6. El uso de listas de comprobación es opcional

8.2.3.2.7. Puede tomar la forma de escenarios, ensayos, o simulaciones

8.2.3.2.8. Se pueden elaborar registros de posibles defectos e informes de revisión

8.2.3.2.9. En la práctica puede variar de bastante informal a muy formal

8.2.3.3. Revisión Técnica

8.2.3.3.1. Objetivos principales: lograr un consenso, detectar defectos potenciales

8.2.3.3.2. Posibles objetivos adicionales: evaluar la calidad y generar confianza en el producto de trabajo, generar nuevas ideas

8.2.3.3.3. Los revisores deben ser pares técnicos del autor y expertos técnicos en la misma u otras disciplinas

8.2.3.3.4. Es necesario que haya una preparación individual antes de la reunión de revisión

8.2.3.3.5. La reunión de revisión es opcional, lo ideal es que la dirija un facilitador capacitado

8.2.3.3.6. El escriba es obligatorio, lo ideal es que no sea el autor

8.2.3.3.7. El uso de listas de comprobación es opcional

8.2.3.3.8. Normalmente se elaboran registros de defectos potenciales e informes de revisión

8.2.3.4. Inspección

8.2.3.4.1. Objetivos principales: detectar defectos potenciales, evaluar la calidad y generar confianza en el producto de trabajo, prevenir futuros defectos similares

8.2.3.4.2. Posibles objetivos adicionales: motivar y capacitar a los autores para que mejoren los futuros productos de trabajo y el proceso de desarrollo de software

8.2.3.4.3. Sigue un proceso definido con resultados documentados formales, basados en reglas y listas de comprobación

8.2.3.4.4. Utiliza roles claramente definidos, como los especificados en la sección 3.2.2, que son obligatorios

8.2.3.4.5. Es necesario que haya una preparación individual antes de la reunión de revisión

8.2.3.4.6. Los revisores son pares del autor o expertos en otras disciplinas que son relevantes para el producto de trabajo.

8.2.3.4.7. Se utilizan criterios especificados de entrada y salida

8.2.3.4.8. El escriba es obligatorio

8.2.3.4.9. La reunión de revisión es dirigida por un facilitador capacitado (no el autor)

8.2.3.4.10. El autor no puede actuar como líder de revisión, lector o escriba

8.2.3.4.11. Se elaboran registros de defectos potenciales e informes de revisión

8.2.3.4.12. Se recopilan y utilizan métricas para mejorar el proceso

8.2.4. 3.2.4 Aplicación de Técnicas de Revisión

8.2.4.1. Ad hoc

8.2.4.1.1. Los revisores reciben poca o ninguna orientación sobre cómo se debe realizar esta tarea

8.2.4.2. Basada en Lista de Comprobación

8.2.4.2.1. Los revisores detectan cuestiones basadas en listas de comprobación que se distribuyen al inicio de la revisión

8.2.4.3. Escenarios y Ensayos

8.2.4.3.1. Los revisores reciben pautas estructuradas sobre cómo leer el producto de trabajo

8.2.4.3.2. Los Escenarios dan más pautas para identificar tipos de defectos específicos que las listas de comprobación.

8.2.4.4. Basada en Roles

8.2.4.4.1. Los revisores evalúan el producto de trabajo desde la perspectiva de roles individuales

8.2.4.5. Basada en Perspectiva

8.2.4.5.1. Los revisores adoptan los diferentes puntos de vista de los implicados en la revisión individual

8.2.5. 3.2.5 Factores de Éxito para las Revisiones

8.2.5.1. Relativo a la Organizacion

8.2.5.1.1. Cada revisión tiene objetivos claros, definidos durante la planificación de la revisión y utilizados como criterios de salida medibles

8.2.5.1.2. Se aplican tipos de revisión que son adecuados para lograr los objetivos y que son apropiados para el tipo y nivel de los productos de trabajo de software y de los participantes

8.2.5.1.3. Cualquier técnica de revisión utilizada es adecuada para la identificación efectiva de defectos en el producto de trabajo que se va a revisar

8.2.5.1.4. Cualquier lista de comprobación utilizada aborda los riesgos principales y se encuentra actualizada

8.2.5.1.5. Los documentos de gran tamaño se redactan y revisan en pequeños fragmentos

8.2.5.1.6. Los participantes disponen de tiempo suficiente para prepararse

8.2.5.1.7. Se establece un calendario de revisiones con la debida antelación

8.2.5.1.8. La dirección apoya el proceso de revisión

8.2.5.2. Relativo a las Personas

8.2.5.2.1. Se involucra a las personas adecuadas para alcanzar los objetivos de la revisión

8.2.5.2.2. Los probadores son vistos como revisores valiosos que contribuyen a la revisión y aprenden sobre el producto de trabajo

8.2.5.2.3. Los participantes dedican tiempo y atención adecuados a los detalles

8.2.5.2.4. Las revisiones se llevan a cabo en pequeños fragmentos

8.2.5.2.5. Los defectos detectados son reconocidos, valorados y tratados objetivamente

8.2.5.2.6. La reunión está bien gestionada

8.2.5.2.7. La revisión se lleva a cabo en un clima de confianza

8.2.5.2.8. Se evita el lenguaje corporal y las conductas que indiquen aburrimiento,exasperación u hostilidad

8.2.5.2.9. Se proporciona la formación adecuada

8.2.5.2.10. Se promueve una cultura de aprendizaje y mejora de los procesos

9. 4. Técnicas de Prueba

9.1. 4.1 Categorías de Técnicas de Prueba

9.1.1. 4.1.1 Elección de Técnicas de Prueba

9.1.1.1. Factores

9.1.1.1.1. Tipo de componente o sistema

9.1.1.1.2. Complejidad del componente o del sistema.

9.1.1.1.3. Estándares de regulación

9.1.1.1.4. Requisitos del cliente o contractuales

9.1.1.1.5. Niveles de riesgo

9.1.1.1.6. Clases de riesgo

9.1.1.1.7. Objetivos de prueba

9.1.1.1.8. Documentación disponible

9.1.1.1.9. Conocimientos y competencias del probador

9.1.1.1.10. Herramientas disponibles

9.1.1.1.11. Tiempo y presupuesto

9.1.1.1.12. Modelo de ciclo de vida de desarrollo de software

9.1.1.1.13. Uso previsto del software

9.1.1.1.14. Experiencia previa en el uso de las técnicas, componente o sistema a probar

9.1.1.1.15. Los tipos de defectos esperados en el componente o sistema

9.1.2. 4.1.2 Categorías de Técnicas de Prueba y sus Características

9.1.2.1. Técnicas de prueba de la caja negra

9.1.2.1.1. Base de Prueba (de la cual se deducen las condiciones de la prueba, los casos de prueba y los datos de la prueba)

9.1.2.1.2. Uso de los casos de prueba

9.1.2.1.3. La cobertura se mide en función de los elementos probados en la base de prueba y de la técnica aplicada a la base de prueba.

9.1.2.2. Técnicas de prueba de caja blanca

9.1.2.2.1. Base de Prueba (de la cual se deducen las condiciones de la prueba, los casos de prueba y los datos de la prueba)

9.1.2.2.2. La cobertura se mide en base a los elementos probados dentro de una estructura seleccionada

9.1.2.2.3. Las especificaciones se utilizan a menudo como una fuente adicional de información para determinar el resultado esperado de los casos de prueba.

9.1.2.3. Técnicas de prueba basadas en la experiencia

9.1.2.3.1. Base de Prueba (de la cual se deducen las condiciones de la prueba, los casos de prueba y los datos de la prueba)

9.2. 4.2 Técnicas de Prueba de Caja Negra

9.2.1. 4.2.1 Partición de Equivalencia

9.2.1.1. Divide los datos en particiones

9.2.1.2. Existen particiones de equivalencia tanto para valores válidos como no válidos

9.2.1.2.1. Los valores válidos son los valores que debe aceptar el componente o el sistema. Una partición de equivalencia que contiene valores válidos se llama "partición de equivalencia válida".

9.2.1.2.2. Los valores no válidos son valores que deben ser rechazados por el componente o sistema. Una partición de equivalencia que contiene valores no válidos se llama "partición de equivalencia no válida".

9.2.1.2.3. Las particiones pueden identificarse para cualquier elemento de datos relacionado con el objeto de prueba, incluyendo entradas, salidas, valores internos, valores relacionados con el tiempo y para parámetros de interfaz

9.2.1.2.4. Cualquier partición se puede dividir en subparticiones si fuera necesario

9.2.1.2.5. Cada valor debe pertenecer a una y sólo a una partición de equivalencia

9.2.1.2.6. Cuando se utilizan particiones de equivalencia no válidas en casos de prueba, deben probarse individualmente, es decir, no combinarse con otras particiones de equivalencia no válidas, para garantizar que no se produzca un enmascaramiento de los fallos. Los fallos se pueden enmascarar cuando se producen varios fallos al mismo tiempo, pero sólo uno de ellos es visible, lo que hace que los otros fallos queden sin detectar.

9.2.1.3. La cobertura se mide como el número de particiones de equivalencia probadas por al menos un valor, dividido por el número total de particiones de equivalencia identificadas

9.2.1.4. Ejemplo

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

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

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

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

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

9.2.2.5. La cobertura de frontera para una partición se mide como el número de valores frontera probados, dividido por el número total de valores frontera de prueba identificados, normalmente expresado como un porcentaje

9.2.2.6. Ejemplo

9.2.3. 4.2.3 Prueba de Tabla de Decisión

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

9.2.3.2. Buena manera de documentar reglas de negocio complejas que un sistema debe implementar

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

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

9.2.3.5. La tabla se puede colapsar

9.2.3.5.1. Borrando las columnas que contienen combinaciones de condiciones imposibles

9.2.3.5.2. Borrando las columnas que contienen combinaciones de condiciones posibles pero no factibles

9.2.3.5.3. Borrando las columnas que prueban combinaciones de condiciones que no afectan al resultado.

9.2.3.6. Cobertura

9.2.3.6.1. % del número de reglas de decisión probadas por, al menos, un caso de prueba, dividido por el número total de reglas de decisión.

9.2.3.7. Ejemplo

9.2.4. 4.3.4 Prueba de Transición de Estado

9.2.4.1. Elementos

9.2.4.1.1. Estado

9.2.4.1.2. Transicion

9.2.4.1.3. Evento

9.2.4.1.4. Accion

9.2.4.2. Un diagrama de transición de estado muestra

9.2.4.2.1. Los posibles estados del software,

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

9.2.4.3. Una tabla de transición de estado muestra

9.2.4.3.1. Todas las transiciones válidas

9.2.4.3.2. las transiciones potencialmente inválidas entre estados

9.2.4.3.3. Los eventos

9.2.4.3.4. Condiciones de guarda

9.2.4.3.5. Las acciones resultantes para las transiciones válidas

9.2.4.4. Diseño de Pruebas

9.2.4.4.1. Para cubrir una secuencia de estados típica

9.2.4.4.2. Para practicar todos los estados

9.2.4.4.3. Para practicar cada transición

9.2.4.4.4. Para practicar secuencias específicas de transiciones

9.2.4.4.5. Para probar transiciones inválidas

9.2.4.5. Utilización

9.2.4.5.1. Aplicaciones basadas en menús

9.2.4.5.2. Industria del software embebido

9.2.4.5.3. Modelar un escenario de negocio con estados específicos

9.2.4.5.4. Probar la navegación en pantalla

9.2.4.6. Cobertura

9.2.4.6.1. % 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

9.2.5. 4.2.5 Prueba de Caso de Uso

9.2.5.1. Un caso de uso especifica algún comportamiento que un sujeto (sistema) puede realizar en colaboración con uno o más actores

9.2.5.2. Las pruebas están diseñadas para practicar los comportamientos definidos

9.2.5.2.1. Básicas

9.2.5.2.2. Excepcionales o alternativas

9.2.5.2.3. Tratamiento de errores

9.2.5.3. Cobertura

9.2.5.3.1. % de comportamientos de casos de uso probados dividido por el número total de comportamientos de casos de uso.

9.3. 4.3 Técnicas de Prueba de Caja Blanca

9.3.1. 4.3.0 Caracteristicas

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

9.3.1.2. Se pueden utilizar en todos los niveles de prueba

9.3.1.3. En algunos entornos de seguridad crítica, de misión críticas se usan técnicas avanzadas

9.3.2. 4.3.1 Prueba y Cobertura de Sentencia

9.3.2.1. Practica las sentencias ejecutables en el código

9.3.2.2. Cobertura

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

9.3.2.3. Ejemplo

9.3.3. 4.3.2 Prueba y Cobertura de Decisión

9.3.3.1. Practica las decisiones en el código y prueba el código que se ejecuta basado en los resultados de la decisión

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

9.3.3.3. Cobertura

9.3.3.3.1. % 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

9.3.3.4. Ejemplo

9.3.4. 4.3.3 El Valor de la Prueba de Sentencia y Decisión

9.3.4.1. Cobertura del 100% de sentencia

9.3.4.1.1. Asegura de que todas las sentencias ejecutables del código se han probado al menos una vez

9.3.4.1.2. No asegura que se haya probado toda la lógica de decisión

9.3.4.2. 100% de cobertura de decisión

9.3.4.2.1. Se han ejecutado todos los resultados de decisión (Verdadero y Falso)

9.3.4.3. Lograr una cobertura del 100% de decisión garantiza una cobertura del 100% de sentencia

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

9.4.1. 4.4.1 Predicción de Errores

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

9.4.1.1.1. Cómo ha funcionado la aplicación en el pasado

9.4.1.1.2. Qué tipo de equivocaciones tienden a cometer los desarrolladores

9.4.1.1.3. Fallos que se han producido en otras aplicaciones

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

9.4.2. 4.4.2 Prueba Exploratoria

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

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

9.4.2.2.1. Se lleva a cabo dentro de un período de tiempo definido.

9.4.2.2.2. El probador utiliza un contrato de prueba (objetivo)

9.4.2.2.3. El probador puede usar hojas de sesión de prueba para documentar

9.4.2.3. Utilidad

9.4.2.3.1. Cuando las especificaciones son escasas o inadecuadas

9.4.2.3.2. Cuando hay una presión significativa con respecto al tiempo para la prueba

9.4.2.3.3. Paracomplementar otras técnicas de prueba más formales

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

9.4.3. 4.4.3 Prueba Basada en Listas de Comprobación

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

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

9.4.3.3. Dan soporte pruebas funcionales y no funcionales

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