No es lo mismo reportar un error que errar reportando

Creo que todos los que actualmente estáis testeando como los que lo habéis hecho alguna vez, tenéis claro que cuando se encuentra un error el siguiente paso es documentarlo. Ya sea trabajando en una suite de un software informático, haciendo test exploratorio del firmware de un aparato electrónico, o ejecutando una prueba de estrés de una página web, si encontramos un bug tenemos que reportarlo de la manera más detallada posible. Siempre sin olvidar aportar todos los datos recopilados tales como archivos de trazas, capturas de pantalla o fotografías que permitan a los desarrolladores implicados entender la causa raíz del problema para así poder subsanarlo.

Cuanto más detallado hagamos el informe de un error, habrá más posibilidades de que se pueda comenzar a buscar la solución a la mayor brevedad. De lo contrario, seguramente nos encontremos con que el desarrollador nos solicite más datos o que nos diga que no lo puede reproducir. Por este motivo debemos redactar de una manera clara y concisa lo que ha ocurrido durante la ejecución del test. También es muy importante no dejarse ningún elemento clave en la descripción. Aquí tenemos algunos puntos a tener en cuenta a la hora de reportar:

• Resumen descriptivo: una frase corta que relate el defecto. Hay que tener en cuenta que el resumen puede ser usado por distintas personas vinculadas a un mismo proyecto, ya sea para buscar información o para comentarlo en una reunión.
• Descripción: en este punto describiremos el bug encontrado de forma breve intentando ceñirnos al máximo a los hechos y sin poner opiniones sobre lo que ha ocurrido. Debe contener todos los elementos relevantes que permitan entender la situación que se está tratando.
• Pasos para reproducirlo: enumerar paso a paso lo que hemos hecho justo antes de que apareciera el error. Han de ser lo suficientemente claros y no estar sujetos a posibles interpretaciones para que cualquier desarrollador pueda reproducirlos fácilmente.
• Resultado actual: definir cuál ha sido el comportamiento anómalo detectado.
• Resultado esperado: explicar el comportamiento definido que tendríamos que haber visto en lugar el error.
• Prioridad: este parámetro nos permite dar mayor o menor visibilidad a un bug y le indica al equipo de desarrollo la urgencia con la que se espera su solución. La nomenclatura con la que definiremos las prioridades deberían estar previamente definidas en el proyecto para que todos los equipos la usen debidamente.
• Severidad: nos indica el impacto que tiene un determinado error sobre lo que estamos testeando. Las diferentes severidades con las que trabajaremos también deberían estar previamente definidas y ser globales.
• Versión o versiones: este punto puede estar dividido en diferentes apartados dependiendo de la tipología del proyecto: versión de firmware, de componente electrónico, de prototipo, etc.
• Estado: definición de cómo está la resolución de un determinado error para facilitar el seguimiento. Los diferentes estados han de estar consensuados desde el inicio y pueden ser muy variados: nuevo, abierto, solucionado, cerrado, más información requerida, duplicado, etc.
• Personas clave: detallar los implicados en la resolución de un defecto como son el desarrollador a cargo del mismo, el tester que lo ha encontrado, el manager del proyecto, etc.
• Entorno: especificar las condiciones con las que hemos encontrado un determinado bug como pueden ser el SO, el navegador, la configuración del ordenador, etc.
• Fecha y hora: normalmente casi todas las herramientas de reporte nos añaden automáticamente estos datos, pero si no es así es muy importante indicarlos para ubicar en el tiempo un determinado problema.

Normalmente los puntos que se acaban de definir ya estarán previamente establecidos por los encargados del proyecto ya sea contemplados en una documentación, en una plantilla o predefinidos en la herramienta que usaremos para informar de los bugs.

Describir un defecto no es difícil si seguimos una metodología y somos rigurosos. Si bien es cierto que la experiencia (ya sea la nuestra propia o de las personas con las que trabajamos) también nos ayudará a mejorar la calidad de nuestros reportes. Debemos evitar hacerlos demasiado extensos aportando información innecesaria para agilizar la comunicación con los desarrolladores, pero también tenemos que evitar ser tan esquemáticos que falten datos esencial. Además antes de definir un bug encontrado tendremos que asegurarnos que no esté ya introducido en nuestra herramienta evitando así duplicidades.

Finalmente, me gustaría indicar que la mayoría de los problemas que se pueden observar en un bug mal documentado no son únicamente responsabilidad del equipo de testing. Hay condicionantes que propician estas situaciones como puede ser la falta de directrices claras en la organización/departamento/proyecto. Otro de los más importantes y presente en muchos grupos es la falta de tiempo y las ajustadas fechas de entrega.

Con todo esto lo que hay que remarcar es que si reportamos un error encontrado de la mejor manera posible y siguiendo las directrices establecidas en el proyecto, nos beneficiaremos nosotros, los desarrolladores, el cliente y los usuarios finales del producto.

Joan Camprodon

Digital Assurance & Testing en SOGETI