¿Qué es la trazabilidad?

¿Cómo se asegura la cobertura de la prueba? – Una de las preguntas de entrevista más comunes. Después de todo, el cliente no quiere omitir nada en las pruebas y luego enfrenta la vergüenza de la falla del usuario final en la aplicación en vivo. ¿Cuál es la base de la cobertura de prueba? ¡Sí! Requisitos: funcionales, técnicos y no funcionales, cada requisito debe ser probado. ¿Qué sucede si por error el equipo de prueba pasó por alto uno de los requisitos y no escribió casos de prueba para ello? ¿Cómo se enterará un administrador de pruebas o un cliente? ¡’Matriz de trazabilidad de requisitos’!

¿Qué es una matriz de trazabilidad?

Una matriz de trazabilidad es un documento que correlaciona dos documentos de línea de base (sección a sección) que requieren una relación de muchos a muchos para verificar la integridad de la relación, es decir, para garantizar que todo lo relacionado con ambos documentos esté relacionado de alguna manera.

Propósito : Identificación de cualquier cosa que no esté vinculada en dos documentos, que requieren un análisis más detallado.

Rastreando los requisitos

Aplicando el concepto de matriz de trazabilidad a los requisitos, es decir, uno de los documentos de referencia siempre será ‘Especificación de requisitos’. En términos simples, la matriz de trazabilidad de requisitos (comúnmente conocida como RTM) es una herramienta (principalmente documento de Excel) que rastrea los requisitos durante todo el proceso de validación, es decir, análisis de requisitos, diseño de pruebas, ejecución de pruebas y fase de cierre.

¿Cómo?

Mapeo simple : ID de requisitos >> ID de escenarios de prueba >> ID de casos de prueba >> ID de defectos (incluido el estado final)

Propósito : rastrear que todos los requisitos están cubiertos en Diseño de prueba, Ejecución de prueba y cierre.

Tipos de matriz de trazabilidad

  • Trazabilidad hacia adelante (Creación del producto correcto): ID de requisitos >> ID de escenarios de prueba >> ID de casos de prueba >> ID de defectos.
  • Trazabilidad hacia atrás o hacia atrás (creación correcta del producto): solo invierta el orden: ID de defectos >> ID de casos de prueba (todos) >> ID de escenario de prueba (todos) >> ID de requisito. Propósito: para garantizar que todo lo desarrollado tenga un requisito correspondiente, ¡nada más!

Como habrás adivinado, RTM es generalmente bidireccional: analiza los agujeros de bucle (no vinculados) en cada paso (requisito, escenarios de prueba, casos de prueba y defectos)

El propósito

  • Confianza del cliente: Lo primero y más importante es construir la confianza del cliente de que el producto está siendo desarrollado y probado según los requisitos.
  • Garantizar la cobertura de la prueba: Todos los requisitos se han cubierto en Diseño y ejecución de pruebas. El objetivo de cualquier proyecto de prueba debe ser una cobertura de prueba del 100%. RTM ayuda está descubriendo las brechas.
  • Seguimiento de solicitudes de cambio: mantenidas durante todo el ciclo de vida de la versión, los cambios en los requisitos también se registran y se rastrean en el RTM.
  • Gestión de riesgos: garantizar que cada requisito sea comprobable y eventualmente probado
  • Sugerir mejoras o funcionalidades faltantes
  • Tareas del proyecto: ayuda en la creación de una solicitud de propuesta, especificación de requisitos de software, varios documentos entregables y tareas del plan del proyecto.
  • Mantenibilidad: cualquier cambio en los requisitos se puede rastrear hasta el cambio requerido correspondiente en el diseño de prueba
  • Cumplir con el alcance: utilizando la trazabilidad inversa, asegúrese de que no se realicen pruebas adicionales que no tengan el requisito correspondiente
  • Destaque cualquier requisito ambiguo
  • Calidad del producto: la cobertura de prueba y el estado del defecto correspondiente le da confianza al cliente sobre la calidad del producto
  • Estimación de solicitudes de cambio: con RTM, un administrador de pruebas puede medir fácilmente el impacto y la cantidad de trabajo requerido si se modifica alguno de los requisitos.
  • Calidad de los componentes: medir qué componentes en el sistema ‘eran’ más defectuosos (la mayoría de los defectos), otra forma de resaltar las áreas de alto riesgo que requieren pruebas exhaustivas.

