Trazabilidad

La Idea

El modelo en V hace una pregunta simple a cada requisito: ¿qué lo construye y qué lo prueba? Sinra responde con tres vínculos explícitos, todos opcionales, todos legibles desde la ficha de una issue.

Una especificación dice qué verificar. Un plan, opcional, dice cómo. Una tarea la construye. Un testing dice que se verificó.

Especificación ──► Plan (opcional) ──► Tarea     (cadena de diseño)
      │
      └──────────► Testing → Accepted / Rejected  (verificación)

Bug fuera de una capability ···► Capability afectada   (informativo)

Todo ocurre dentro de una capability, cuya página se lee así de una sola vez: requisitos, realización, pruebas.

La Cadena de Diseño

Un plan tiene como padre una especificación, una tarea tiene como padre un plan o una especificación. Los bugs y las especificaciones no tienen padre. Tres niveles como máximo, sin subtareas.

• El padre es opcional: una tarea sin padre es válida.
• Padre e hijo siempre están en la misma capability.
• Eliminar un plan hace subir sus tareas a la especificación. Una especificación que aún tiene hijos no se puede eliminar.

En la ficha de una especificación ves sus planes, luego las tareas bajo cada plan y luego las tareas vinculadas directamente, cada una con su estado. También ves las tareas terminadas sobre el total y la realización de la especificación: Not started, In progress o Done, calculada a partir de sus tareas.

La generación asistida mantiene la cadena por ti: el plan generado desde una especificación tiene esa especificación como padre, y las tareas generadas desde un plan tienen ese plan como padre.

Las Pruebas que Verifican una Especificación

Un testing puede indicar qué issue Verifies: una especificación o un bug de su capability. El vínculo es opcional, un testing siempre puede cubrir toda la capability.

• La ficha de una especificación lista los testings que la verifican, con su estado (aceptado o no), y ofrece Add a test.
• En la página de la capability, cada especificación indica su número de pruebas, o No test yet.
• El widget de huecos de cobertura del panel del tester lista las especificaciones activas sin ningún testing.

Una especificación cuenta como probada en cuanto un testing la señala, aceptado o no. Su estado de redacción o su realización nunca cuentan como cobertura: solo cuentan los testings.

Para que el vínculo siga siendo cierto, una issue verificada por al menos un testing no se puede eliminar, no puede salir de la capability de sus pruebas y no se puede cambiar, mediante la API, a un tipo no verificable. El mensaje indica el número de pruebas afectadas.

Bugs Tras la Entrega: Concerns

Un bug encontrado tras la entrega no puede volver a la capability entregada: tomaría su release, ya pasada, y contaría en su progreso. Se queda sin capability y declara la capability que Concerns.

• El vínculo no tiene efecto sobre la release del bug, ni sobre el progreso, la carga, la fase o la capacidad de la capability.
• La página de la capability lista estas issues aparte, en Concerned issues, con tipo, estado y release.
• Un bug que afecta a una capability puede ser verificado por un testing de esa capability: así se escribe la prueba de no regresión de un bug posterior a la entrega.
• Una issue nunca tiene a la vez una capability y una capability afectada. Elegir una capability vacía el otro campo.

Dónde Aparecen los Vínculos

Las issues y testings existentes no tienen ningún vínculo hasta que lo establezcas: Sinra nunca adivina un vínculo a partir de nombres o fechas.