ISTQB CTFL 2018

1. 6. Soporte de Herramientas para el proceso de pruebas

1.1. 6.1 Consideraciones sobre las Herramientas de Prueba

1.1.1. 6.1.1 Clasificación de las Herramientas de Prueba

1.1.1.1. Objetivos posibles

1.1.1.1.1. Mejorar la eficiencia de las actividades de prueba

1.1.1.1.2. Mejorar la calidad de las actividades de prueba

1.1.1.1.3. Automatizar actividades que no se pueden ejecutar manualmente

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

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

1.1.1.2.2. Herramientas de gestión de requisitos

1.1.1.2.3. Herramientas de gestión de defectos

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

1.1.1.2.5. Herramientas de integración continua

1.1.1.3. Soporte de Herramientas para la Prueba Estática

1.1.1.3.1. Herramientas de apoyo a las revisiones

1.1.1.3.2. Herramientas de análisis estático

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

1.1.1.4.1. Herramientas para la prueba de rendimiento

1.1.1.4.2. Herramientas de monitorización

1.1.1.5. Soporte de Herramientas para Necesidades de Prueba Especializadas

1.1.1.5.1. Evaluación de la calidad de los datos

1.1.1.5.2. Conversión y migración de datos

1.1.1.5.3. Prueba de usabilidad

1.1.1.5.4. Prueba de seguridad

1.1.1.5.5. Prueba de portabilidad

1.2. 6.2 Uso Eficaz de las Herramientas

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

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

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

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

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

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

1.2.1.6. Evaluar al proveedor o soporte para herramientas no comerciales

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

1.2.1.8. 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).

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

1.2.2.1. Objetivos

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

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

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

1.2.2.1.4. Comprender las métricas que se desea que la herramienta recopile e informe

1.2.3. 6.2.3 Factores de Éxito para Herramientas

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

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

1.2.3.3. Entrenamiento

1.2.3.4. Definicion de directrices para el uso

1.2.3.5. MOnitorear el uso

1.2.3.6. Proporcionar apoyo a usuarios

2. 5. Gestión de la Prueba

2.1. 5.1 Organización de la Prueba

2.1.1. 5.1.1 Independencia de las pruebas

2.1.1.1. 1.Probadores no independientes

2.1.1.2. 2.Desarrolladores independientes o probadores dentro de los equipos de desarrollo

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

2.1.1.4. 4.Equipos de prueba por fuera de la organizacion

2.1.1.5. Beneficios

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

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

2.1.1.6. Desventajas

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

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

2.1.2. 5.1.2 Tareas de un lider de Prueba y un Probador

2.1.2.1. Lider de Prueba

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

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

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

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

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

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

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

2.1.2.2. Probador

2.1.2.2.1. Revisar y contribuir a los planes de prueba

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

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

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

2.1.2.2.5. Preparar y obtener datos de prueba

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

2.1.2.2.7. Automatizar las pruebas según sea necesario

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

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

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

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

2.2.1.2. Definir el enfoque general de la prueba

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

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

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

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

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

2.2.2. 5.2.2 Estrategia y Enfoque de la Prueba

2.2.2.1. Analítica

2.2.2.1.1. Las pruebas se analizan

2.2.2.2. Basada en Modelos

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

2.2.2.3. Metódica

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

2.2.2.4. Conforme a Proceso

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

2.2.2.5. Dirigida (o consultiva)

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

2.2.2.6. Adversa a la Regresión

2.2.2.6.1. Adversa a la Regresión

2.2.2.6.2. Reutilización de productos de prueba existentes

2.2.2.6.3. Automatización extensiva de las pruebas

2.2.2.7. Reactiva

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

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

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

2.2.3.1. Criterios de entrada habituales

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

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

2.2.3.1.3. Disponibilidad del entorno de prueba

2.2.3.1.4. Disponibilidad de las herramientas de prueba necesarias

2.2.3.1.5. Disponibilidad de datos de prueba y otros recursos necesarios

2.2.3.2. Criterios de salida habituales