Pasos

  1. Reciba el documento de especificación de requisitos
  2. Enumere todos los requisitos en un Excel (ID y descripción requeridos)
  3. Agregue una columna que especifique si el requisito es comprobable o no: resalte para el equipo comercial si algo NO es comprobable
  4. Desarrollar escenarios de prueba y casos de prueba
  5. Actualice el RTM, es decir, ID de requisitos (todos) >> ID de escenarios de prueba (todos) >> ID de casos de prueba (todos)
  6. RTM está listo!
  7. Verifique el RTM para identificar brechas de cobertura: cualquier requisito, escenario de prueba o caso que no esté relacionado con al menos otro elemento
  8. Ejecute todos los casos de prueba y aumente los defectos (si los hay)
  9. Actualice el RTM, es decir, ID de requisitos >> ID de escenarios de prueba >> ID de casos de prueba >> ID de defectos
  10. Vuelva a probar todos los defectos (una vez corregidos)
  11. Actualice el RTM, es decir, ID de requisitos >> ID de escenarios de prueba >> ID de casos de prueba >> ID de defectos (incluyendo prioridad, gravedad y estado)
  12. Finalice y comparta el RTM, incluida cualquier información (teniendo en cuenta el propósito mencionado anteriormente)
  13. Mantener el RTM para cualquier cambio adicional y evaluación posterior

Personalmente prefiero una hoja de Excel muy simple con columnas limitadas (para mantenimiento).

El formato

La Matriz de trazabilidad de requisitos se puede crear y mantener en una herramienta automatizada (como HP QC), en una hoja de cálculo de Excel o en una tabla de MS Word.

  • ID de requisito
  • Descripción del requisito
  • Comprobable (S / N)
  • Módulo / Submódulo
  • ID de escenarios
  • ID de casos de prueba
  • ID de defectos
  • Estado
  • Observaciones

Punteros clave

  • En primer lugar, RTM no es lo que piensan muchos de los evaluadores, es decir, inútil si se mantiene adecuadamente en un formato simple, RTM es una herramienta valiosa que rastrea uno de los aspectos de prueba más importantes ‘La cobertura de prueba’. La forma en que el equipo de prueba mantiene y actualiza el RTM determina la efectividad de su uso.
  • RTM debe crearse a partir de la fase de requisitos en sí. Se vuelve engorroso después de completar el diseño de prueba y ya tiene numerosos escenarios y casos de prueba.
  • RTM, si se prepara durante la fase de requisitos, puede referenciarse en la fase de diseño de prueba posterior para evitar pasar por alto cualquier requisito.
  • No se detenga en Requisito: mapeo de casos de prueba. Extrapolarlo hasta los defectos para obtener los máximos beneficios.
  • Mantenibilidad: la tarea más descuidada pero importante. El RTM debe actualizarse para cada requisito o cambio de diseño de prueba.
  • Actuar: No solo cree el RTM y consérvelo. Actúe en los pasos 3, 7, 12 y 13 como se mencionó anteriormente para obtener los beneficios
  • RTM garantiza que los requisitos y los casos de prueba se desglosen a nivel modular, lo que garantiza una mejor comprensión y facilidad de mantenimiento.
  • RTM debe almacenarse en un sistema de control de revisión para evitar actualizaciones simultáneas
  • Algunas herramientas de gestión de pruebas como HP Quality Center (ahora ALM) proporcionan la generación automática de RTM según los requisitos, casos de prueba y defectos ingresados.
  • No existe un formato estándar de la industria para RTM. Siéntase libre de ajustar (agregar o eliminar columnas) el formato para incluir / excluir múltiples documentos como especificaciones de requisitos, diseño técnico, casos de uso, etc.
  • RTM puede ampliarse para incluir tanto casos de prueba manual como scripts de prueba automatizados (cobertura de automatización)
  • RTM se utiliza en las fases completas del ciclo de vida de las pruebas de software: análisis de riesgos, análisis de requisitos, diseño de pruebas, ejecución de pruebas, gestión de defectos y cierre de pruebas.

Espero que este artículo haya ayudado a obtener la comprensión básica de la Matriz de trazabilidad de requisitos. ¿Entonces, Qué esperas? Comience a usar RTM diligentemente en su Proyecto de prueba.