Fundamentos del Proceso de Prueba – ISTQB (1/6)

Durante la Guerra del Golfo, veintiocho soldados estadounidenses murieron y casi cien más resultaron heridos cuando un sistema de defensa antimisiles Patriot cercano no pudo rastrear correctamente un misil Scud lanzado desde Irak. Más tarde se descubrió que la causa de la falla era un error de programación en la computadora incorporada en el sistema de control de armas del Patriot. Un error de precisión aritmética que se iba acumulando después de un uso prolongado del software.

Cuatro meses después, Bruce Garnett, coronel del Ejército de los EE. UU, director del Programa Patriot indicó: “El incidente fue una anomalía que nunca apareció en miles de horas de pruebas e involucró una combinación imprevista de docenas de variables, incluida la velocidad, la altitud y la trayectoria del Scud”. Sin embargo, informes oficiales indicaron que los soldados israelís ya habían informado semanas antes que el software tenía una notable pérdida de precisión después de 8 horas consecutivas de uso. Por lo tanto, aparentemente, todas estas «miles de horas» de pruebas implicaron reinicios frecuentes. A su vez, en el informe oficial, se indicó que el software Patriot fue modificado apresuradamente en los meses previos a (e incluso durante) la Guerra del Golfo para rastrear misiles Scud que iban 2.5 veces más rápido que los misiles de cruceros y aviones, para los cuales originalmente fue diseñado.

Probablemente, el lector de este artículo no tenga que probar software de tal nivel de criticidad, pero hay algo que es seguro independientemente de la complejidad del proyecto o sistema informático, el proceso de pruebas es un factor de gran relevancia en cualquier ciclo de desarrollo.

En la actualidad existe un cuerpo de conocimiento bastante amplio sobre los distintos aspectos que involucran las pruebas. En esta serie de artículos dejaré mis apuntes basados en el Programa de Estudio de Nivel Básico del International Software Testing Qualifications Board (ISTQB). Este programa está dirigido a todos aquellos que tengan el objetivo de certificarse, desempeñen algún rol asociado a las pruebas en su organización o estén interesados en ingresar a esta rama de especialización. En algunos apartados, añado algunos ejemplos prácticos o referencias que considero pueden ser de interés al lector.

1. ¿Qué es probar?

Para responder esta pregunta, podemos partir de lo contrario, ¿qué no es probar? Una percepción común, pero equivocada, de la prueba es que solo consiste en ejecutar pruebas, es decir, ejecutar el software y comprobar los resultados. Otro enfoque sesgado corresponde a pensar que las pruebas se centran solo en la verificación de requisitos, historias de usuarios u otras especificaciones.

El proceso de prueba es más integrador, involucra actividades de planificación, análisis, diseño, ejecución, informes de avance y resultados y evaluación. De esta forma, se organizan y realizan las pruebas de acuerdo a las necesidades del proyecto y el ciclo de vida.

1.1. Objetivos de las Pruebas

• Evaluar productos de trabajo como requisitos, historías de usuario, diseños, código fuente.
• Verificar el cumplimiento de los requisitos especificados.
• Validar si el objeto de prueba está completo y satisface las expectativas de usuarios e interesados.
• Generar confianza en el nivel de calidad del objeto de prueba.
• Prevenir defectos.
• Encontrar fallos y defectos (en las pruebas de desarrollo y aceptación).
• Proporcionar información suficiente para la toma de decisiones en relación con el nivel de calidad del objeto de prueba.
• Reducir el nivel de riesgo de calidad inadecuada del software.
• Cumplir con requisitos o normas contractuales, legales o reglamentarias (o revisar su cumplimiento).

Los objetivos pueden variar dependiendo del contexto del objeto de prueba, el nivel de prueba y el modelo del ciclo de vida de desarrollo de software. Por ejemplo en una prueba de componente se busca identificar la mayor cantidad de defectos para que puedan ser solucionados de forma temprana, mientras que en una prueba de aceptación se persigue confirmar que el sistema funciona o del riesgo que involucraría su liberación en un momento dado.

