Un buen reporte de resultados de pruebas de software debe ser claro y preciso. En este artículo, descubre cómo mejorar la gestión de errores informáticos, a través de un buen diseño de casos de prueba, para contribuir a la calidad del producto final. La comunicación efectiva y una correcta planificación de la estrategia de pruebas son claves para minimizar riesgos y contribuir al éxito de la aplicación o sitio web.

Redactar un defecto puede parecer sencillo, pero los reportes de pruebas de software comúnmente no se alinean con el caso de prueba. Aunque existan formatos, es común que el equipo de testing no los transmita claramente y que el de desarrollo no los entienda, lo que crea confusión y retrasos en la entrega del producto final.

En Abstracta, identificamos oportunidades de mejora desde el inicio de los proyectos en conjunto con nuestros clientes. Ignorar la gestión de defectos como fase fundamental del proceso de pruebas genera riesgos de mala comunicación y considerables pérdidas económicas.

Para mejorar la gestión de errores en el sistema o una página web, es importante comprender primero qué es un informe de testing y QA de software. En este artículo, exploramos sus elementos clave y algunas buenas prácticas.

¿Qué es un informe de testing y QA de software?

Un informe de testing es una herramienta clave para entender los procesos y el desempeño del software. Iniciar este proceso de manera temprana ayuda a identificar las causas raíces de los problemas, minimiza riesgos asociados a los proyectos y al producto y permite evaluar en detalle el estado del software. Una gestión de errores efectiva mejora la comunicación entre el equipo y el cliente, lo cual ayuda a que las tareas se completen según lo planeado.

Este informe contiene el registro de diferencias entre el resultado esperado y el obtenido durante la ejecución de las pruebas de software. Estas diferencias se identifican en diferentes etapas del ciclo de vida del desarrollo.

El diseño de casos de prueba, planes de pruebas adecuados y la transparencia son esenciales para aumentar la calidad del producto. Un informe bien estructurado debe ser fácil de leer y evitar malentendidos por mala comunicación.

Esto permite que los equipos manejen una cantidad considerable de datos de manera efectiva y ofrezcan un mejor servicio al usuario. Comprender la importancia de estos documentos ayuda a los equipos de trabajo a mantener la confianza y realizar entregas de manera eficiente.

¿Cuál es la importancia del reporte de resultados de pruebas de software?

Un informe de testing y QA debe incluir todas las pruebas realizadas, los datos recolectados y los cambios necesarios para mejorar la calidad del producto. Es importante que el equipo revise constantemente los casos de prueba para asegurar que todos los procesos se cumplan adecuadamente.

1. Información del producto

El informe ofrece información valiosa sobre el funcionamiento del producto y el desempeño del equipo y los procesos.

2. Prevención de problemas

Un informe exhaustivo previene la falta de información y la trazabilidad. Con suficientes datos, se puede predecir el comportamiento futuro del software y tomar decisiones informadas.

3. Ahorro y mejora continua

Evitar reprocesos mediante un buen informe ahorra dinero. Además, facilita la mejora continua al generar ideas para optimizar los procesos de desarrollo y pruebas.

¿Cómo reportar incidentes informáticos?

Los informes de prueba deben ser claros, ordenados, fiables, precisos y trazables. Deben contener información pertinente y coherente que ayude al equipo a entenderlos rápidamente. Es importante detallar cada caso de prueba para facilitar su revisión.

Cualquier defecto detectado debe ser investigado, reportado y monitoreado bajo un proceso estricto de seguimiento. Utilizar una herramienta adecuada para el registro y seguimiento de los defectos contribuye a una buena gestión.

1. Documentación

Para mejorar la documentación del reporte y su lectura, incluye los siguientes atributos:

1. Casos de prueba detallados: Facilitan el entendimiento y redacción del defecto.
2. Identificador único: Permite la trazabilidad de los errores a lo largo del proceso de QA.
3. Tarea principal: Asocia los errores a la tarea principal para mejorar la trazabilidad.
4. Informante: Persona responsable de encontrar y reportar los errores.
5. Estado: Depende de la situación, puede ser abierto, cerrado, en revisión, anulado, entre otros.
6. Versión: Especifica en qué versión del producto o commit se encontraron los errores.
7. Severidad: Facilita la priorización para la resolución de los errores.
8. Reproducibilidad: Identifica la frecuencia de los errores.
9. Resumen: Una breve descripción que interprete fácilmente el defecto. Debe proporcionar una visión clara del problema y facilitar la comprensión rápida del caso de prueba por parte del equipo de QA.
10. Reproducir el error: Describe paso a paso cómo reproducir fielmente los errores encontrados.
11. Información adicional: Incluye datos de prueba, diagnóstico y cualquier información que facilite la solución del defecto. Proporciona detalles sobre el contexto del error, como el estado del software, la versión y los cambios recientes.
12. Ambiente: Nombre o identificador del ambiente donde se produjo el problema.
13. Soportes visuales: Imágenes o videos que faciliten la comprensión del defecto.
14. Descripción del error: Una descripción clara y detallada para facilitar la corrección.

