Cualquiera que haya sido programador probablemente ha recibido defectos mal reportados. Defectos que no dicen nada ( “No funciona!”); que no tiene sentido; que no dan suficiente información; que dan información errónea. Defectos que resultan ser error del usuario, problemas que son culpa de otro componente del programa; o que resultan ser un problema de red.
Tenemos que distinguir claramente hechos reales de especulaciones. Debemos dejar a un lado las especulaciones, frases como: “Yo creo que el problema podría ser…”, y ceñirnos a los hechos, a lo que ha ocurrido.
¿Que debe incluir el reporte de un defecto?:
- Título del defecto: Una frase corta que describa el defecto. El título puede ser la parte más importante del defecto ya que en los meetings de revisiones de defectos lo primero que se lee es el título del defecto y en función de el se puede tomar la decisión erronea de rechazarlo(“rejected”, “referred”…). Debemos recordar que en este tipo de meetings se revisan muchos defectos y no hay tiempo de leer en detalle todo los pasos del defecto. Es por ello que el título puede ser determinante.
- Breve descripción: intenta describir el defecto en dos o tres frases.
- Pasos para reproducirlo: introducir todos los pasos, debe de ser lo suficientemente explicativo para que el desarrollador pueda reproducirlo fácilmente. Pasos claros que no resulten ambiguos
- Resultado actual: describe lo que realmente ha ocurrido.
- Resultado esperado: describe lo que debería de haber pasado.
- Adjuntar toda la información que sea posible: logs, screenshots o cualquier otra información adicional que creamos puede ayudar al desarrollador a la hora de identificar el problema.
Describir un defecto no es difícil, pero si requiere un poco de sentido común. He visto defectos demasiado extensos y otros que apenas ocupan unas lineas…un defecto no debería añadir una sobrecarga de trabajo a los desarrolladores, sino ayudarles a reproducir el error y resolverlo de manera efectiva en el menor tiempo posible.
Últimos Comentarios