1.2. Pruebas vs Depuración

2. ¿Por qué es necesario probar?

• Ayuda a reducir el riesgo (no eliminar) de que se produzcan fallos durante la operación del software.
• Permite cumplir con requisitos contractuales o estándares de la industria.

2.1. Contribuciones de la Prueba al Éxito

Un escenario común en el área de TI es que el área de Desarrollo entregue software con ciertos defectos al área de Operaciones. El uso adecuado de las técnicas y niveles de prueba en el ciclo de desarrollo de pruebas permite reducir la frecuencia de entregas problemáticas.

• En la etapa de identificación de requisitos o historias de usuario: reducción del riesgo de desarrollar funcionalidades incorrectas.
• Durante la etapa de diseño: aumento de la compresión del software, reducción del riesgo de defectos en el diseño e identificación pruebas en una fase temprana.
• Durante la construcción: colaboración estrecha con el desarrollador aumenta la comprensión del código (reduce el riesgo de defectos en el código y la prueba) y cómo probarlo.
• Antes de la liberación: detección de fallos y apoyo en la depuración de defectos aumenta la posibilidad de satisfacer los requisitos.

2.2. Aseguramiento de la Calidad y Proceso de Prueba

Tres términos de vital importancia: gestión de la calidad, aseguramiento de la calidad y el control de calidad.

2.3. Errores, Defectos y Fallos

2.4. Defectos, Causa Raíz y Efectos

3. Siete Principios de Prueba

3.1. Principio 1: La prueba muestra la presencia de defectos, no su ausencia

• La prueba reduce la probabilidad de existencia de defectos, no la elimina. Aunque no se encuentren defectos, el proceso de prueba no garantiza la corrección absoluta del software.
• El procedimiento o las condiciones de prueba pueden influir en la no detección de errores.

3.2. Principio 2: La prueba exhaustiva es imposible

• No es posible probar todo excepto en casos triviales. El análisis de riesgos, elección adecuada de las técnicas de pruebas y las prioridades para centrar los esfuerzos de prueba.

3.3. Principio 3: La prueba temprana ahorra tiempo y dinero

• Shift Left Testing, «desplazamiento hacia la izquierda», trasladar las prácticas de prueba críticas a una etapa más temprana del ciclo de vida del desarrollo.
• Los conceptos y especificaciones también pueden ser probados. La etapa inicial de preparación de pruebas requiere de un esfuerzo considerable. Es posible ejecutar actividades de prueba de forma paralela a la especificación y el diseño de software.

3.4. Principio 4: Los defectos se agrupan

• Normalmente, al encontrar un defecto, la posibilidad de encontrar más en el mismo módulo crece. Es importante tomar previsiones acerca de estas agrupaciones en un análisis de riesgos para centrar los esfuerzos de prueba.

3.5. Principio 5: Cuidado con la paradoja del pesticida

• La repetición de una misma prueba eventualmente ya no encontrará ningún defecto. Al igual que los insectos desarrollan resistencia a ciertos pesticidas después de un tiempo, las pruebas ya no son efectivas para detectar defectos.

3.6. Principio 6: La prueba depende del contexto

• La prueba se realiza de manera diferente en diferentes contextos, dependiendo del tipo de software (misión crítica, comercial, etc.) o del ciclo de vida del proyecto (ágil, secuencial, etc.).

3.7. Principio 7: La ausencia de errores es una falacia

• Una creencia equivocada es esperar que solo encontrar y corregir un gran número de defectos se asegure éxito de un sistema. Es posible que, a pesar de que se ejecuten pruebas exitosas, el sistema no satisfaga las necesidades de los usuarios.

4. Proceso de Prueba

Conjunto de actividades de prueba comunes con las cuales es más probable que la prueba alcance los objetivos establecidos.

Las siguientes definiciones asociadas al proceso de prueba son importantes para entender la sección:

