Informe de Errores: Qué es y Cómo Redactarlo Correctamente

Todo lo que siempre quisiste preguntar, pero no sabías a quién.

Un informe de error (bug report) es uno de los principales documentos de trabajo de un tester y un ingeniero de QA. Describe un defecto detectado en el funcionamiento de una aplicación o programa para que los desarrolladores puedan solucionarlo posteriormente.

¿Qué es un bug y un informe de error?

Un bug (del inglés bug) es un error en el funcionamiento de un programa o aplicación. Por ejemplo, un usuario añade un producto a su cesta en una tienda online y pasa a la fase de pago. Si todo funciona correctamente, introducirá los datos de su tarjeta bancaria y realizará el pedido. Si el producto no se añade a la cesta o el botón de pago está inactivo, eso es un bug, ya que esperamos un resultado diferente.

Por lo tanto, podemos formular una segunda definición:

un bug es la no conformidad del software desarrollado con los requisitos especificados.

¡Importante!

Bug es un término coloquial. En la terminología oficial se distinguen varios conceptos:

• Error: Son las acciones del desarrollador que han llevado a un resultado diferente al esperado. Por ejemplo, ha escrito un fragmento de código incorrecto.
• Defecto: Un fallo en el código escrito incorrectamente por el desarrollador. Cuando se ejecuta, provoca un fallo en el funcionamiento del software.
• Fallo: El resultado de ejecutar un código con un defecto.

En este artículo, englobamos los términos fallo y defecto bajo la palabra «bug». Pero recuerda que en la documentación o literatura oficial puedes encontrarte con términos individuales.

Los testers y los ingenieros de QA buscan bugs. No solo lo hacen después del lanzamiento del programa, cuando ya hay usuarios activos, sino en todas las etapas de su desarrollo.

También puedes leer: ¿Qué son las versiones alfa y beta?

Cuando un especialista encuentra un bug, debe informarlo a los desarrolladores. En algunos equipos se hace usando un software específico, y en otros simplemente escribiendo un mensaje al especialista en un mensajero. Pero existe un estándar para documentar un defecto detectado: el informe de error.

Tipos de bugs

Según el lugar o las condiciones en las que se detectan los defectos, se clasifican en varios tipos: funcionales y no funcionales.

Defectos funcionales

Aparecen cuando la aplicación o el sitio web no cumplen sus funciones. Por ejemplo, al pulsar el botón Guardar texto en un editor online, el texto no se guarda.

Una variedad de defectos funcionales son los lógicos. Son bugs que provocan un mal funcionamiento del programa desde el punto de vista de la lógica: en el campo Mes al indicar la fecha de nacimiento se puede seleccionar un número mayor de 12 o en el formulario de registro de un sitio web escribir una dirección de correo electrónico sin «@«.

Defectos no funcionales

Son bugs que no están directamente relacionados con la funcionalidad del software, pero afectan a su funcionamiento o comodidad para el usuario.

• Bugs de IU (Interfaz de usuario): Los elementos de la aplicación se dibujan incorrectamente: el tamaño y el color de un botón en la interfaz difieren del diseño, imágenes con proporciones distorsionadas, etc.
• Defectos en la UX (Experiencia de usuario): La aplicación o el sitio web son incómodos para el usuario. Una página web puede tener una navegación poco intuitiva, por lo que el usuario tiene que cambiar varias veces de pestaña en el menú antes de encontrar la que necesita.
• Bugs de rendimiento: Una aplicación o programa debe poder gestionar la carga sobre él. Por ejemplo, una tienda online se prepara para un aumento del número de usuarios antes de una venta anunciada. Si en el momento del inicio de la venta se produce una sobrecarga del servidor, se trata de un bug de rendimiento.
• Defectos de portabilidad y multiplataforma: Los programas y aplicaciones deben funcionar de forma estable en diferentes sistemas operativos, navegadores, etc.
• Fallos de seguridad: Bugs que pueden provocar la fuga de información confidencial: los datos de la tarjeta bancaria se transmiten entre la aplicación y el servidor a través de un protocolo no seguro, etc.

Gravedad del bug y prioridad de la corrección

Históricamente, para los defectos se indicaban dos características: gravedad y prioridad. Cada una de ellas determinaba la importancia de un bug concreto. Actualmente, los parámetros se han unificado en uno: prioridad. Pero es útil conocer ambos, ya que aparecen en la literatura técnica.

Niveles de gravedad de los bugs

• Nivel trivial: Estos errores no afectan al funcionamiento del programa o la aplicación. Por ejemplo, son errores tipográficos en el texto de una página web o una inscripción que no está centrada en un botón.
• Nivel menor: Bugs que el usuario no percibe, ya que no afectan a la funcionalidad: un botón mal colocado que dificulta la navegación, etc.
• Nivel serio: El usuario ve el defecto, pero no le impide trabajar con la aplicación o el programa. Por ejemplo, no puede acceder a una página del sitio web desde el menú principal, pero se abre desde otra página.
• Nivel crítico: Se limita el funcionamiento de una parte importante del programa, pero se puede utilizar el software: no se puede seleccionar la fecha de nacimiento durante el registro y el usuario se registra con el valor predeterminado del formulario, o no se aplica un código promocional de descuento en una tienda online, pero el producto se puede comprar al precio normal.
• Nivel bloqueador: El software no funciona. Por ejemplo, el sitio web devuelve un error 404 o la aplicación no se abre.

