Una polilla aleteó (en 1945) en el interior del Mark II (uno de los primeros ordenadores) hasta quedar atrapada en uno de los revés impidiendo que este funcionara. De ahí el término “bug” para los defectos.

Los defectos del software (también conocidos como “bugs”) son fallas o errores que se encuentran en una aplicación y que producen resultados no esperados o que no cumplen con las necesidades del cliente.

Estos pueden ser originados por diversas causas, desde un mal levantamiento de requerimientos, especificación incorrecta, requerimientos incumplidos, errores de diseño o codificación, pruebas insuficientes, etc.

Es prácticamente imposible crear un software que no presente defectos, sin embargo, es posible disminuirlos a través de revisiones (verificaciones o validaciones) por diferentes personas.

Introducir actividades de aseguramiento de la calidad desde etapas tempranas del desarrollo, aporta numerosos beneficios para las empresas de desarrollo de software, recuerda que corregir defectos resulta más barato al inicio del desarrollo del producto que cuando este ya se colocó en producción. Por ello siempre es recomendable realizar verificaciones y validaciones a los productos de trabajo.

Encontré un bug, ¿qué hago?

Para que un defecto sea corregido completamente, primero tiene que ser reportado eficientemente, si el reporte no es claro, entendible o completo, el responsable de la solución no lo atenderá o lo resolverá parcialmente. Considera que una mala redacción de un defecto, puede incluso generar uno nuevo (cambiar la funcionalidad requerida por el cliente).

¿Qué incluyo en el reporte del bug?

Existen herramientas para darle seguimiento y control a los bugs (Mantis, ALM, Bugzilla, etc.) que ya traen campos por defecto pero te ofrecen la opción de personalización, quitando de los existentes los que no te sirvan y agregando otros que sí aporten información de valor. Según mi experiencia, te sugiero incorpores/utilices los siguientes campos informativos:

Obligatorios

Estos campos no deben ser omitidos en ningún reporte de defectos:

  • ID del bug: Identificador del defecto, cuando utilizas algún bugtracker se genera automáticamente, pero si no utilizas ninguna herramienta, lo puedes asignar de manera manual. Recuerda que este nunca debe repetirse, aún cuando se trate de diferentes proyectos, puede generar confusión.
  • Título o resumen: Descripción muy breve del bug de manera concreta y entendible (redacta para otros, no para ti). Para ubicar de manera eficiente el defecto, siempre recomiendo que los títulos del bug se realicen de la siguiente manera (el separador “|” es muy importante):
    ROL | Módulo | Sección | Resumen.
    Ejemplo:
    Administrador | Alta de usuarios | Información de contacto | En el campo Nombre no se permite ingresar acentos o mayúsculas.
  • Descripción del bug: Esta información complementa al título del defecto, aquí debes introducir toda la información sobre el bug. Generalmente este campo es ilimitado, pero no abuses, recuerda que debe ser sólo lo necesario.
  • Pasos para reproducir el bug: Indica la secuencia de acciones que realizaste para reproducir el defecto (si un defecto no es reproducible, entonces no deberás reportarlo). Recuerda también agregar los datos que introdujiste (ejemplo: en el campo “A” ingresar el valor “1.2”).
  • Datos adjuntos: Agrega capturas de pantalla de lo sucedido, archivos generados en la aplicación, logs, etc. Cualquier instrumento que le ayude a desarrollo a encontrar el origen del bug.
  • Estado: Situación en la que se encuentra la solución del defecto: abierta, en corrección, resuelta, pendiente por verificar, etc.
  • Precondiciones: Características que debe cumplir el escenario para reproducir el defecto: realizar antes de las 12:00 p.m., haberse logeado con perfil administrador, etc. OJO: No aplica para todos los reportes de bugs.

No necesarios pero recomendados

Si bien, con los datos anteriores ya se puede saber en qué consiste el bug, pero puedes echar mano también de estos campos para ser más claro:

  • Prioridad: Con el cual indicamos la urgencia de la solución del bug.
  • Severidad: Indicar el impacto o la afectación que genera el bug sobre la aplicación.
  • Informador: Persona que detectó y reportó el defecto. Es recomendable que exista un medio de comunicación entre el desarrollador y el informador para resolver posibles dudas que no puedan resolverse sencillamente.
  • Versión de la aplicación: Indicar en qué versión de la aplicación fue detectado el bug. Para desarrollo es muy importante este dato porque quizá es algo que ya se corrigió implícitamente al tratar otra cuestión del software.
  • Tipo de defecto: Indica a qué tipo de defecto fue detectado: De funcionalidad, interfaz de usuario, usabilidad, performance, accesibilidad, etc.
  • Plataforma o sistema operativo:  Indicar qué dispositivo se utilizó (computadora, dispositivo móvil) y qué sistema operativo se usó (CentOS, Windows, Ubuntu, OS X, etc.).
  • Ambiente: ¿En dónde se produjo la falla? Quizá la aplicación se encuentra distribuida en varios ambientes (región 1, región 2, etc.).
  • Navegador: Aplica sólo para aplicaciones Web (Safari, IE, Chrome, FIrefox, etc.). No olvides indicar en qué versión probaste.

Opcionales

Estos campos pueden ser muy útiles a la hora de depurar los defectos, aunque no son necesarios para resolver el bug:

  • Resultado esperado: Para algunos desarrolladores es importante que les indiques este valor. Yo no lo considero tan necesario, el desarrollador ya debería estar informado del resultado esperado a través de los requerimientos.
  • Ciclo de pruebas: Esto para control del área de aseguramiento de la calidad del software. Es una métrica muy importante para revisar cuántos defectos fueron detectados en el primer ciclo, en el segundo, etc.
  • Resolutor: Persona responsable de corregir o depurar el defecto.
  • Caso de prueba: Indicar el nombre del flujo que estabas verificando cuando la aplicación mostró el fallo.
  • Número de intento de prueba: Este parámetro es importante para obtener el número de veces que el defecto se ha dado por corregido, cuando en realidad no lo estuvo (¿No se está reportando adecuadamente el bug? o ¿No se está leyendo toda la información reportada?).

¿Recomendaciones para el reporte de bugs?

Como ya lo mencioné anteriormente, es importante que seas muy breve y claro a la hora de redactar un reporte de defectos. Puedes usar las siguientes recomendaciones para lograrlo:

  • No redactes dando suposiciones o ideas de cómo crees que sucedió el bug. Siempre debes de tener la seguridad de cómo se produjo.
  • Redacta considerando para quién va dirigido el texto. Para este artículo, no redacté usando terminología muy técnica debido a que este texto va dirigido para todos los involucrados en las TIs.
  • Mantén una buena estructura de tu contenido. Que tus frases y párrafos sean cortos.
  • Revisa la sintaxis, que tus frases o ideas sean coherentes.
  • Utiliza los verbos adecuados.
  • Escribe como regularmente hablas.
  • Da una última lectura antes de enviar el reporte, si no entiendes tú, no esperes que entiendan los lectores.

Conclusión

El aseguramiento de la calidad del software debe de ser un proceso que se ejecute desde el inicio del proyecto con el fin de garantizar la satisfacción de los usuarios, erradicando la mayoría de los defectos (bugs) o problemas en los productos de software.

A la hora de realizar verificaciones/validaciones al software, no basta con encontrar defectos, lo ideal es eliminarlos definitivamente de las aplicaciones. Este proceso (detectar, corregir y confirmar la corrección) puede ser largo y repetitivo, esto depende de la efectividad del reporte.

Realizar un buen reporte de defectos (completo, conciso y fácilmente entendible) garantiza que los defectos se corrijan de manera rápida. Cuando no se realiza un reporte de bugs eficiente, lo único que se gana es retraso en el desarrollo del producto y mayor retrabajo. También es importante que el desarrollador lea todo el detalle que el informador le envía, si no hace esto, de nada sirve una buena especificación del defecto.

Si quieres ahorrar tiempos en desarrollo, asegúrate que los bugs que reportas sean entendidos a la primera, no dejes nada en el “supongo que lo entiende”, no todos piensan como tú, ni tienen el contexto que tú posees al momento. Redacta bugs para otras personas, recuerda que el informe va dirigido a otros lectores.

Gracias por haber leído el artículo, ahora permíteme preguntarte: ¿consideras que existen otros campos adicionales que hay que considerar? Con tu experiencia, ¿qué otras consideraciones debemos aplicar? Saludos.