• Objeto de prueba.- El componente o sistema que se va a probar (el sujeto que se va a examinar por ejemplo, un documento o la porción de software en el proceso de desarrollo de software).
• Condición de prueba.- Un aspecto de la base de la prueba que es relevante para lograr los objetivos específicos de la prueba.
• Ejecución de la prueba.- Llevar a cabo la prueba en el componente o sistema sujeto a prueba, produciendo resultados reales.
• Calendario de Ejecución de Prueba.- Esquema para la ejecución de procedimientos de prueba. Los procedimientos de prueba se incluyen en el calendario de ejecución de prueba en su contexto y en el orden en el que deben ejecutarse.
• Caso de prueba.- Conjunto de condiciones previas, entradas (incluidas las acciones, cuando corresponda) y resultados esperados, desarrollados para determinar si la parte cubierta del elemento de prueba se ha implementado correctamente o no.
• Base de Prueba.- Conjunto de conocimientos utilizados como base para el análisis y el diseño de las pruebas (a menudo un conjunto de documentos que incluyen los requisitos de un componente o sistema).
• Juego de pruebas.- Conjunto de casos de prueba para un componente o sistema en pruebas, donde la post-condición de una prueba es a menudo usada como precondición de la siguiente.
• Oráculo de prueba. Fuente para determinar resultados esperados para compararlos con los resultados reales del software en pruebas. Un oráculo puede ser un sistema existente (para una evaluación comparativa), un manual de usuario o el conocimiento especializado de un individuo, pero no debería ser el código.
• Estrategia de Prueba.- Documentación que expresa los requisitos genéricos para probar uno o más proyectos ejecutados dentro de una organización, proporcionando detalles sobre cómo se deben llevar a cabo las pruebas. Está alineada a la política de pruebas.
• Política de Pruebas.- Descripción de alto nivel de las pruebas para una organización o programa.
• Condición de salida.- Conjunto de condiciones para completar formalmente una tarea definida.

4.1. Proceso de Prueba en Contexto

Los factores que influyen en el proceso de prueba de una organización incluyen, pero no están limitados a:

• Modelo de ciclo de vida de desarrollo de software y metodologías de proyecto en uso.
• Niveles y tipos de prueba considerados.
• Riesgos de producto y de proyecto.
• Dominio del negocio.
• Restricciones operativas, incluyendo pero no limitadas a:
  • Presupuestos y recursos.
  • Plazos.
  • Complejidad.
  • Requisitos contractuales y normativos.
• Políticas y prácticas de la organización.
• Estándares internos y externos necesarios.

4.2. Actividades y Tareas de Prueba

Un proceso de prueba consiste en los siguientes grupos de actividades:

• Planificación de la prueba.- Definición de los objetivos y el enfoque de cumplimiento de este dentro de las restricciones del contexto.
• Monitorización y Control de la Prueba.- Comparació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.
• Análisis de la prueba.- Análisis de la base de prueba para identificar qué debe ser probado en términos de criterios de cobertura medibles.
• Diseño de la prueba.- Las condiciones de prueba se transforman en casos de prueba de alto nivel y conjuntos de casos de prueba.
• Implementación de la prueba.- Creación y compleción de 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.
• Ejecución de la prueba.- Ejecución de los conjuntos de prueba de acuerdo al calendario definido.
• Compleción de la prueba.- Recopilación de datos de las actividades de prueba completadas para consolidar la experiencia, productos de prueba. Normalmente, ocurre en hitos del proyecto (liberación, fin de una iteración, etc.).

Cada grupo de actividades está compuesta por múltiples tareas individuales, que pueden variar de un proyecto o de un lanzamiento a otro. Al final de esta sección se describen en una tabla con detalles de las actividades, tareas y productos de trabajo de la prueba.

4.3. Productos de Trabajo de la Prueba

Se crean como parte del proceso de prueba. Los tipos de trabajo de prueba varían en su forma de organización y gestión de acuerdo a como la organización implementa el proceso de prueba.

• Productos de Trabajo de la Planificación de la Prueba
  • Plan (es) de prueba
• Productos de Trabajo de la Monitorización y Control de la Prueba
  • Informes de prueba (avances y resumen de la prueba)
