Entradas
Normalmente cuando se desarrollan productos de software, es común que esos productos en las etapas de desarrollo tengan muchos errores o no conformidades por parte de los clientes ya que no cumplen con los requerimientos o hubo un cambio de último momento.
Cuando esto sucede se tiene que realizar el reporte del error o no conformidad (pulga) encontrado para que realicen su corrección. A partir de este momento la pulga inicia un proceso de seguimiento hasta que sea corregido y cumpla con los requerimientos y expectativas del cliente.
Este proceso es el siguiente y se le llama ciclo de vida de una pulga:
1. Cuando se ingresa por primera vez un error o solicitud de un nuevo requerimiento, la tarea tiene estado Open.
2. Cuando el desarrollador corrige o implementa la tarea que se le fue asignada, ella entra en estado de resolved y puede ser por los siguientes puntos que llega a ese estado:
a. Arreglado (Fixed), Resuelto por diseño, No reproducible, No arreglado (No Fixed).
3. Después de que la tarea es revisada por el responsable de la calidad del software, esta entra en estado de cerrado y por los mismos motivos por los que fue resuelto. En el caso de que la tarea no esté funcionando correctamente, el estado que se le asigna es de Re-Open y vuelve a utilizar el mismo proceso hasta llegar al estado cerrado.
4. Algunas veces por correcciones nuevas o requerimientos nuevos, hay tareas que después de cerrados pueden entrar en estado re-open, hay que tener cuidado con este tipo de situación porque no deberían pasar si se tiene un buen proceso de calidad implementado.
2 comentarios:
Como Bug o defecto considero que son los casos de negocios que en la etapa de Testeo se detectan y deben de ser corregidos para tener el Go o No Go del proyecto a producción. Si nos reportan un incidente en producción entonces entraríamos a validar si es un escenario que se dejó por fuera de la etapa de testing (no debería de pasar)o si es un nuevo requerimiento al que nos estamos enfrentando, para el cual entraríamos a una mejora de la versión actual. Creo que para documentación y seguimiento de estos Bugs en las etapas de testeo, debemos de tener los estados de New:cuando lo reportan; Open: cuando es asignado a un especialista para su análisis y solución; Re-testin; Rejected; Re-open, Fixed y Closed. Claro está, debemos de tener casos de negocio documentados a testear, responsables de los testeos, responsable de la etapa de testeo; así podemos tener un panorama mas claro (documentación)de como solucionamos un Bug para futuras versiones.
Gracias por el comentario.
Desde luego hay muchas formas de cómo se puede reportar un error pero en general el ciclo de vida siémpre tiene este comportamiento.
No necesariamente una pulga tiene que ser detectada en la etapa de testeo, ya que un desarrollador puede detectar varias defectos en las pruebas que él realiza antes de que el producto sea puesto en Calidad y es importante registrarla para llevar su control y asi si vuelve a ocurrir saber cual es su solución.
Es muy importante lo que usted dice, documentar, tenemos que tener guías para que el testeo de las aplicaciones sea mas ordenado aunque existen tipos de prueba que no necesitan documentación, próximamente estaré hablando de los diferentes tipos de prueba que se pueden aplicar.
Publicar un comentario