2.2.3.2.1. Las pruebas planificadas han sido ejecutadas

2.2.3.2.2. Se ha logrado un nivel de cobertura definido

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

2.2.4. 5.2.4 Calendario de Ejecución de Prueba

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

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

2.2.4.3. Factores a tener en cuenta

2.2.4.3.1. Priorizacion

2.2.4.3.2. Dependencias

2.2.4.3.3. Pruebas de confirmación

2.2.4.3.4. Pruebas de regresión

2.2.4.3.5. Secuencia más eficaz para ejecutar las pruebas

2.2.5. 5.2.5 Factores que Influyen en el Esfuerzo de Prueba

2.2.5.1. Características del Producto

2.2.5.1.1. Los riesgos asociados al producto

2.2.5.1.2. La calidad de la base de prueba

2.2.5.1.3. El tamaño del producto

2.2.5.1.4. La complejidad del dominio del producto

2.2.5.1.5. Los requisitos para las características de calidad

2.2.5.2. Características del Proceso de Desarrollo

2.2.5.2.1. La estabilidad y madurez de la organización

2.2.5.2.2. El modelo de desarrollo en uso

2.2.5.2.3. El enfoque de prueba

2.2.5.2.4. Las herramientas utilizadas

2.2.5.2.5. El proceso de prueba

2.2.5.2.6. Presión con respecto al tiempo

2.2.5.3. Características de las Personas

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

2.2.5.3.2. Cohesión y liderazgo del equipo.

2.2.5.4. Resultados de la Prueba

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

2.2.5.4.2. La cantidad de reconstrucción necesaria

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

2.2.6.1. La técnica basada en métricas

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

2.2.6.2. La técnica basada en expertos

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

2.3. 5.3 Monitorización y Control de la Prueba

2.3.1. 5.3.1 Métricas Utilizadas en la Prueba

2.3.1.1. Que Evaluan?

2.3.1.1.1. Avance con respecto al calendario y presupuesto previstos

2.3.1.1.2. Calidad actual del objeto de prueba

2.3.1.1.3. Adecuación del enfoque de prueba

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

2.3.1.2. Metricas comunes

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

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

2.3.1.2.3. Ejecución de casos de prueba

2.3.1.2.4. Información sobre defectos

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

2.3.1.2.6. El coste de la prueba

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

2.3.2.1. Objetivo

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

2.3.2.2. Informe de avance

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

2.3.2.2.2. Factores que impiden el avance

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

2.3.2.2.4. La calidad del objeto de prueba

2.3.2.3. Informe de resumen

2.3.2.3.1. Resumen de la prueba realizada

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

2.3.2.3.3. Desviaciones con respecto al plan,

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

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

2.4. 5.4 Gestión de la Configuración

2.4.1. Objetivo

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

2.4.2. Asegurarse de

2.4.2.1. Todos los elementos de prueba

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

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

2.5. 5.5 Riesgos

2.5.1. 5.5.1 Definición de Riesgo

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

2.5.2. 5.5.2 Riesgos de Producto y Riesgos de Proyecto

2.5.2.1. Riesgo de Producto

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

2.5.2.1.2. ejemplos

2.5.2.2. Riesgo de Proyecto (Jefes de proyecto)

2.5.2.2.1. implica situaciones que en caso que ocurran pueden tener un efecto negativo en la capacidad de lograr los objetivos

2.5.2.2.2. ejemplos

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

2.5.3.1. Basada en riesgos

2.5.3.1.1. Se usa para priorizar las pruebas, donde y cuando empezar?

2.5.3.1.2. Que areas necesitan más atencion

2.5.3.1.3. determinar los niveles y tipos de pruebas a realizar

2.5.3.2. mitigarlos

2.5.3.2.1. implementar acciones para mitigar los riegos

2.5.3.2.2. elaborar planes de contigencia

2.6. 5.6 Gestión de Defectos

2.6.1. Objetivos

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

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

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

2.6.2. Contenido de un Informe de Defecto

2.6.2.1. Un identificador

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

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

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

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

