Un buen informe de pruebas debe ser fácil de leer y debe minimizar desperdicios causados por la falta o mala comunicación. Revisa en este post las pautas para facilitar este proceso.

Se asume que redactar un defecto es una tarea sencilla, ¿pero no nos hemos encontrado muchas veces con que los reportes de testing no tienen nada que ver con el caso de prueba? A pesar de tener un formato para reportar defectos, es común que el tester no los pueda transmitir y el desarrollador mucho menos entender, dejando la puerta abierta a interpretaciones causadas por ambigüedad, imprecisión, redundancia o falta de información.

Más allá de la redacción del reporte, entre algunos de nuestros clientes identificamos otro tipo de oportunidades de mejora, desde la fase de inicio de los proyectos de testing, pues al obviar la gestión de defectos como una fase fundamental del proceso de pruebas, se materializaron varios riesgos asociados a la mala comunicación del equipo interno, mala comunicación con sus clientes o usuarios, y pérdidas de dinero u oportunidades de negocio. Un proceso no óptimo de gestión de defectos pierde de vista la posibilidad de una mejora continua asociada al ciclo de vida del desarrollo de software.

El reporte parece una actividad de baja complejidad, donde temporalmente las actividades de testing “finalizan”. Más, es la oportunidad para conocer el comportamiento de los procesos y proyectos, así como el desempeño humano y del producto. Es un proceso fundamental que si inicia de manera temprana, facilita la identificación de las causas raíces de los problemas asociados al software.

La gestión de defectos está orientada a reconocer, investigar, clasificar, registrar, asignar y medir defectos, que eviten situaciones de bloqueo.

Este post tiene como objetivo transmitir pautas para facilitar el proceso de reportes de testing. Así como recalcar la importancia de tener un buen diseño de casos de prueba, estandarización y transparencia, toda vez que el reporte debe ser fácil de leer, debe minimizar desperdicios causados por la falta o mala comunicación, y porque el momento de redactar un defecto no debería ser tan complejo.

¿Por qué gestionar los reportes de testing?

• Porque se obtiene información valiosa sobre el funcionamiento y el comportamiento del producto.
• Se obtiene información valiosa sobre el desempeño del equipo de trabajo, de los procesos y hasta del ciclo de vida del desarrollo del software.
• Porque se puede evitar ese dolor de cabeza que causa la falta de información y la falta de trazabilidad.
• Se pueden tener suficientes datos para predecir lo que sucederá con el software.
• Porque se pueden obtener suficientes datos para predecir lo que sucederá con el ciclo de vida y los procesos del software.
• Cuando se evitan reprocesos, se evita la pérdida de dinero.
• Porque permite aumentar la objetividad, desde una perspectiva más holística para la generación de ideas de cara a la mejora de los procesos de desarrollo y de pruebas.

¿Qué es un informe de prueba

Un reporte contiene información sobre el registro de las discrepancias entre el resultado esperado, y el resultado obtenido en la ejecución de la funcionalidad de un software.

Dichas discrepancias se pueden identificar en diferentes etapas del ciclo de vida del desarrollo y del producto de software. Con el objetivo de minimizar diferentes tipos de riesgos asociados a los proyectos y al producto, lo ideal es evidenciar la mayor cantidad de defectos posible en etapas tempranas del desarrollo del software, incluso desde la fase de planeación.

¿Cómo reportar incidentes informáticos?

Los reportes de testing deben ser comprensibles, ordenados, fiables, transparentes, ágiles, consistentes, precisos, completos y trazables, por lo cual, deben gozar de información pertinente y congruente para ayudar a todos en el equipo a entenderlos fácil y rápidamente.

Cualquier defecto detectado además de ser investigado y reportado, debe ser monitoreado bajo un proceso estricto de seguimiento y control.

Documentación

Para mejorar la documentación del reporte y su lectura, se sugiere contar con los siguientes atributos:

1. Casos de prueba escritos correcta y detalladamente: Facilitará el entendimiento y redacción del defecto.
2. Identificador del reporte: Un identificador único que permita trazar el defecto .
3. Tarea padre: Generalmente el caso de prueba es la tarea padre para asociar el defecto, esta asociación facilita la trazabilidad.
4. Informador o tester: Responsable del reporte, quien encuentra el defecto y redacta el reporte.
5. Estado: Según los estados definidos para el ciclo de vida, por ejemplo: Abierto, cerrado, en revisión, anulado, etcétera. Este ítem se detalla con precisión más adelante.
6. Versión: Especificar en qué versión del paquete, funcionalidad, producto o commit, se encontró el defecto.
7. Severidad: La severidad facilita la priorización para la resolución de la incidencia  y afecta los datos que se obtendrán en el informe. Este ítem se detalla con precisión más adelante.
8. Reproducibilidad: Identificar si es un defecto común, si nunca se ha intentado o si es un defecto frecuente.
9. Resumen: Escribir un título que permita interpretar fácilmente el defecto.
10. Pasos para reproducir el error: Describir todos los pasos que faciliten el camino para que cualquier persona del equipo pueda llegar a reproducir el defecto.
11. Información adicional: Datos de prueba, diagnóstico.
12. Ambiente o ubicación: Documentar la base de datos de pruebas, el nombre o identificador del ambiente.
13. Imágenes y/o videos: Respaldar el reporte con imágenes o videos para ampliar y facilitar su lectura.
14. Descripción del defecto: Este ítem se detalla a continuación.