2. Descripción del error o incidente informático

Una buena redacción del defecto es crucial para minimizar problemas y altos reprocesos causados por malentendidos en el informe. Para describir un defecto adecuadamente, considera los siguientes elementos:

• Cuándo: Acción que describe el evento y las variables del caso de prueba.
• Qué: Resultado obtenido que difiere del esperado.
• Dónde: Ubicación del objeto de prueba.
• Resultado esperado: Objetivo de la funcionalidad.

Una descripción clara y precisa permite al equipo de pruebas identificar, comprender y solucionar el defecto sin malentendidos. Incluir todos los datos relevantes mejora la calidad del informe y facilita el proceso de revisión.

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 la descripción y el resultado esperado del caso de prueba. Lo mismo aplica para los pasos para reproducir el defecto y los pasos del caso de prueba.

3. Severidad

Asignar severidades a los defectos facilita su priorización. Existen diferentes tipos de severidades: Bloqueante, alta, crítica, mayor, menor, entre otras. Esto depende de cada organización y del plan de pruebas.

• Bloqueante: Impide la ejecución completa del proceso de pruebas. No hay funcionalidad y bloquea el flujo normal.
• Funcional/Mayor: Problemas graves que afectan las reglas de negocio. Deben ser priorizados para resolución inmediata.
• Menor: Problema que no afecta las reglas de negocio, generalmente relacionado con la apariencia o usabilidad del software. Debe ser documentado.

Clasificar los defectos por severidad ayuda a medir prioridades y evitar sorpresas, además de mejorar la gestión de proyectos y la evaluación del estado del software.

Es importante diferenciar entre defectos y mejoras. Las mejoras no son defectos y no forman parte del ciclo de vida de las incidencias. Son propuestas para agregar características o funcionalidades, optimizando el software y añadiendo valor. No deben tratarse en el mismo informe de pruebas.

Ciclo de vida de los defectos

Estandarizar y comunicar el ciclo de vida de un defecto es fundamental para la madurez del equipo y del proceso. Cada estado dentro del ciclo de vida y la asignación de roles brinda información clave para el proyecto. Cada empresa puede tener su propio ciclo de vida, pero es importante que este sea estandarizado, comunicado y, si es necesario, mejorado.

Te puede interesar: El error más común en el ciclo de vida de un incidente informático.

¿Cómo determinar los estados de los errores?

• Nuevo: El equipo de testing crea los errores en el sistema de gestión. Aquí comienza la evaluación inicial del defecto registrado.
• Asignado: Los errores son asignados al equipo de desarrollo para un análisis general. En esta etapa, es importante que el resultado del análisis sea documentado en el informe.
• Más datos: Desde desarrollo solicitan más información para entender el informe. Este es uno de los estados que debemos evitar para no generar reprocesos y retrasos en el proceso de QA.
• Aceptado: Se confirma que son errores que necesitan solucionarse y se abordarán o priorizarán según la clasificación. Este estado valida la calidad del informe inicial.
• Resuelto: Los errores son resueltos y están listos para volver a probar. El reporte de resultados debe reflejar el cambio y el estado actualizado del defecto.
• Devuelto: Los errores liberados por desarrollo pasan al estado “resuelto”. Si el retest identifica que los fallos no han sido solucionados, se devuelven al área de desarrollo para corregir.
• Cerrado: Este estado se utiliza cuando se realiza el retest y el equipo de testing confirma que los errores fueron corregidos. Solo dicho equipo puede determinar cuándo cerrar la incidencia para lograr la trazabilidad del proceso de pruebas.
• Otros estados: “No será corregido” o “no es un defecto”. Estos estados deben ser utilizados con precaución y bien documentados para evitar malentendidos.

Siempre que haya un cambio de estado, es importante documentar las razones del cambio para el seguimiento del proyecto. Por ejemplo, si se decide ir al flujo alterno “No será corregido”, se debe describir el motivo, como resolverlo en el siguiente sprint o eliminar la funcionalidad.

Análisis y gestión de resultados de pruebas de software

Profundizar en el análisis permite identificar las causas raíces de las incidencias y dejar un registro que se puede configurar mediante una herramienta o documento parametrizado. Esto contribuye al mejoramiento de la gestión de los proyectos, del ciclo de vida del desarrollo del software, del ciclo de vida del producto y de su gestión de riesgos.

