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”

]]> http://www.codigomanso.com/es/2009/10/consejo-manso-como-reportar-bugs/feed/ 9 http://www.codigomanso.com/es/2009/01/micropost-testing-shows-the-presence-of-bugs/ http://www.codigomanso.com/es/2009/01/micropost-testing-shows-the-presence-of-bugs/#comments Fri, 16 Jan 2009 10:16:23 +0000 Pau Sanchez http://www.codigomanso.com/es/?p=455 Hoy Hector, en un mail, me ha puesto la siguiente frase, con la que estoy totalmente de acuerdo:
“Testing shows the presence, not the absence of bugs” – Edger Dijkstra

Es decir, los tests están para capturar y mostrar si hay algún bug, sin embargo cuando todos los tests pasan, no significa que la aplicación no tenga bugs, normalmente significa que no hay suficientes tests para capturarlos

Por otro lado, cuantos más tests haya se supone que mejor cobertura tendrá la aplicación y mas robusto será el software que hagamos.