Propósito

Tener en cuenta (de cara a la estabilización) todos los errores detectados en la fase de desarrollo y que no se hayan corregido con anterioridad, más los errores detectados mediante el testeo del instalable que inicia la fase de estabilización, más los errores detectadot en versiones anteriores de la aplicación/extensión.

Precondición

Haber acabado la fase de testeo del instalable que da comienzo con la fase de estabilización. Tener acceso al gestor de cambios donde están reportados los errores.

Postcondición

Tener un listado de ticket de error que ocurren sobre el instalable que da comienzo a la fase de estabilización. Este listado se priorizará para decidir qué errores deben ser corregidos para generar una versión estable del desarrollo.

Ejecutor

Testers Coordinador de test

Supervisor

Coordinador de test

Entrada

1.Tickets de error de fase de desarrollo detectados en instalables previos al que da origen a esta fase de estabilización (ya sean reportados por el propio equipo de desarrollo o a través del testo colaborativo)

2.Tickets de error detectados en la ejecución del plan de pruebas de las nuevas funcionalidades

3.Tickets de error detectados al pasar los test de persistencia

4.Tickets de error actualizados desde la versión anterior del mismo producto (sea de gvSIGDesktop, gvSIGMobile o extensiones)

Pasos

[Paso simple (1)]: Reproducir cada ticket dado de alta en la fase de desarrollo en el build que da origen a la estabilización.

[Decisión (2)]: ¿El error sigue ocurriendo?

[Paso siguiente cuando SI se cumple condición]: se pueden dar varios casos, pero en gral. podemos decir de abrir/actualizar un ticket por cada error reproducido sobre la versión a estabilizar. Cuando la versión del ticket original no coincida con la versión del desarrollo a estabilizar, se tendrá como norma abrir un ticket nuevo.

[Paso siguiente cuando NO se cumple condición]: de no poder reproducir el error puede ser por varias razones. Si es porque se ha corregido durante la fase de desarrollo, dicho ticket se cerrará. Si es porque la información del ticket no es suficiente para poder hacerlo, estos tickets se invalidarán y no se tendrán en cuenta en la estabilización.

[Éxito Final (3)]: Una vez se hayan repasado todos los tickets definidos como Entradas de este proceso, se conseguirá el listado de tickets de error que efectivamente se producen sobre el build que abre la fase de estabilización.

Salida

1.Listado de tickets de error que efectivamente ocurren sobre el build que da comienzo a la fase de estabilización

2.Actualización de los tickets que ya han sido corregidos en la fase de desarrollo. Estos tickets tendrán un estado de cerrados (para no ser tenido en cuenta en el futuro). Además se pondrá un comentario en el ticket sobre el build en el que se ha comprado que ya no courren.

Artefacto

Formulario de ticket de error. New Ticket

Cómo dar de alta un error. Cómo comunicar un error

Herramienta

Navegador web

Aplicación gvSIG

Acceso a bugtracking o gestor de cambio correspondiente