2.6.2.6. Resultados esperados y reales

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

2.6.2.8. Urgencia/prioridad de la corrección

2.6.2.9. Estado del informe de defecto

2.6.2.10. Conclusiones, recomendaciones y aprobaciones

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

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

3. 1. Fundamentos del Proceso de prueba

3.1. 1.2 ¿Por qué es Necesario Probar?

3.1.1. 1.2.1 Contribuciones de la Prueba al Éxito (Importancia de las pruebas)

3.1.1.1. La identificación y eliminación de defectos en los requisitos lo cual reduce el riesgo de desarrollar funcionalidades incorrectas

3.1.1.2. Aumentar la comprensión sobre el diseño y la forma de probarlo, reduciendo el riesgo de defectos de diseño

3.1.1.3. Puede detectar fallos que de otro modo podrían haberse omitido aumentando la probabilidad de que el software cumpla con las necesidades

3.1.2. 1.2.2 Aseguramiento de la Calidad y proceso de pruebas

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

3.1.2.1.1. orientado al proceso

3.1.2.1.2. Documentation Buenas practidas de desarrollo Entrenamiento de personal Buen control de cambios Buenas politicas de branching

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

3.1.2.2.1. orientado al producto

3.1.2.2.2. Pruebas dinamicas , pruebas automaticas, deteccion de bugs, pruebas de regression.

3.1.2.3. La gestión de la calidad incluye todas las actividades que dirigen y controla una organizacion con respecto a la calidad. (QA+ QC)

3.1.3. 1.2.3 Errores, Defectos y Fallos

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

3.1.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)

3.1.3.2. Si se ejecuta un fragmento de código que contiene un defecto, esto puede causar un fallo

3.1.3.2.1. Cuando ese codigo se ejecute, el defecto hace que la calculadora no funcione como se espera. (Causa)

3.1.3.3. El defecto puede convertirse en un fallo si el software no maneja esa excepcion y deja de funcionar o se cae

3.1.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)

3.2. 1.3 Siete Principios de la Prueba

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

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

3.2.2. 2. La prueba exhaustiva es imposible

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

3.2.3. 3. La prueba temprana ahorra tiempo y dinero

3.2.4. 4. Los defectos se agrupan

3.2.5. 5. Cuidado con la paradoja del pesticida

3.2.6. 6. La prueba depende del contexto

3.2.7. 7. La ausencia de errores es una falacia

3.3. 1.4 Proceso de Prueba

3.3.1. 1.4.1 El Proceso de Prueba en Contexto

3.3.1.1. Factores que influyen

3.3.1.1.1. Modelo de ciclo de vida de desarrollo de software en la organizacion

3.3.1.1.2. Niveles y tipos de prueba considerados.

3.3.1.1.3. Riesgos de producto y de proyecto

3.3.1.1.4. Dominio del negocio

3.3.1.1.5. Restricciones operativas

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

3.3.1.1.7. Plazos

3.3.2. 1.4.2 Actividades y Tareas de pruebas

3.3.2.1. Planificacion de la prueba

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

3.3.2.2. Monitorizacion de la prueba

3.3.2.2.1. Avance con respecto al plan de pruebas

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

3.3.2.3. Analisis de la prueba

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

3.3.2.4. Diseño de la prueba

3.3.2.4.1. Diseño de casos y test suites

3.3.2.4.2. Identificar datos de prueba

3.3.2.4.3. Diseñar entorno de pruebas

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

3.3.2.5.1. Esta todo listo para probar?

3.3.2.5.2. Comparacion de resultados reales vs esperados

3.3.2.5.3. Analizar anomalias y reportar bugs

3.3.2.5.4. Registrar resultado de las pruebas

3.3.2.6. Finalización de las pruebas

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

3.3.2.6.2. Verificar todos los bugs estan cerrados

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

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

3.3.3. 1.4.3 Productos de Trabajo de Prueba (artefactos)

3.3.3.1. Acabados que se crean durante el proceso de pruebas. ISO/IEC/IEE29119-3

