Dentro de las pruebas de Testing uno de los objetivos comunes es detectar defectos en las aplicaciones, tipicamente las incidencias que vemos mientras probamos las aplicaciones las reportamos (Diferencia entre lo esperado y el resultado real) y es necesario darles seguimiento oportuno hasta que se confirme su solución.


Además el reporte de estas incidencias persiguen ciertos objetivos especificos como pueden ser:
  • Ayudar a los desarrolladores a detectar en donde se encuentra el defecto.
  • Proporciona a los lideres una visión de la calidad del sistema y el progreso de las pruebas.
  • Ayudar a mejorar el proceso de desarrollo y de pruebas.
A continuación vemos el clico clasico de las incidencias y basicamente buscamos que como minimo el reporte de una incidencia contenga lo siguiente:
  • Fecha en la que se esta detectando el problema.
  • Nombre de la persona que lo detectó.
  • Objetivo, severidad y Prioridad de la incidencia.
  • Descripción (Pasos a seguir para reproducir la prueba, resultados esperados VS Reales).



Cada compañia o departamento pudiera tener su propia versión del ciclo de vida dependiendo del sistema utilizado para el seguimiento de ellas, desde papel y lapiz hasta una herramienta como HP ALM, Bugzilla, TFS, JIRA, etc.


Reportado.- Corresponde al primer Estatus una vez que hayamos creado el reporte de la incidencia.
Rechazado.- Cuando después de ser revisado por el Comité encargado o por el equipo de desarrollo se determina que el reporte no es válido. Ya sea que falta detalle en el reporte o que lo reportado no corresponde a un defecto en la aplicación sino en otra cosa.
Abierto.- Cuando después de ser revisado se reconoce como un defecto de la aplicación o falla en base de datos, ambiente, etc. En fin algo que necesita la atención del equipo de desarrollo o alguien más para su corrección.
Diferido.- Cuando después de ser analizado por parte del equipo de desarrollo se determina que no se será arreglado. Las razones pueden ser varias, por ejemplo que el costo de arreglar el defecto sea mucho comparado con el impacto que el defecto tiene en el sistema.
Asignado.- Una vez que se analizo el defecto se asigna a la persona indicada para su reparación.
Arreglado.- La persona asignada a reparar el defecto hizo los cambios necesarios para su resolución, normalente después de este paso regresa a quien lo reporto o al equipo de Testing encargado de la aplicación.
Reabierto.- Es cuando el equipo de Testing o quien reporto el defecto originalmente prueba la solución pero el defecto se sigue presentando de la misma forma que se reporto originalmente o con cierta variación pero que sigue pasando en el sistema.
Cerrado.- Este estatus significa que quien reporto el defecto originalmente o el equipo de Testing han verificado que el defecto ya no se presenta dentro del sistema. Si el defecto reaparece en una versión más adelante se procede a re-abrir el defecto.


A continuación el ejemplo de bugzilla:
https://landfill.bugzilla.org


El mapeo que podemos hacer de estos que trae bugzilla (Estos son los que encontramos en la pagina de prueba de bugzilla, sin embargo son editables por el administrador, asi que pueden diferir)


Unconfirmed = Reportado
Confirmed = Abierto
In_Progress = Asignado
Resolved & Fixed = Arreglado
Resolved & Invalid = Rechazado
Resolved & Wontfix = Diferido
Resolved & Duplicate = Rechadado
Resolved & Worksforme = Rechazado
Verified = Cerrado
Confirmed = Reabierto (Ya que de verified nos permite regresar a Confirmed).

Como mencione anteriormente en otras herramientas pudieran existir otros Estatus, pero cualquiera se puede mapear a este ciclo generico mencionado por lo que teniendo claro este podemos adaptarnos facilmente a cualquier herramienta.