Prioridad de los bugs

La prioridad determina la rapidez con la que es necesario corregir un defecto detectado. Normalmente, la característica no la establece el propio tester, sino el gestor o el product owner, que pueden evaluar los riesgos para el producto debido al bug: pérdida de beneficios, fuga de usuarios a la competencia, etc.

• Baja prioridad: El problema no afecta al funcionamiento de la aplicación o el programa, por lo que se puede resolver en última instancia si hay recursos disponibles.
• Prioridad media: El bug debe incluirse en el plan de trabajo, pero no hay necesidad de prisas.
• Alta prioridad: Es necesario corregir el defecto inmediatamente, ya que la aplicación o el programa no funcionan.

Ciclo de vida de un bug

Los equipos de pruebas y desarrollo documentan el trabajo sobre los bugs. Para ello, utilizan sistemas de gestión de proyectos en los que es cómodo crear y gestionar informes de errores: YouTrack, Trac o Jira.

Uno de los puntos importantes del seguimiento del estado de un bug es indicar su estado. Gracias a ello, los testers o desarrolladores saben qué acciones se requieren de ellos. En diferentes empresas, el número de estados puede variar. Pero en cualquiera de ellas se pueden encontrar cuatro estados principales:

• Abierto: El tester ha detectado un bug y lo ha introducido en el sistema de acuerdo con la plantilla de diseño adoptada.
• En proceso: El responsable ha recibido el informe de defecto y lo ha aceptado para su trabajo.
• Corregido: El desarrollador ha indicado que ha realizado el trabajo para corregir el bug y el producto se puede enviar a las pruebas de verificación.
• Cerrado: Las pruebas repetidas han confirmado la corrección del bug. El ticket se cierra. Si el problema persiste, la tarea se vuelve a abrir y se devuelve al responsable.

Además del estado del bug, se puede indicar la respuesta del desarrollador (resolution). Por ejemplo, Aplazado (Later), es decir, aplazado para más tarde debido a un cambio de prioridad, Rechazado (Incorrect / Cannot reproduce), si el informe de error está mal redactado, por ejemplo, no se indican los pasos para reproducir el error, etc., aceptados por el equipo.

Estructura de un informe de error

Cada empresa tiene su propia estructura para los informes de error. Pero la mayoría de las plantillas tienen puntos comunes:

El informe de error lo elabora un tester o un ingeniero de QA. Si un desarrollador detecta un bug por sí mismo, lo rellena o lo envía al departamento de pruebas para reproducir el defecto y describirlo detalladamente.

Ejemplo de informe de error

Veamos cómo se ve un informe de error en la realidad. Tomaremos como base nuestra plantilla:

Cómo redactar correctamente un informe de error

Algunos equipos y testers consideran que la elaboración de un informe de error es una tarea desagradable e innecesaria. Lo rellenan parcialmente o envían la información sobre los defectos en los mensajeros.

Pero esta práctica conduce a la persistencia de los bugs existentes y a una baja eficacia en su cierre. Por lo tanto, los testers y los ingenieros de QA deben seguir reglas estrictas para la elaboración de un informe de error.

• Describir el defecto con el máximo detalle. Nunca describas un bug con una sola frase. Imagina que va a trabajar con él un desarrollador que no ha abierto el programa o la aplicación antes. Por lo tanto, describe el problema de forma clara y concisa e indica la secuencia de acciones que conducen a la aparición del defecto.
• Usar la plantilla de informe de error adoptada por la empresa, y no inventar la tuya propia. Los desarrolladores y otros testers ya están acostumbrados a un formato establecido, por lo que la aparición de nuevos campos o la eliminación de los antiguos puede provocar errores en la interpretación de la información. Si crees que son necesarias nuevas incorporaciones a la plantilla, discútelo con el responsable del departamento de pruebas o el gestor.
• Localizar el bug y las formas de provocarlo en la medida de lo posible. Si no es posible, indícalo claramente. Antes de describir un defecto, reprodúcelo varias veces, señalando las diferentes condiciones de aparición y la secuencia de acciones que lo provocan. Esto ayudará a los desarrolladores a identificar y eliminar más rápidamente la causa del bug.
• Adjuntar materiales adicionales. Para los bugs que se ven inmediatamente, sin reproducir acciones específicas, capturas de pantalla; para los bugs que aparecen durante el funcionamiento, screencasts; y para los bugs de API, registros, etc. El desarrollador los analizará y podrá comprender más rápidamente en qué consiste el defecto del funcionamiento del software.