3.3.3.1.1. Planeación: Uno o mas planes de prueba

3.3.3.1.2. Monitoreo : Reportes de pueba y estatus

3.3.3.1.3. Analisis: Definicion y priorización de casos de prueba

3.3.3.1.4. Diseño: Casos de prueba

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

3.3.3.1.6. Finalización: Reporte de cierre, resumen de las pruebas

3.4. 1.5 La Psicología del Proceso de Prueba

3.4.1. 1.5.1 Psicología Humana y el Proceso de pruebas

3.4.1.1. Algunas personas pueden percibir al proceso de prueba como una actividad destruictiva

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

3.4.1.2.1. colaboracion en lugar de batallas

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

3.4.1.3.1. Empatia, comunicación efectiva

3.4.2. 1.5.2 Formas de Pensar del Probador y del desarrollador

3.4.2.1. El Desarrollador se enfoca a menudo en la construccion de soluciones y no en que podria salir mal

3.4.2.1.1. El sesgo hace dificil encontrar errores en su proprio codigo.

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

3.5. 1.1 ¿Qué son las Pruebas?

3.5.1. 1.1.0 Que es probar?

3.5.1.1. Probar el software es una forma de evaluar la calidad y de reducir el riesgo de fallo en produccion

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

3.5.1.2. La prueba de software es un proceso que incluye muchas actividades diferentes;la ejecucion de la prueba es solo una de estas

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

3.5.1.4. Formas de probar

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

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

3.5.2. 1.1.1 Objetivos Característicos de la prueba

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

3.5.2.2. Verificar el cumplimiento de todos los requisitos especificados

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

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

3.5.2.5. Prevenir defectos***

3.5.2.6. Encontrar fallos y defectos.

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

3.5.2.8. Reducir el nivel de riesgo de calidad del software

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

3.5.3. 1.1.2 Prueba y Depuración

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

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

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

4.1. 2.1 Modelos de Ciclo de Vida del desarrollo de software

4.1.1. 2.1.1 Desarrollo de Software y Prueba de software

4.1.1.1. Características de las pruebas en cualquier modelo

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

4.1.1.1.2. Cada nivel de pruebas tiene un objetivo de prueba especifico parfa ese nivel

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

4.1.1.1.4. Modelos de ciclo de vida de desarrollo

4.1.2. 2.1.2 Modelos de Ciclo de Vida del desarrollo de software en contexto

4.1.2.1. Se adaptan en función del objetivo del proyecto, el tipo de producto que se esta desarrollando, las prioridades del negocio y riesgos

4.1.2.2. Puede ser necesario combinar o reorganizar los niveles de prueba. Integration entre sistema

4.1.2.3. Se pueden combinar los propios modelos de ciclo de vida de de desarrollo. Modelo V para Back end, Agil para Front End

4.2. 2.2 Niveles de Prueba

4.2.1. 2.2.1 Prueba de Componente (unitarias)

4.2.1.1. Objetivo especifico

4.2.1.1.1. Verificar los comportamientos funcionales y no funcionales del componente

4.2.1.1.2. Prevenir la propagacion de defectos a niveles de prueba superior

4.2.1.2. Base de prueba

4.2.1.2.1. Diseño detallado

4.2.1.2.2. Codigo

4.2.1.2.3. Modelo de datos

4.2.1.3. Objetos de prueba

4.2.1.3.1. Componentes, unidades o mudulos

4.2.1.3.2. Clases

4.2.1.3.3. Modelos de bases de datos

4.2.1.4. Defectos tipicos

4.2.1.4.1. Problemas de flujo de datos

4.2.1.4.2. Codigo y logica incorrecto

4.2.1.4.3. Funcionamiento incorrecto

4.2.1.5. Enfoques y responsabilidades

4.2.1.5.1. Desarrollador que escribe el codigo realiza pruebas de componente

4.2.1.5.2. Enfoque TDD "Test Driven development"

4.2.2. 2.2.2 Prueba de Integración

4.2.2.1. Objetivo de las pruebas

