Política de Zero Bug

Política de Zero-Bug's, no significa producción de código libre de errores; significa esforzarse por erradicar todos los errores conocidos.

Comience repasando sus problemas existentes y clasificando correctamente los errores. Mueva todos los errores a la parte superior del back log para que el equipo de desarrollo comience a trabajar.

El equipo de desarrollo no debe comenzar a trabajar en ningún otro elemento de la reserva hasta que se eliminen todos los errores. ¡SIN EXCEPCIONES! Si esta regla está comprometida, la técnica no funcionará. Es esta regla es la que obliga a una buena clasificación de defectos.

Introduccion:

Ciclo de vida del defecto o el Ciclo de vida de un error

Es el conjunto específico de estados que un error pasa desde el descubrimiento hasta la reparación del defecto.

El número de estados propuestos por los que pasara un defecto son:

Nuevo: cuando un nuevo defecto se registra y se publica por primera vez. 

Se le asigna un estado como NUEVO.

Activo: una vez que el tester publica el error, y se asigna al recurso responsable. El desarrollador comienza a analizar y trabaja en la reparación del defecto.

Solucionado: cuando un desarrollador realiza un cambio de código necesario y verifica el cambio, además de agregar una prueba de integración o unitaria, como mejor práctica, puede hacer que el estado del error sea "Corregido".

En Pruebas: una vez que se soluciona el defecto, el desarrollador asocia un conjunto de cambios para volver a probar el escenario y el tester lo retoma con el estatus "En pruebas"

Cerrado: Cuando el tester reviso la corrección del BUG y no se volvió a presentar el mismo.

**Re abierto: **En caso de que este siga presente se reasignara a la persona responsable de desarrollo para su atención nuevamente.

Cómo funciona Zero-Bug:

1. Clasificación por prioridad de negocio y criticidad funcional:

Se comienza haciendo que el área responsable de Q&A de los productos y/o sistemas, etiqueten los problemas utilizando una clasificación muy estricta:

• Critico
• Bug
• Característica
• Mejora

Como se realiza:

En el campo **XXX **del elemento Bug dentro del **Azure DevOps **establecer el valor de la clasificación.

2. Asignación de responsables

• De manera inicial el probador y quien detecta el bug es el que debe de crear y/o asignar el mismo al responsable de la plataforma
• Los bugs una vez clasificados de forma adecuada y revisados por el responsable de la plataforma, deberán de ser asignados al programador correspondiente.
• Priorización del equipo de desarrollo en conjunto con el equipo funcional y técnico para resolución de estos.

Clasificación de bugs

P1 - Critico:

Clasificación:

El sistema completo o parte de él no se puede utilizar.

Los consumidores ya no reciben el valor al que tienen derecho, o se desperdicia dinero / tiempo a una tasa inaceptable.

Cuando el sistema no se puede liberar si no se corrige este tipo de defecto.Invalida casos de prueba o escenarios de mayor prioridad.

Resolución:

Detenga lo que está haciendo y solucione el problema inmediatamente.

El tiempo de respuesta debe de ser menor de un día.

P2 - Bugs:

Clasificación:

El sistema no se comporta como se especifica, pero los consumidores pueden recibir el valor al que tienen derecho;Una función principal o proceso está significativamente impactando a la

solución.

La tasa de dinero / tiempo desperdiciado como resultado del problema es aceptable para el corto plazo.

Funcionalidad totalmente diferente a la acordada en el alcance o en los

requerimientos acordados, es decir, el sistema hace algo totalmente diferente a lo acordado.

Resolución:

Termina lo que estás haciendo y luego arréglalo.

El tiempo de respuesta debe de ser menor a dos dias.

P3 - Característica:

Clasificación:

Nueva funcionalidad que aún no existe en el sistema.

Flujos no identificados y/o no analizados.

Cuando el sistema se puede liberar, si no se corrige este tipo de defecto.

Resolución:

Trabajar en estos en el orden de prioridad del backlog.

Crear Feature de mejora o deuda técnica para atender el caso.

Asociar al bug reportado y poner como resuelto con referencia al nuevo elemento creado.

El tiempo de respuesta debe de ser planificado y comunicado al equipo.

P4 - Mejora:

Clasificación:

Una mejora de una funcionalidad o sistema existente.

La prueba puede continuar, aunque se tenga este defecto.

Cuando el sistema se puede liberar, si no se corrige este tipo de defecto.

Resolución:

Trabajar en estos en el orden de prioridad del back log.

Crear Feature de mejora o deuda técnica para atender el caso.

Asociar al bug reportado y poner como resuelto con referencia al nuevo elemento creado.

El tiempo de respuesta debe de ser planificado y comunicado al equipo.

---

Aquí hay algunas pautas de re clasificación:

¿Se puede vivir con el defecto de implementación?

Por ejemplo, la fuente web se está descargando cuando debería estar incrustada en la aplicación

Re clasificar error ↝ Mejora

¿La especificación incorrecta nos está causando un error o una pérdida potencial?

Por ejemplo, los campos requeridos en una interfaz para integración de terceros no se envían adecuadamente como se necesitan.

Re clasificar error ↝ Bug

¿La especificación faltante implica una nueva funcionalidad?

Por ejemplo, los usuarios no pueden editar y compartir sus detalles de perfil en las redes sociales

Re clasificar error ↝ Nueva función

---

Seguimiento de errores en el ciclo de desarrollo:

Para poder tener visibilidad de la clasificación y planificación de atención de bugs tambien podemos implementar por equipo de trabajo dentro del portal de AzureDevOps el siguiente tablero Kanban.

Ejemplo: