Cuando los requisitos de un proyecto cambian "sobre la marcha" y no tiene a mano los medios para monitorear la implementación de cada requisito individual por característica o módulo, surge la pregunta: ¿cómo analizar la cobertura? Una de las herramientas que nuestro equipo de control de calidad utiliza en tales proyectos es la matriz de trazabilidad.
Por el momento, hemos estado usando matrices por más de 2.5 años. Durante este tiempo, pudimos evaluar las ventajas de esta herramienta, así como adaptarla a nuestro proyecto.
¿Qué es una matriz de trazabilidad?
Por definición, la matriz de trazabilidad es una tabla bidimensional que contiene la correspondencia de los requisitos funcionales del producto (requisitos funcionales) y los casos de prueba preparados (casos de prueba).
En la intersección de la fila y columna correspondiente, se coloca una marca que indica que este requisito está cubierto por este caso de prueba.
Por lo tanto, la tabla muestra visualmente dos parámetros:
- la presencia en el sistema de requisitos que aún no están cubiertos (si el requisito no tiene una sola intersección con casos de prueba (condición suficiente);
- ¿Hay pruebas excesivas en el sistema si los requisitos tienen varias intersecciones (una condición necesaria)?
En nuestro proyecto, utilizamos matrices de trazabilidad no solo para evaluar la cobertura, sino también para determinar la relación entre las tareas de desarrollo, los requisitos y los artefactos de prueba.
Por lo tanto, la matriz tiene la forma de una tabla, cada una de las cuales contiene:
- número y descripción de la tarea de desarrollo de la tarea de seguimiento;
- bloque lógico al que pertenece la tarea (opcional);
- requisito atómico o criterios de aceptación;
- prioridad
- número y descripción del artefacto de prueba correspondiente.
Como utilizamos el rastreador de tareas Jira, Zephyr by Jira para la documentación de la prueba y el sistema de gestión de requisitos de Confluence, todas las entidades están sincronizadas y esta trazabilidad nos permite:
- visualizar el estado actual de implementación;
- descomponer los requisitos en más atómicos y estructurarlos;
- para monitorear si hay requisitos para los cuales el desarrollo aún no está planificado (pase de implementación);
- supervisar si el requisito se implementa actualmente;
- supervisar si el requisito está cubierto por un caso de prueba (omitiendo la prueba);
- Visualice la priorización de requisitos.
Opciones de relación en la matriz de trazabilidad
Los requisitos vinculantes y los casos de prueba pueden ser:
- 1 a 1 (requisito atómico, que está cubierto por un caso de prueba, este caso de prueba cubre solo este requisito);
- 1 a n (un requisito que está cubierto por varios casos de prueba, estos casos de prueba cubren solo este requisito);
- n a n (un requisito que está cubierto por varios casos de prueba, estos casos de prueba cubren este y otros requisitos).
En cuanto al último punto, quiero señalar que
- cuando un requisito en la matriz de trazabilidad está cubierto por varias pruebas, esto puede indicar la redundancia de las pruebas. En este caso, es necesario analizar qué tan atómico es el requisito.
- si al realizar todos los casos de prueba nos aseguramos de que la cobertura sea completa y los casos de prueba en sí no se duplican entre sí, esto no será una prueba excesiva.
Tenemos casos en el proyecto donde un requisito está cubierto por varias pruebas y una prueba puede cubrir varios requisitos (conexiones "1 a n" y "n a n").
Especificidad de la estimación de cobertura utilizando matrices de trazabilidad
Si utilizamos la métrica "relación entre el número de requisitos y el número de artefactos de prueba" para evaluar la cobertura, entonces las relaciones en la matriz deberían ser "1 a 1" y los requisitos deberían descomponerse al máximo.
Un ejemplo Tenemos un requisito no atómico: "El usuario debe poder modificar y formatear la carta en un editor de texto". Un caso de prueba obviamente no será suficiente, pero si solo un artefacto está vinculado en la matriz, visualmente habrá una idea de que el requisito está cubierto.
Por lo tanto, es mejor:
- dividir este requisito en la matriz en funciones atómicas separadas de un editor de texto;
- escribir un criterio de aceptación para cada función;
- crear un artefacto de prueba para cada criterio;
- Si una lista de verificación puede cubrir varios requisitos atómicos, no puede hacer una fragmentación excesiva, ahorrando recursos.
Con la falta de recursos para una descomposición máxima, puede usar requisitos no atómicos, pero para cubrir cada uno de ellos necesita crear varios artefactos de prueba.
En este caso, los casos de prueba y las listas de verificación para cada requisito no atómico se compilan a la vez, es decir, cada requisito en la matriz está completamente cubierto por artefactos o no está cubierto en absoluto.
Al compilar las matrices, es aconsejable cumplir con la recomendación de que la descomposición de cada requisito en una matriz única debe ser aproximadamente igual, es decir, una tabla no debe contener requisitos, algunos de los cuales requieren 5 casos de prueba, y la primera parte.
La puntuación de cobertura en este caso se calcula por separado para cada matriz.
Dado que la documentación de nuestro proyecto puede tener un aspecto diferente para cada característica, e incluso una descripción de una característica puede contener UML, diagramas, diagramas de casos de usuarios y transiciones, y el proyecto contiene más de 40 funcionalidades voluminosas, decidimos desarrollar una matriz separada para cada módulo o característica para que No pierdas ninguna de las ventajas de esta herramienta.
El puntaje de cobertura también se calcula por separado para cada módulo o característica.
Con este enfoque, podemos utilizar la métrica descrita anteriormente: "la cantidad de requisitos para la cantidad de artefactos de prueba". Incluso si tenemos 1 a n, n a n conexiones, tenemos varios componentes, cada uno de los cuales se puede utilizar en varios módulos. Los requisitos y criterios de aceptación se describen en cada matriz, y se utiliza un artefacto de prueba.
Nuestras matrices también se almacenan en el sistema de gestión de requisitos de Confluence: cada matriz se ubica con la estructura como una página secundaria de la función para la que se desarrolló. Además, todas las matrices se recopilan en una página por conveniencia para evaluar la cobertura de toda la aplicación.
Crear y mantener una matriz
La creación de una matriz está incluida en nuestro flujo de trabajo en tareas de análisis.
Cuando recibimos información sobre una nueva función, el analista de nuestro equipo crea una tarea en el rastreador de tareas y, junto con el propietario del producto, trabaja como parte de esta tarea por parte del cliente. En el proceso de recopilación y estructuración de requisitos, todo el equipo realiza una revisión y hace preguntas adicionales. Cuando el cliente formula, documenta y confirma los requisitos, el líder del equipo de desarrollo crea tareas para el desarrollo de esta función, y el equipo de prueba puede comenzar a crear una matriz de rastreo.
Y aquí podemos distinguir las siguientes etapas de compilación de la Matriz de trazabilidad:
- Al principio, los requisitos se descomponen y priorizan por el control de calidad y / o el comando del propietario del producto. El resultado de este paso es una lista estructurada y priorizada de todos los requisitos para esta funcionalidad.
- La segunda etapa será la comunicación con el equipo de desarrollo y la asignación de tareas desde las tareas del rastreador hasta el desarrollo en la matriz a los requisitos relevantes. Como resultado, podemos rastrear la trazabilidad de los requisitos y tareas de desarrollo.
- La tercera etapa es el desarrollo de casos de prueba y listas de verificación.
Esta etapa se lleva a cabo antes de probar o durante la prueba de una tarea específica.
Si la funcionalidad es nueva y la interfaz cambiará, puede haber casos en los que los pasos se describan mejor inmediatamente antes de probar la tarea.
Si la funcionalidad de implementación es similar a una de las características existentes, entonces podemos comenzar a describir casos de prueba con pasos inmediatamente después de la revisión y descomposición de los requisitos. - Etapa 4: llenar la matriz con casos de prueba.
Con base en los resultados de todo el proceso, obtenemos tareas de desarrollo, casos de prueba para pruebas y una matriz de trazabilidad que los combina y los requisitos.
La tarea de desarrollar requisitos se está cerrando. - Etapa 5: mantenimiento de la matriz en el estado actual. Se deben hacer cambios a cualquier modificación a los requisitos. También debe tener en cuenta las relaciones de integración entre dos matrices que describen diferentes características o módulos, y al cambiar una, asegúrese de verificar si es necesario editar la segunda.
Dificultades para trabajar con la matriz de trazabilidad
- Actualización
La matriz será útil solo con la condición de que siempre se mantenga actualizada. En nuestro proyecto con requisitos que cambian con frecuencia, la actualización tomó mucho tiempo, pero si la matriz no se actualiza, se vuelve no solo inútil, sino también confusa.
Cómo decidir
Solucionó parcialmente el problema con un cambio frecuente en los requisitos y transfirió la etapa de creación de la matriz al momento en que los requisitos ya fueron revisados por el equipo y confirmados por el cliente.
El equipo decidió que el analista actualizará los requisitos no solo en la página con la descripción de las características, sino que también los encontrará y actualizará en la matriz, resaltando en un color diferente. Esto ayudó a todo el equipo a no perder los cambios, y al equipo de control de calidad en particular, para ver qué casos de prueba requieren actualización. - Recursos temporales
El proyecto puede tener un lanzamiento urgente y trabajar con nuevos requisitos al mismo tiempo, y todos los recursos de control de calidad se envían para pruebas y no funcionan con los requisitos. Por lo tanto, la deuda aumenta de acuerdo con la documentación de prueba.
Cómo decidir
Si todos los especialistas en control de calidad están ocupados probando tareas prioritarias, transferimos la creación de una matriz para una función específica. En la medida de lo posible, se transfiere al momento de probar la primera tarea para esta característica, y en este caso la matriz se llena con casos de prueba a medida que prueba las tareas en las que se implementa la característica.
El especialista en control de calidad establece el tiempo de evaluación no solo para escribir los casos de prueba en sí, sino también para desarrollar la matriz. - Eficiencia
Si el proyecto es pequeño y todos los requisitos se enmarcan en forma de ToR estructurados, y se crean casos de prueba para cada requisito a la vez, la matriz de trazabilidad en nuestro formulario solo duplicará la información y será un desperdicio de recursos.
Por lo tanto, debe usar la matriz estándar descrita en la definición para evaluar la cobertura.
Servicios
- La matriz le permite monitorear la implementación de los requisitos, realizar un seguimiento de que todos los requisitos se desarrollan y prueban y no falta nada.
- La matriz ayuda al equipo de control de calidad a rastrear si hay deuda en la documentación de prueba y qué requisitos específicos aún no están cubiertos por los casos de prueba.
- El analista y el equipo de control de calidad utilizan la herramienta para controlar los requisitos modificados.
- En el proyecto, las matrices de trazabilidad comenzaron a ser utilizadas no solo por nosotros, sino también por el propietario del producto por parte del cliente. Por lo tanto, se aseguraron de que todos los requisitos estén allí y sean correctos, y se rastrearon utilizando la matriz, que ya se ha implementado. Las matrices nos permitieron hacer que el proceso de desarrollo y prueba sea algo transparente.