4.2.2.1.1. Verificar los compoertamientos funcionales y no funcionales de las interfaces sean los disenados

4.2.2.1.2. Pruebas de integracion de componentes del sistema

4.2.2.1.3. Pruebas de integracion entre paquetes o microservicios

4.2.2.2. Base de prueba

4.2.2.2.1. Arquitectura a nivel de componente o sistema

4.2.2.2.2. Flujos de trabajo.

4.2.2.2.3. Diagramas de secuencia

4.2.2.3. Objetos de prueba

4.2.2.3.1. Microservicios.

4.2.2.3.2. APIS

4.2.2.3.3. Bases de datos

4.2.2.4. Defectos tipicos

4.2.2.4.1. Fallos en la comunicación entre componentes

4.2.2.4.2. Fallos en la comunicación entre sistemas

4.2.2.4.3. Error de datosque se transmiten entre componentes

4.2.2.5. Enfoques y responsabilidades

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

4.2.2.5.2. Responsabilidad de los probadores

4.2.2.5.3. Generalmente se hace en integracion continua

4.2.3. 2.2.3 Prueba de Sistema

4.2.3.1. Objetivos de la Prueba de Sistema

4.2.3.1.1. Validar que el sistema está completo y que fucinoa como se espera

4.2.3.1.2. Generar confianza en la calidad del sistema considerando como un todo

4.2.3.1.3. Encontrar defectos

4.2.3.2. Bases de Prueba

4.2.3.2.1. Casos de uso

4.2.3.2.2. Épicas e historias de usuario

4.2.3.2.3. Modelos de comportamiento del sistema

4.2.3.2.4. Manuales del sistema y del usuario

4.2.3.3. Objetos de Prueba

4.2.3.3.1. Aplicaciones

4.2.3.3.2. Sistemas hardware/software

4.2.3.3.3. Sistemas operativos

4.2.3.3.4. Configuración del sistema y datos de configuracion

4.2.3.4. Defectos tipicos

4.2.3.4.1. Cálculos incorrectos

4.2.3.4.2. Comportamiento funcional o no funcional incorrecto

4.2.3.4.3. Fallo del sistema

4.2.3.5. Enfoque y responsabilidades

4.2.3.5.1. Debe centrarse en el comportamiento global y de extremo a extremo del sistema en su conjunto

4.2.3.5.2. Responsabilidad del tester

4.2.4. 2.2.4 Prueba de Aceptación

4.2.4.1. Objetivos de la Prueba de Aceptación

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

4.2.4.1.2. Validar que el sistema está completo y que funcionara como se espera

4.2.4.2. Base de prueba

4.2.4.2.1. Procesos de negocio

4.2.4.2.2. Requisitos de usuario o de negocio

4.2.4.2.3. Requisitos de sistema

4.2.4.2.4. Documentación del sistema o del usuario

4.2.4.3. Objetos de Prueba Característicos

4.2.4.3.1. Sistema sujeto a prueba

4.2.4.3.2. Procesos de negocio para un sistema completamente integrado

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

4.2.4.3.4. Procesos operativos y de mantenimiento

4.2.4.4. Defectos y Fallos Característicos

4.2.4.4.1. Las reglas de negocio no se implementan

4.2.4.4.2. El sistema no satisface los requisitos

4.2.4.4.3. Los flujos de trabajo del sistema no cumplen con los requisitos de negocio

4.2.4.5. Enfoques y Responsabilidades Específicos

4.2.4.5.1. Responsabilidad de los clientes, usuarios de negocio, propietarios de producto

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

4.3. 2.3 Tipos de Prueba

4.3.1. 2.3.1 Prueba Funcional (Caja negra)

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

4.3.1.2. Se deben realizar en todos los niveles de prueba

4.3.1.3. Utiliza técnicas de caja negra

4.3.2. 2.3.2 Prueba No Funcional (caja negra)

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

4.3.2.2. Se deben realizar tan pronto como sea posible

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

4.3.3. 2.3.3 Prueba de Caja Blanca

