Este checklist contempla los elementos esenciales que pueden afectar la probabilidad de los riesgos y se enfoca en el análisis técnico:
1. Complejidad del Código
- ¿El código es modular y fácil de entender? Evaluar si el código está dividido en módulos manejables y si sigue buenas prácticas de programación.
- ¿La complejidad ciclomática es alta en módulos críticos? Medir la complejidad ciclomática para determinar la cantidad de caminos posibles y evaluar si es manejable o compleja.
- ¿Se encuentran dependencias ocultas entre módulos? Comprobar si existen interdependencias no documentadas que podrían afectar la capacidad de prueba y de mantenimiento.
- ¿El código presenta múltiples condiciones o bucles anidados? Revisar si existen estructuras de control complejas que incrementen el riesgo de defectos lógicos.
2. Historial de Defectos
- ¿Se ha registrado una alta frecuencia de defectos en módulos específicos? Analizar los reportes de defectos previos para identificar módulos problemáticos.
- ¿Los defectos registrados son críticos o de alta severidad? Clasificar los defectos históricos según su severidad para identificar áreas de alto riesgo.
- ¿Hay patrones de defectos recurrentes? Determinar si ciertos tipos de defectos tienden a repetirse en el mismo módulo o funcionalidad, lo que indicaría un problema subyacente.
- ¿Los defectos se encontraron en etapas avanzadas? Evaluar si los defectos tienden a descubrirse en pruebas de integración o aceptación, indicando problemas de diseño o especificación.
3. Integración y Dependencias
- ¿El sistema depende de componentes externos o servicios de terceros? Evaluar la estabilidad y disponibilidad de servicios externos y su impacto en el sistema.
- ¿Existen riesgos asociados a la integración de componentes (APIs, servicios web)? Revisar si la comunicación entre componentes presenta problemas de sincronización, latencia o dependencia.
- ¿El sistema utiliza versiones diferentes de bibliotecas o frameworks? Asegurarse de que todas las dependencias son compatibles y de que no presentan problemas de integración.
- ¿Se ha identificado una adecuada cobertura de pruebas de integración? Verificar que las pruebas cubran adecuadamente los puntos de integración entre módulos críticos.
4. Tasas de Cambio y Volatilidad de los Requerimientos
- ¿La funcionalidad del sistema cambia con frecuencia? Evaluar si el sistema está sujeto a cambios continuos que aumenten la probabilidad de introducir errores.
- ¿Existen requerimientos inestables o ambiguos? Identificar cualquier requerimiento que haya sido poco claro o sujeto a interpretaciones que puedan aumentar el riesgo de defectos.
- ¿Se documentan y versionan adecuadamente los cambios? Verificar que los cambios se manejen mediante un control de versiones para evitar inconsistencias.
- ¿El equipo tiene una comunicación fluida sobre cambios en el sistema? Confirmar que todos los cambios se comunican eficazmente entre los equipos de desarrollo y pruebas.
5. Pruebas Previas y Cobertura
- ¿Los módulos de alto riesgo tienen una baja cobertura de pruebas? Identificar si los módulos críticos o complejos han sido probados adecuadamente.
- ¿Se realizan pruebas automatizadas para componentes de alto riesgo? Verificar si se utilizan pruebas automatizadas en módulos donde los cambios son frecuentes.
- ¿Existen pruebas de regresión para cambios en funcionalidades críticas? Evaluar si las pruebas de regresión cubren las áreas más vulnerables a fallos por cambios recientes.
- ¿Los defectos encontrados en etapas avanzadas se han corregido completamente? Asegurar que los defectos descubiertos en las pruebas anteriores han sido resueltos y reprobados correctamente.
6. Habilidades y Experiencia del Equipo Técnico
- ¿El equipo tiene experiencia en las áreas críticas del sistema? Asegurarse de que el equipo técnico tiene experiencia suficiente en los módulos de alto riesgo.
- ¿Se cuenta con habilidades especializadas para el manejo de tecnología específica (seguridad, rendimiento, etc.)? Confirmar que el equipo posee las habilidades necesarias para abordar riesgos técnicos específicos.
- ¿El equipo ha recibido capacitación en nuevas herramientas o tecnologías utilizadas? Verificar si el equipo está capacitado para utilizar herramientas de soporte en las áreas de prueba más complejas.
- ¿Existe apoyo de expertos externos cuando es necesario? Evaluar la disponibilidad de consultores o expertos que puedan apoyar en áreas de riesgo elevado.
7. Entorno y Herramientas de Prueba
- ¿El entorno de prueba es similar al de producción? Asegurar que el entorno de prueba reproduce fielmente las condiciones de producción.
- ¿Las herramientas de prueba están actualizadas y son adecuadas para el proyecto? Confirmar que las herramientas son compatibles con las versiones actuales del software.
- ¿Existen planes de contingencia si el entorno de prueba falla? Evaluar si se dispone de alternativas para continuar con las pruebas en caso de fallos en el entorno.
- ¿Las pruebas automatizadas se ejecutan en entornos controlados? Verificar que las pruebas automatizadas se ejecutan de forma controlada para evitar errores debidos a variaciones en el entorno.
Este checklist proporciona una estructura para que el TTA pueda evaluar los riesgos técnicos de manera exhaustiva y así priorizar los esfuerzos de prueba según las áreas de mayor probabilidad e impacto.
Espero que te ayude este checklist como para mejorar tu práctica diaria, y gracias por seguir leyendo mis artículos. También puedes seguirme en LinkedIn.
Fuente de inspiración: ISTQB-CTAL-TTA_Syllabus_v4.0