• Productos de Trabajo del Análisis de la Prueba
  • Condiciones de prueba definidas y priorizadas, en forma de contratos de prueba
  • Trazabilidad bidireccional entre bases de prueba y condiciones de prueba
  • Informes de defectos en las bases de prueba
• Productos de Trabajo del Diseño de la Prueba
  • Casos de prueba
  • Casos de prueba de alto nivel (lógico) reutilizables
  • Definición de la infraestructura y los datos de prueba necesarios (entornos, herramientas, etc.)
  • Extensión de la documentación, así como el tiempo necesario para desarrollar la infraestructura.
• Productos de Trabajo de la Implementación de la Prueba
  • Procedimientos de prueba y su secuencia
  • Juegos de prueba.
  • Calendario de ejecución de la prueba
  • Datos de prueba y entornos de prueba realizados, guiones de prueba automatizada.
  • Identificación de resultados esperados mediante un oráculo de pruebas.
• Productos de Trabajo de la Ejecución de la Prueba
  • Documentación sobre el estado de los casos de prueba individuales o procedimientos de prueba
  • Informes de defecto.
  • Documentación sobre los elementos involucrados en la prueba (objetos, herramientas y productos de prueba)
  • Estado de cada elemento de la base de prueba mediante la trazabilidad direccional.
• Productos de Trabajo de la Compleción de la Prueba
  • Informes resumen de prueba
  • Sugerencias de mejora o elementos de acción para la mejora de proyectos.
  • Solicitudes de cambio o elementos de la cartera del producto.
  • Productos de prueba finalizados.

4.4. Trazabilidad entre Base de Prueba y Productos del Trabajo de Prueba

Independientemente de las variaciones de los productos de trabajo de pruebas en una organización, para implementar un monitoreo y control efectivo de las pruebas es importante establecer y mantener la trazabilidad a lo largo del proceso de prueba entre cada elemento de la base de prueba y los diversos productos de trabajo de la prueba asocadiados al elemtno. De esta forma se consigue:

• Evaluar de la cobertura de las pruebas.
• Analizar del impacto de cambios.
• Posibilitar auditoría de la prueba.
• Cumplir criterios de gobernanza de TI.
• Mejorar la compresión de informes de prueba (de avance, resumen)
• Relacionar aspectos técnicos de la prueba con los implicados para mejor entendimiento.
• Aportar información para evaliuar calidad de los productos, capacidad de los procesos y avance de los proyectos con la relación a los objetivos del negocio.

El uso de herramientas de gestión facilita la adopción de modelos de productos de trabajo como el presentado.

Actividades, tareas y productos de prueba

5. Psicología del Proceso de Prueba

La psicología humana tiene efectos importantes en la prueba de software.

5.1. Psicología Humana y el Proceso de Prueba

• La identificación de defectos puede ser percibida como una crítica al producto y a su autor, derivada de un sesgo de confirmación del desarrollador.
• Sesgo de confirmación: favorecer, buscar, interpretar y recordar la información que confirma las propias creencias o hipótesis, dando desproporcionadamente menos consideración a posibles alternativas.
• La información sobre defectos y fallos como resultado de ejecución debe ser comunicada de manera constructiva a modo reducir tensiones entre los diferentes roles del proyecto.
• Los responsables de prueba en todo nivel deben tener buenas competencias interpersonales de comunicación. Algunos ejemplos:
  • Recordar que el objetivo común es lograr sistemas de mejor calidad.
  • Enfatizar los beneficios de la prueba (ahorro de tiempo, reducción de riesgos, mejora del producto).
  • Comunicar los resultados de prueba de forma neutral, objetiva, fundamentada en hechos.
  • Ser empático con la otra persona, anticipar posibles reacciones negativas y sus razones.
  • Confirmar el entendimiento mutuo.
• El planteamiento de objetivos claro tiene un gran impacto psicológico, pues permite que todo el equipo se alineará a dichos objetivos.

5.2. Formas de Pensar del Probador y del Desarrollador

Una forma de pensar o mentalidad refleja las suposiciones de un individuo y los métodos preferidos para la toma de decisiones y la resolución de problemas.