4.3.3.1. Pruebas basadas en la estructura interna del sistema

4.3.3.1.1. Codigo

4.3.3.1.2. Arquitectura

4.3.3.1.3. Flujo de datos

4.3.3.2. Implicar competencias o conocimientos como la forma en que se construye el codigo o como se almacenan los datos

4.3.4. 2.3.4 Prueba Asociada al Cambio

4.3.4.1. Prueba de confirmación

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

4.3.4.2. Prueba de regresión

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

4.3.4.2.2. Fuerte candidato para la automatización

4.3.4.3. Consideraciones

4.3.4.3.1. Se realizan en todos los niveles de prueba

4.3.4.3.2. Importante en Desarrollo Ágil y Sistemas IoT

4.3.5. 2.3.5 Tipos de Prueba y Niveles de Prueba

4.3.5.1. Es posible realizar cualquiera de los tipos de prueba en cualquier nivel de prueba

4.4. 2.4 Prueba de Mantenimiento

4.4.1. 2.4.1 Activadores para el Mantenimiento

4.4.1.1. Modificación

4.4.1.1.1. Mejoras planificadas

4.4.1.1.2. Cambios correctivos

4.4.1.1.3. Cambios de emergencia

4.4.1.1.4. Cambios en el S.O.

4.4.1.2. Migracion

4.4.1.2.1. De una plataforma a otra

4.4.1.2.2. De datos

4.4.1.3. Retirada

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

4.4.1.3.2. Procedimientos de restauración/recuperación

4.4.2. 2.4.2 Análisis de Impacto para el mantenimiento

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

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

5. 3. Prueba Estática

5.1. 3.1 Conceptos Básicos

5.1.1. 3.1.0 Introducción

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

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

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

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

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

5.1.2.3. Especificaciones de arquitectura y diseño

5.1.2.4. Código.

5.1.2.5. Contratos, planes de proyecto, calendarios y presupuestos

5.1.3. 3.1.2 Ventajas de la Prueba Estática

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

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

5.1.3.3. Incrementar la productividad de desarrollo

5.1.3.4. Reducir el coste y el tiempo de desarrollo

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

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

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

5.1.4.3. Defectos tipicos

5.1.4.3.1. Defectos en los requisitos

5.1.4.3.2. Defectos de diseño

5.1.4.3.3. Defectos de codificación

5.1.4.3.4. Desviaciones con respecto a estándares

5.1.4.3.5. Vulnerabilidades de seguridad

5.2. 3.2 Proceso de Revisión

5.2.1. 3.2.1 Proceso de Revisión de Productos de trabajo

5.2.1.1. Planificación

5.2.1.2. Iniciar Revisión

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

5.2.1.4. Comunicación y Análisis de Cuestiones

5.2.1.5. Corregir e Informar

5.2.2. 3.2.2 Roles y Responsabilidades en una revison formal

5.2.2.1. Autor

5.2.2.2. Dirección

5.2.2.3. Facilitador (a menudo llamado moderador)

5.2.2.4. Líder de Revisión

5.2.2.5. Revisores

5.2.3. 3.2.3 Tipos de Revisión

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

5.2.3.1.1. Utilizado con mucha frecuencia en el desarrollo agil

5.2.3.2. Revisión Guiada

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

5.2.3.3. Revisión Técnica

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

5.2.3.4. Inspección

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

5.2.4.1. Ad hoc

5.2.4.1.1. Los revisores reciben poca o ninguna orientación sobre como se debe realizar esta tarea

5.2.4.2. Basada en Lista de Comprobación

5.2.4.3. Escenarios y Ensayos

5.2.4.3.1. Los revisores reciben pautas estructuradas

5.2.4.4. Basada en Roles

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

5.2.4.5. Basada en Perspectiva

5.2.4.5.1. Los revisores adoptan los diferentes puntos de vista

5.2.5. 3.2.5 Factores de Éxito para las Revisiones

5.2.5.1. Cada revisión tiene objetivos claros, definidos durante la planificacion de la revision y utilizados como critero de salida