Una forma efectiva de gestionar los defectos y facilitar el seguimiento es crear ciclos de ejecución de pruebas. Durante el diseño, se crea un conjunto que agrupan los casos de prueba y los preparan para la fase de ejecución.

Ciclos de ejecución de una prueba

Los casos de prueba en diseño no están asignados a un plan de pruebas particular o a un conjunto de pruebas, por lo que se agrupan para iniciar la ejecución, ya que cada conjunto tiene un objetivo específico. Sugerimos el uso de 3 ciclos:

• Ciclo 1: Ejecución de los casos de prueba que afectan directamente la funcionalidad que ha sido cambiada, actualizada, corregida o mejorada.
• Ciclo 2: Testear los casos de prueba que fallaron en el ciclo 1. Este ciclo, normalmente denominado retest, verifica que los errores identificados previamente han sido corregidos adecuadamente.
• Ciclo 3: Ejecución de los casos de prueba que validan la regresión del producto. Estos casos de prueba aseguran que los cambios no hayan causado daños colaterales en otras partes del software.

En algunos ciclos, los errores reportados no se corrigen de inmediato, por lo que el caso de prueba se mantiene con el reporte. Sin embargo, es necesario planear su corrección para una nueva versión. Documenta estos defectos y planifica su resolución en futuros ciclos de ejecución para mejorar la calidad y estabilidad del software.

El proceso de gestión de defectos facilita la comunicación entre testers y el equipo de desarrollo. Una buena comunicación es esencial para aumentar la eficacia de las pruebas y la resolución rápida de los problemas.

• El uso de herramientas para la gestión de errores informáticos incrementa la trazabilidad y facilitan la revisión, registro, seguimiento y control. Estas herramientas proporcionan información valiosa y organizada, lo que permite un manejo más eficiente de los defectos y optimizar el conjunto de procesos de prueba.
• La gestión de errores arroja información estadística y cuantificable para la toma de decisiones en los proyectos. Esta información es crucial para evaluar el estado del software y la realización del plan de pruebas futuras.
• Permite la catalogación de las causas de los errores, lo cual ayuda a prevenir la recurrencia de problemas similares y mejorar continuamente el proceso de desarrollo.
• Mejora la interacción y transparencia para llegar a acuerdos con el equipo. Es importante que cada una de las personas involucradas en el proyecto estén alineadas y comprendan las prioridades y el impacto de cada uno de los errores.
• La gestión de la configuración afecta directamente la detección, registro, análisis y medición de los errores. Por ejemplo, un método bien definido y documentado permite identificar problemas de manera eficiente. Utilizar un formato estándar y seguir un conjunto de pasos claros asegura procedimientos consistentes.
• Los errores pueden ocurrir en cualquier momento del ciclo de vida del software: documentación, código, diseño de arquitectura, funcionalidad, etc. Es importante contar con las herramientas adecuadas, realizar actividades de monitoreo continuo, tener un equipo capacitado y seguir procesos establecidos para identificar y gestionar estos problemas en cada etapa.
• Los reportes sistematizados permiten aislar problemas y realizar pruebas específicas para su identificación, con el fin de reducir el tiempo y esfuerzo necesarios. Además, permiten identificar el tiempo dedicado a realizar el informe y su corrección, lo que mejora la eficiencia del equipo.

En definitiva, en Abstracta ofrecemos servicios de pruebas de software que añaden valor en todas las etapas del ciclo de vida del desarrollo de software. En todo momento, nos centramos en la calidad para ayudar a las organizaciones a innovar con confianza. Combinamos la excelencia técnica, el liderazgo global, la tecnología de vanguardia, la cultura corporativa humanista y el compromiso con la sostenibilidad para capacitar a nuestros testers a diario.

¿Te gustaría seguir aprendiendo sobre buenas prácticas para diseñar un reporte de pruebas qa de software? Revisa este artículo.

---

En Abstracta, brindamos servicios de pruebas de software que añaden valor en todas las etapas del ciclo de vida del desarrollo de software. En todo momento, nos centramos en la calidad para ayudar a las empresas a innovar con confianza.

Combinamos la excelencia técnica, el liderazgo global, la tecnología de vanguardia, la cultura corporativa humanista y el compromiso con la sostenibilidad para capacitar a nuestro equipo de testing a diario. Descubre cómo podemos ayudarte a elevar la calidad de tu software en este artículo.

¡Síguenos en LinkedIn, X, Facebook, Instagram y YouTube para ser parte de nuestra comunidad!