Descripción del defecto

Se ha dejado este tópico aparte por la atención que merece. De la buena redacción del defecto depende en gran medida que se logren minimizar los problemas asociados a los altos reprocesos producidos por las falencias en la interpretación del reporte.

Para lograr con mayor facilidad este objetivo, se puede realizar la descripción del defecto teniendo en cuenta los siguientes elementos:

1. Cuándo: Acción que describe el evento y las variables dentro de la descripción del caso de prueba.
2. Qué: Resultado que se obtuvo al ejecutar la acción (cuándo), que discrepa del resultado esperado.
3. Dónde: Ubicación del objeto de prueba.
4. Resultado esperado: Describe el objetivo de la funcionalidad.

El siguiente ejemplo facilitará entender el ¿por qué? de estos elementos.

Ejemplo: Transferencia bancaria

Variables: Cobertura, receptor, clave.

Falla: El sistema genera el mensaje “Fondos insuficientes”

Caso de prueba

Descripción del defecto

Identificador, precondiciones… Descripción: Realizar una transferencia con suficiente cobertura, un receptor correcto y clave válida. Pasos: 1. Seleccionar la transacción y realizar transferencia 2. Ingresar la clave 3. Ingresar el número de cuenta del receptor 4. Ingresar la cantidad válida con suficiente cobertura Resultado esperado: Se espera que el sistema realice la transferencia del valor exacto al número de cuenta del receptor y se genere un mensaje de transacción exitosa

Forma 1 – Cuándo: Al realizar una transferencia con suficiente cobertura, un receptor correcto y clave válida. – Dónde: En la sección transferencias a otros bancos. – Qué: El sistema genera el mensaje “Fondos insuficientes”. – Resultado esperado: Se espera que el sistema realice la transferencia del valor exacto al número de cuenta del receptor y se genere un mensaje de transacción exitosa. Forma 2 Cuándo – dónde- qué – resultado esperado: Al momento de  realizar una transferencia con suficiente cobertura, un receptor correcto y clave válida, en la sección transferencias a otros bancos; el sistema genera el mensaje “Fondos insuficientes”. Se esperaba que el sistema realice la transferencia del valor exacto al número de cuenta del receptor y se genere un mensaje de transacción exitosa.

Básicamente los elementos cuándo, dónde y resultado esperado del defecto son un “copy –  paste” de los elementos descripción y resultado esperado del caso de prueba. Lo mismo podría darse con los pasos para reproducir el defecto y los pasos del casos de prueba. 

Importancia de escribir buenos Casos de Prueba

• Facilita la redacción y entendimiento del reporte.
• El reporte no necesariamente lo realiza quién escribió el caso de prueba.
• Mejora la comunicación.
• Minimiza reprocesos.
• Una buena gestión genera agilidad.
• La mejora en la comunicación, minimiza desperdicios.

Severidad

Asignar severidades a los defectos reportados facilitará su priorización. Existen diferentes tipos de severidades, tales como: Bloqueante, alta, crítica, mayor, menor, entre otras. Esto dependerá de cada organización.

Es una incidencia o defecto si: Bloquea la ejecución, hay cálculos incorrectos o mensajes errados o inexistentes. Para hacer la vida un poco más sencilla al momento de realizar el reporte, se pueden asignar las siguientes:

• Bloqueante: Un estado de severidad bloqueante es aquel donde no hay funcionalidad de las reglas del negocio y/o la aplicación, presenta bloqueos para continuar con el flujo normal de la funcionalidad o con las pruebas.
• Funcional/Mayor: Son problemas graves que afectan las reglas de negocio. 
• Menor: El defecto no afecta ninguna regla de negocio es probablemente un problema cosmético.

La clasificación por severidad de los defectos es una buena estrategia para medir prioridades, y para que el equipo no se lleve sorpresas al momento de recibir los reportes.

Usualmente se confunde la severidad “Menor” con las mejoras. Sin embargo, las mejoras no hacen parte del ciclo de vida de las incidencias.

Mejora: Es una propuesta que se realiza con el objetivo de agregar alguna característica, funcionalidad o parte del producto, lo cual difiere completamente de la definición de un defecto.

Ciclo de vida de un bug

Estandarizar y comunicar el ciclo de vida de un bug es fundamental para la madurez del equipo y del proceso. Cada estado dentro del ciclo de vida y la asignación de roles arroja información trascendental para el proyecto. Cada organización puede tener su propio ciclo de vida, la recomendación reiteradamente es que sea estandarizado, comunicado y si es necesario, mejorado.

Ejemplo para configurar los estados de un incidente