5.2.5.2. Se involucra a las personas adecuadas para alcanzar los objetivos de la revision

5.2.5.3. Los probadores son vistos como revisores valiosos que contribuyen a la revision

5.2.5.4. Los participantes dedican tiempo y atencion adecuados a los detalles

6. 4. Técnicas de Prueba

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

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

6.1.1.1. Factores

6.1.1.1.1. Tipo de componente o sistema

6.1.1.1.2. Complejidad del componente

6.1.1.1.3. Estándares de regulación

6.1.1.1.4. Niveles de riesgo

6.1.1.1.5. Documentación disponible

6.1.1.1.6. Herramientas disponibles

6.1.1.1.7. Modelo de ciclo de vida de desarrollo de software

6.1.2. 4.1.2 Categorías de Técnicas de Prueba y sus caracteristicas

6.1.2.1. Técnicas de prueba de la caja negra

6.1.2.1.1. Base de prueba

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

6.1.2.2. Técnicas de prueba de caja blanca

6.1.2.2.1. Base de prueba

6.1.2.2.2. La cobertura se mide en base a los elementos probados dentro de una estructura selecionada

6.1.2.3. Técnicas de prueba basadas en la experiencia

6.1.2.3.1. Base de prueba

6.2. 4.2 Técnicas diseño de casos de Prueba de Caja Negra

6.2.1. 4.2.1 Partición de Equivalencia

6.2.1.1. Divide los datos en particiones

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

6.2.1.3. La cobertura se mide como el número de particiones de equivalencia probadas por al menos un valor / numero total de particiones de equivalencias

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

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

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

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

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

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

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

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

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

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

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

6.2.3.5. La tabla se puede colapsar

6.2.3.6. Cobertura : % 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.

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

6.2.4.1. Elementos

6.2.4.1.1. Estado:

6.2.4.1.2. Transicion

6.2.4.1.3. Evento

6.2.4.1.4. Accion

6.2.4.2. Un diagrama de transición de estado muestra

6.2.4.2.1. Los posibles estados del software,

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

6.2.4.3. Una tabla de transición de estado muestra

6.2.4.3.1. Todas las transiciones válidas

6.2.4.3.2. las transiciones potencialmente inválidas entre estados

6.2.4.3.3. Los eventos

6.2.4.3.4. Condiciones de guarda

6.2.4.3.5. Las acciones resultantes para las transiciones válidas

6.2.4.4. Diseño de Pruebas

6.2.4.4.1. Para cubrir una secuencia de estados típica

6.2.4.4.2. Para practicar todos los estados

6.2.4.4.3. Para practicar cada transición

6.2.4.4.4. Para practicar secuencias específicas de transiciones

6.2.4.4.5. Para probar transiciones inválidas

6.2.4.5. Utilización

6.2.4.5.1. Aplicaciones basadas en menús

6.2.4.5.2. Industria del software embebido

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

6.2.4.5.4. Probar la navegación en pantalla

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

6.2.5. 4.2.5 Prueba de Caso de Uso

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

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

6.2.5.2.1. Básicas

6.2.5.2.2. Excepcionales o alternativas

6.2.5.2.3. Tratamiento de errores

6.2.5.3. Cobertura

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

6.3. 4.3 Técnicas de Prueba de Caja Blanca

6.3.1. 4.3.0 Caracteristicas

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

6.3.1.2. Se pueden utilizar en todos los niveles de prueba

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

6.3.2. 4.3.1 Prueba y Cobertura de Sentencia

6.3.2.1. Practica las sentencias ejecutables en el código

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

6.3.2.3. Ejemplo

6.3.3. 4.3.2 Prueba y Cobertura de Decisión

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

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

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

6.3.3.4. Ejemplo

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

6.4.1. 4.4.1 Predicción de Errores

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

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

6.4.2. 4.4.2 Prueba Exploratoria

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

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

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

6.4.3. 4.4.3 Prueba Basada en Listas de Comprobación

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

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

6.4.3.3. Dan soporte pruebas funcionales y no funcionales

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