El trabajo del QA es asegurarse de que el producto funciona perfectamente (o al menos con un mínimo de calidad). Es decir, los QA tienen que encontrar el mayor número de problemas posibles, ya sean incoherencias, fallos de compatibilidad, bugs en la aplicación, erratas, …  y una vez los ha encontrado, debe asegurarse de que estos bugs han sido solucionados y no vuelven a aparecer.

Reportar un bug es algo fundamental para que el software mejore. El problema, es que si la persona que nos reporta el bug, nos dice algo como:

• No funciona
• Peta cuando le doy al botón de guardar
• El texto no se pone en negrita
• …

No se tú, pero yo como desarrollador me quedo igual tras leer algo como lo de arriba. No me aporta absolutamente nada.

Desde mi experiencia como desarrollador, reportar un bug es MUY FACIL. La descripción del bug símplemente  debe responder, como mínimo, a las siguientes preguntas:

• ¿En qué consiste el bug?
  Explica cual es el problema y recuerda que a veces una imagen vale más que mil palabras; las capturas de pantalla ayudan
• ¿Cómo se reproduce el bug?
  Una vez detectes el problema, reprodúcelo. Una vez lo reproduzcas, escribe los pasos para que el programador lo reproduzca. Si hace falta, empieza con “Abre la aplicación”. Pon una lista de pasos, donde cada paso sea breve, claro y conciso. Recuerda adjuntar cualquier archivo o dato necesario para reproducir el bug.
• ¿En qué versión del programa ocurre?
  También muy importante es indicar en qué version del programa ha ocurrido (incluyendo el número de build si procede). Para reproducir el bug, es importante que el programador sepa en qué versión exacta ocurre el problema, porque tal vez, en el último build el problema no se reproduce, pero eso no significa que el bug haya desaparecido.
  Si el programa se conecta a algún servidor, también es importante saber la versión del servidor con el que se comunica.

• ¿Cual es el comportamiento esperado? (opcional)
  A veces, no basta con decir cual es el problema, también hay que indicar que es lo que se espera. Obviamente si la aplicación peta cuando se intenta realizar algún cálculo, el comportamiento esperado es realizar dicho cálculo sin que pete, pero si por ejemplo haces click en “Cambiar el color del objeto” y el objeto se vuelve negro, y tú habias seleccionado previamente el color azul, pues el comportamiento esperado es que el objeto se vuelva azul. No siempre hace falta, pero a veces ayuda al que lee la descripción del problema.
• ¿En que versión de sistema operativo / componentes hardware ha ocurrido? (opcional)
  A veces el software sólo falla en determinados ordenadores, determinado hardware, …. Normalmente cuando se reporta un bug, si el programador lo devuelve como que no lo puede reproducir, entonces es que no estamos recreando el ambiente adecuado, es posible que sólo pase en una determinada versión de un sistema operativo, con un hardware específico, etc….

Básicamente la regla de oro de un QA se puede resumir en:

“Que el desarrollador sea capaz de reproducir los bugs en SU ordenador sin mi ayuda”

Trackback URL

bugs, consejo manso, qa, reportar-bugs