Please enable JavaScript.
Coggle requires JavaScript to display documents.
*FUNDAMENTOS Y GESTIÓN DE LAS PRUEBAS DE SOFTWARE - Coggle Diagram
*FUNDAMENTOS Y GESTIÓN DE LAS PRUEBAS DE SOFTWARE
1- FUNDAMENTOS DE LAS PRUEBAS
Principios de prueba
Naturaleza de los defectos
Las pruebas de software demuestran la presencia de defectos en el sistema pero no pueden asegurar de manera absoluta su ausencia total.
Paradoja del pesticida
La paradoja del pesticida indica que si las mismas pruebas se repiten continuamente, estas dejan de encontrar nuevos defectos con el tiempo.
Falacia de ausencia de errores
Encontrar y arreglar defectos no sirve de nada si el sistema construido no es usable o no cumple con las necesidades reales del usuario.
Definición y objetivos
Propósito de las pruebas
El objetivo principal de las pruebas es identificar defectos y verificar que el software cumpla con los requisitos establecidos para garantizar un producto confiable.
Psicología de las pruebas
Mentalidad del probador vs. desarrollador
La psicología de las pruebas distingue la mentalidad constructiva del desarrollador de la mentalidad analítica y crítica que requiere el probador para hallar fallos.
2- NIVELES DE PRUEBA (CICLO DE VIDA)
Pruebas unitarias
Foco en componentes
Las pruebas unitarias se centran en verificar de manera aislada el correcto funcionamiento de los componentes individuales del código.
Pruebas de integración
Foco en interfaces
Las pruebas de integración evalúan las interfaces y el flujo de datos entre los distintos módulos del sistema para asegurar su interacción.
Pruebas de sistema
Verificación integral
Las pruebas de sistema consisten en la verificación del comportamiento del producto completo para comprobar que cumple con las especificaciones globales.
Pruebas de aceptación (UAT)
Validación del usuario
Las pruebas de aceptación validan el software frente a las necesidades del usuario final para determinar si el producto está listo para su despliegue.
TÉCNICAS DE PRUEBA
Caja negra (Black-Box)
Basadas en requisitos
La técnica de caja negra se enfoca exclusivamente en las entradas y salidas del sistema basándose en la especificación de requisitos sin mirar el código interno.
Caja blanca (White-Box)
Análisis de estructura
La técnica de caja blanca se basa en el análisis profundo de la estructura interna del código y el flujo lógico de la programación.
Basadas en la experiencia
Pruebas exploratorias
Las pruebas basadas en la experiencia utilizan el conocimiento previo de los probadores para realizar exploraciones y predicción de errores comunes.
MEDIDAS Y MÉTRICAS (CALIDAD CUANTITATIVA)
Densidad de defectos
Concentración de errores
La densidad de defectos cuantifica el número de errores encontrados por cada módulo o por cada mil líneas de código escritas.
Eficacia de las pruebas
Detección preventiva
La eficacia mide la capacidad que tiene el proceso de pruebas para detectar fallos antes de que el software sea entregado a producción.
Cobertura de pruebas
Medición de alcance
La cobertura de pruebas mide el porcentaje de requisitos o líneas de código que han sido efectivamente validados durante el proceso.
4- PROCESOS DE PRUEBA (STLC)
Fase 1: Planificación y control
Definición de estrategia
En la fase de planificación se definen los objetivos de la prueba y las actividades necesarias para lograr las metas del proyecto.
Fase 2: Análisis y diseño
Creación de casos
El análisis y diseño de casos consiste en transformar los objetivos generales en condiciones de prueba y casos de prueba detallados.
Fase 3: Implementación y ejecución
Ejecución de pruebas
Durante la implementación y ejecución se preparan los datos de prueba y se corren los casos para comparar los resultados reales con los esperados.
Fase 4: Evaluación de salida y cierre
Reporte y finalización
La evaluación de criterios de salida permite determinar si se han completado suficientes pruebas para dar por terminada la actividad y generar los reportes finales.