Soluciones

 Industrias
 Sobre Abstracta
 Recursos
 CONTACTO

Blog

Tips para generar y gestionar Reportes

de Testing de Software
by Mercedes Quintero Martínez Octubre 14, 2020 Buscar

Buscar aquí... 

Pruebas de Software  1
Categorías

Automatización de Pruebas
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 Calidad de Software Cultura
este proceso. 
Desarrollo de Software DevOps

Estrategia Eventos

Herramientas Liderazgo

Partners Pruebas de Accesibilidad

Pruebas de Performance

Pruebas de Software

Pruebas en Aplicaciones Móviles

Tecnología Testing Ágil

Imagen de Deedster en Pixabay

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 identi camos otro tipo de oportunidades de Descarga nuestro e-book
mejora, desde la fase de inicio de los proyectos de testing, pues al obviar la gestión de defectos como una fase de automatización de
fundamental del proceso de pruebas, se materializaron varios riesgos asociados a la mala comunicación del equipo pruebas:
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 “ nalizan”.
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 identi cación de las
causas raíces de los problemas asociados al software.

La gestión de defectos está orientada a reconocer, investigar, clasi car, registrar, asignar y medir defectos, que
eviten situaciones de bloqueo.
DESCARGAR E-BOOK
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.

Accede a nuestra última

¿Por qué gestionar los reportes de testing? guía de testing continuo

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 su cientes datos para predecir lo que sucederá con el software.
Porque se pueden obtener su cientes 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.
VER GUÍA

¿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 identi car 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, ables, 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:

. Casos de prueba escritos correcta y detalladamente: Facilitará el entendimiento y redacción del defecto.
. Identi cador del reporte: Un identi cador único que permita trazar el defecto .
. Tarea padre: Generalmente el caso de prueba es la tarea padre para asociar el defecto, esta asociación facilita
la trazabilidad.
. Informador o tester: Responsable del reporte, quien encuentra el defecto y redacta el reporte.
. Estado: Según los estados de nidos 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.
. Versión: Especi car en qué versión del paquete, funcionalidad, producto o commit, se encontró el defecto.
. 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.
. Reproducibilidad: Identi car si es un defecto común, si nunca se ha intentado o si es un defecto frecuente.
. Resumen: Escribir un título que permita interpretar fácilmente el defecto.
. 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.
. Información adicional: Datos de prueba, diagnóstico.
. Ambiente o ubicación: Documentar la base de datos de pruebas, el nombre o identi cador del ambiente.
. Imágenes y/o videos: Respaldar el reporte con imágenes o videos para ampliar y facilitar su lectura.
. 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:

. Cuándo: Acción que describe el evento y las variables dentro de la descripción del caso de prueba.
. Qué: Resultado que se obtuvo al ejecutar la acción (cuándo), que discrepa del resultado esperado.
. Dónde: Ubicación del objeto de prueba.
. 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 insu cientes”

Caso de prueba Descripción del defecto

Forma 1

Identi cador, precondiciones… – Cuándo: Al realizar una transferencia con su ciente

Descripción: Realizar una transferencia con
su ciente 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 su ciente
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
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
insu cientes”.
– 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
su ciente cobertura, un receptor correcto y clave
válida, en la sección transferencias a otros bancos; el
sistema genera el mensaje “Fondos insu cientes”. 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 ujo 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 clasi cació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.

Foto de Dids en Pexels

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 di ere completamente de la de nició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 con gurar 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 identi ca que es un fallo, necesita solucionarse y será abordado o priorizado de
acuerdo a la clasi cació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
identi ca 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 identi ca 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 ujo 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 identi car las causas raíces de la incidencia y dejar un registro
que se podría con gurar 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.

Foto de RF._.studio en Pexels

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 cuanti cable 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 con guració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 identi cación de efectos especí cos.
Los reportes sistematizados permiten aislar los problemas y hacer pruebas de reproducción mínimas.
Sistematizar la gestión de defectos permite identi car 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 e caz

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

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

Bene cios de Shift Left Testing en el Ciclo de Desarrollo de Software

Etiquetas

PRUEBAS DE SOFTWARE REPORTES TESTING DE SOFTWARE

 COMPARTIR  57 / 219 

Posts Relacionados

Pruebas de Software Tecnología Calidad de Software Pruebas de Software

Testing de Software, clave para el éxito
de los Pagos Digitales
El panorama de los modos de consumo y pago se
encuentran en pleno cambio de paradigma: el
efectivo es cosa del pasado. Conoce la situación
global y cómo desde Abstracta te ayudamos a
optimizar los pagos digitales.
Abstracta quedó rankeada entre las
principales Empresas de Testing 2020-
2021
Nos apasiona el desafío de ayudar a empresas
disruptivas para que logren introducir mejores
prácticas de gestión de calidad y pruebas de
software, en el ciclo de vida de sus


desarrolladores.
0 Ver más 
 0 Ver más 

Contáctenos Suscríbete a nuestro boletín

CHILE ESTADOS UNIDOS URUGUAY

Escriba su correo SUSCRIBIRSE
Santiago de Chile San Francisco Montevideo/Salto

 +56 9 9506 0968  +1 415 745 3678  +598 2709 6613

Política de Privacidad Abstracta © 2023, Todos los derechos reservados.