Cosas que hay que tomar en cuenta al reportar un BUG

Un tema que está asociado  al campo de quality control  es el reporte de bugs.  En muchos lugares no hay un estándar o en casos más extremos no se tiene el conocimiento de como realizar esta tarea y simplemente  se reporta en base a una explicación vaga que se ve a primera vista, lo cual puede causar muchos problemas en el lado de desarrollo para poder entender lo que el tester quiso decir al reportar el bug. Muchas veces esto puede causar molestias por parte de dev team  y lógicamente puede causar problemas dentro de un equipo y adicionalmente causar retrasos posiblemente estos retrasos no sean de tiempo largo, pero al momento de tener tiempos cortos esto puede llegar a ser algo incomodo y perjudicial para el equipo. Supongo que este escenario pude ser más común en los equipos distribuidos. Ya que se contaría con idas y vueltas y hasta en muchos casos sería necesario realizar una reunión para poder clarificar que quiso informar  el tester al reportar el bug.

Por otra parte muchas de las empresas pueden contar con el software necesario para poder realizar el seguimiento de los bugs reportados, pero tenemos que tomar en cuenta que estos sistemas si bien son útiles  posiblemente no cuenten con los campos necesarios para poder explicar de manera correcta un bug o en el peor de los casos se tengan los campos pero solo se llenen los que el usuario vea útiles por que no se tienen normas definidas o por alguna otra razon.

Hablando con un amigo Dante Villarroel  alias (dantecillo y otro alias mas).Compañero de trabajo sobre el tema le pregunte que campos crees que es necesario en un bug.

El me contesto lo siguiente:

• Titulo
• Descripción 
• Requerimientos (son por ejemplo el ambiente (OS), despues el tipo de instalacion (distributed, full), otras configuraciones adiconales, como ser (User is not a member of domain admins.. etc etc.)
• Severidad
• Build
• Pasos
• Resultado obtenido
• Resultados esperado
• En alguna caso prioridad a lo que enfatizo que el equipo de dev es el que coloca este valor

También investigué más del tema en encontré lo siguiente:

• Reporter (llenado automaticamente)
• Producto: 
• Version: 
• Componente: 
• Platform (‘PC’, ‘MAC’, ‘HP’, ‘Sun’ etc.)
• Operating system ( Windows NT, Windows 2000, Windows XP etc.)
• Prioridad:
• Severidad:
• Estado (llenado automaticamente)
• responsable: 
• URL:
• Resumen:
• Descripcion:
• Pasos: 
• Resultado esperado
• Resultado actual

Y bueno desde mi perspectiva pienso que tanto Dante como la página amiga en la cual encontré la información tienen datos muy similares lo único que varia serian los datos auto llenados que sino estoy mal Dante también los toma en cuenta pero como algo que ya es automático y que comúnmente no se llena en un formulario por un tester pero que si debería estar.

Recordar también al momento de reportar un bug todo tester debería saber  "Que el desarrollador tiene que ser capaz de reproducir los bugs en su ordenador sin ayuda del tester", una ves que este lo haga entonces como tester sabras que esta realizando un buen trabajo 

Ahora bien como dicen que una imagen vale más que mil palabras y navegando en internet encontré una imagen muy interesante la cual describe todo lo anterior.

 bueno hasta la proxima saludos a todos...............