• Nuevo: El tester crea la incidencia en el sistema de gestión.
• Asignada: La incidencia es asignada al desarrollador para un análisis general.
• Se necesitan más datos: El desarrollador solicita más información para entender el reporte. Este es uno de los estados que se deberían evitar para no generar reprocesos.
• Aceptada: El desarrollador identifica que es un fallo, necesita solucionarse y será abordado o priorizado de acuerdo a la clasificación.
• Resuelta: El fallo es resuelto por el desarrollador y liberado a pruebas para retest. 
• Devuelta: La incidencia fue liberada por el desarrollador, pasa a pruebas como “resuelta” se realiza el retest y se identifica que el fallo no ha sido removido, se devuelve al desarrollador para que sea corregido.
• Cerrada: Este estado se utiliza cuando se  realiza el retest y el tester identifica que la incidencia sí fue corregida. El único que debe tener la potestad para poner la incidencia en este estado es el tester.

Otros estados: “No será corregido” o “no es un defecto”

Siempre que haya un cambio de estado es importante para el seguimiento del proyecto dejar notas documentando las razones del cambio. Es decir, si se toma la decisión de ir al flujo alterno “No será corregido” se debería describir el motivo, por ejemplo:

Estado: “No corregido”

Notas: Se resolverá en el siguiente sprint o se eliminará la funcionalidad.

Ciclo de vida de un defecto

Informe de Prueba

La información de los reportes puede depender de variables como los estados de los defectos, la severidad, tiempo de resolución, qué defectos son los más activos y la efectividad del informador.

Adicionalmente, facilita la obtención de información sobre incidencias por:

• Desarrollador
• Informador o tester
• Resolución
• Tendencias de las incidencias

Profundizar en el análisis habilita la posibilidad de identificar las causas raíces de la incidencia y dejar un registro que se podría configurar a través de una parametrización en el documento o herramienta. Y con ello, aportar al mejoramiento de la gestión de los proyectos, el ciclo de vida del desarrollo del software, el ciclo de vida del producto y su gestión de riesgos.

Una forma de gestionar los defectos para facilitar el seguimiento y monitoreo es crear ciclos de ejecución de pruebas. Cuando se realizan los diseños se crean las suite de pruebas o juego de pruebas, que sirve para agrupar los casos de prueba y disponerlos para la fase de ejecución.

Ciclos de ejecución de pruebas

Los casos de prueba en diseño no están asignados a un plan de prueba particular o a una suite, solo se agruparán para iniciar la ejecución, dado que cada suite tiene un objeto de prueba particular. Se sugiere el uso de 3 ciclos, así:

• Ciclo 1: Se ejecutan los casos de prueba que afectan directamente la funcional que ha sido cambiada, actualizada, corregida o mejorada.
• Ciclo 2: Se prueban los casos de prueba que fallaron en el ciclo 1. El ciclo 2, normalmente se denomina Re-Test.
• Ciclo 3: Se ejecutan los casos de prueba que validan la regresión del producto, son casos de prueba que permiten validar que los cambios no hayan causado daños colaterales.

Algunos errores se reportan en un ciclo y se decide que no serán corregidos, por lo cual, se mantiene el caso de prueba con el reporte. Sin embargo se tiene en cuenta que este deberá planearse para una nueva versión.

Conclusiones sobre los Reportes de Pruebas de Software

• El proceso de gestión de defectos facilita la comunicación entre testers y el equipo de desarrollo.
• El uso de herramientas para la gestión de los defectos incrementa la trazabilidad y facilita el seguimiento y control de los mismos.
• La gestión de incidentes arroja información estadística y cuantificable para la toma de decisiones en los proyectos.
• Permitirá la catalogación de las causas raíces de los defectos. 
• El uso de herramientas software es necesario para lograr una gestión mucho más transparente y organizada de los bugs.
• Mejora la interacción y transparencia para llegar a acuerdos con el equipo.
• El proceso de gestión de la configuración, afecta directamente la gestión de los defectos para  su detección, registro, análisis, medición.
• Los fallos pueden ocurrir en cualquier lugar o momento del ciclo de vida del software: Documentación, código, diseño de arquitectura, funcionalidad, etc.).
• Proporciona a los desarrolladores información sobre eventos adversos.
• Una buena gestión de defectos posibilita la identificación de efectos específicos.
• Los reportes sistematizados permiten aislar los problemas y hacer pruebas de reproducción mínimas.
• Sistematizar la gestión de defectos permite identificar el tiempo dedicado para realizar el reporte de testing y su corrección.

¡Síguenos en LinkedIn, Twitter, Facebook, Instagram y Youtube para ser parte de nuestra comunidad y enterarte de más buenas prácticas para gestionar informes de testing!

---

Otros contenidos relacionados

Cómo crear un Informe de Pruebas de Software eficaz

3 elementos esenciales para lanzar Software rápidamente, sin afectar la Calidad

Cómo crear la estrategia de pruebas adecuada para tu proyecto

Beneficios de Shift Left Testing en el Ciclo de Desarrollo de Software

---