Pruebas de software: ¿Qué es una matriz de trazabilidad y cuáles son algunos ejemplos?

¿Qué es una matriz de trazabilidad?

El enfoque de cualquier trabajo de prueba es y debe ser la máxima cobertura de prueba. Por cobertura, simplemente significa que necesitamos probar todo lo que hay que probar. El objetivo de cualquier proyecto de prueba debe ser una cobertura de prueba del 100%.

Para empezar, la Matriz de trazabilidad de requisitos establece una forma de asegurarnos de que verifiquemos el aspecto de la cobertura. Ayuda a crear una instantánea para identificar brechas de cobertura.

¿Cómo crear una matriz de trazabilidad?

Para estar con nosotros necesitamos saber exactamente qué es lo que necesita ser rastreado o rastreado.

Los probadores comienzan a escribir sus escenarios / objetivos de prueba y, finalmente, los casos de prueba basados ​​en algunos documentos de entrada: documento de requisitos comerciales, documento de especificación funcional y documento de diseño técnico (opcional).

Suponga que este es su caso de prueba / escenarios.

Una vez que lleguemos aquí, ahora sería un buen momento para comenzar a crear la matriz de trazabilidad de requisitos.

Personalmente, prefiero una hoja de Excel muy simple con columnas para cada documento que deseamos rastrear. Dado que los requisitos comerciales y los requisitos funcionales no están numerados de forma exclusiva, vamos a utilizar los números de sección en el documento para realizar un seguimiento. (Puede elegir realizar un seguimiento en función de los números de línea o de los puntos con viñetas, etc., según lo que tenga más sentido para su caso en particular).

Así es como se vería una matriz de trazabilidad simple para nuestro ejemplo:

El documento anterior establece un rastro entre el BRD y el FSD y, finalmente, los escenarios de prueba. Al crear un documento como este, podemos asegurarnos de que el equipo de prueba haya tenido en cuenta todos los aspectos de los requisitos iniciales para crear sus conjuntos de pruebas.

Descargue la plantilla de matriz de trazabilidad de requisitos aquí: Matriz de trazabilidad en formato Excel

Puntos importantes a tener en cuenta sobre la matriz de trazabilidad

Los siguientes son los puntos importantes a tener en cuenta sobre esta versión de la Matriz de trazabilidad:

1) También se muestra el estado de ejecución. Durante la ejecución, ofrece una instantánea consolidada de cómo progresa el trabajo.

2) Defectos: cuando esta columna se utiliza para establecer la trazabilidad hacia atrás, podemos decir que la funcionalidad “Nuevo usuario” es la más defectuosa. En lugar de informar que los casos de prueba fallaron, TM proporciona una transparencia de vuelta al requisito comercial que tiene la mayoría de los defectos, por lo que muestra la calidad de la carcasa en términos de lo que el cliente desea.

3) Como un paso más, puede codificar con color la identificación del defecto para representar sus estados. Por ejemplo, la identificación del defecto en rojo puede significar que todavía está abierto, en verde puede significar que está cerrado. Cuando se hace esto, el TM funciona como un informe de verificación de estado que muestra el estado de los defectos correspondientes a cierta funcionalidad BRD o FSD que se está abriendo o cerrando.

4) Si hay un documento de diseño técnico o casos de uso o cualquier otro artefacto que le gustaría rastrear, siempre puede expandir el documento creado anteriormente para satisfacer sus necesidades agregando columnas adicionales.

En resumen, una matriz de trazabilidad de requisitos ayuda a:

1. Asegurando una cobertura de prueba del 100%
2. Mostrando inconsistencias de requisitos / documentos
3. Mostrar el estado general de defecto / ejecución con foco en los requisitos del negocio.
4. Si un determinado requisito comercial y / o funcional cambiara, un TM ayuda a estimar o analizar el impacto en el trabajo del equipo de control de calidad en términos de revisión / reelaboración en los casos de prueba.

Adicionalmente,

1. Un TM no es una herramienta específica de prueba manual, también se puede utilizar para proyectos de automatización. Para un proyecto de automatización, el ID del caso de prueba puede indicar el nombre del script de prueba de automatización.
2. Tampoco es una herramienta que pueda ser utilizada solo por los QA. El equipo de desarrollo puede usar lo mismo para asignar los requisitos de BRD / FSD a bloques / unidades / condiciones de código creado para asegurarse de que se desarrollen todos los requisitos.
3. Las herramientas de gestión de pruebas como HP ALM vienen con la función de trazabilidad incorporada.

Un punto importante a tener en cuenta es que, la forma en que mantiene y actualiza su matriz de Tractabilidad determina la efectividad de su uso. Si no se actualiza con frecuencia o se actualiza incorrectamente, la herramienta es una carga en lugar de ser una ayuda y crea la impresión de que la herramienta por sí misma no merece ser utilizada.

La trazabilidad no es solo para proyectos DO-178. También puede usarlo de manera informal para mejorar su proceso de desarrollo. En resumen, la trazabilidad te ayuda a decidir si has recordado todo.

• La trazabilidad desde las necesidades del cliente (también llamadas requisitos por algunas personas) hasta aspectos del diseño puede decirle qué partes de su diseño están motivadas por las necesidades del usuario. Puede ayudarlo a priorizar la implementación para satisfacer la mayoría de las necesidades lo antes posible. Puede ayudarlo a eliminar las necesidades de los usuarios que ha olvidado y los fragmentos de diseño innecesarios que no están motivados por las necesidades del usuario. Puede ayudarlo a evaluar diseños alternativos para ver cuál satisface la mayoría de las necesidades.
• La trazabilidad desde el diseño hasta la implementación le indica qué partes de la implementación forman parte de un aspecto específico del diseño e indirectamente qué partes de la implementación satisfacen las necesidades de cada usuario. Como se indicó anteriormente, esto le permite priorizar los bits de la implementación, encontrar los bits faltantes de diseño y los bits de implementación no motivados.
• La trazabilidad a través de las pruebas hace todas las mismas cosas, aunque generalmente se usa para priorizar la escritura de la prueba y decirle si ha olvidado probar algo, o si sus pruebas son delgadas en un área en particular, volviendo a la implementación, el diseño o el usuario necesariamente.

A veces tiene un poco de implementación que intuitivamente sabe que debe ser parte de su sistema, pero no se remonta a la necesidad del usuario. Esto sirve como un control de la integridad de su análisis de necesidades al señalar algo que se ha perdido. Si se rasca la cabeza y aún no puede pensar en la necesidad del usuario que se satisface con un poco de diseño, puede anular su intuición sobre la importancia de un poco de diseño.

Al calificar la importancia relativa de cada necesidad del usuario, una matriz de trazabilidad le informa automáticamente la importancia de los bits de diseño, implementación y código de prueba, lo que le permite priorizar para entregar el mayor valor lo antes posible. Esta es una técnica muy poderosa. Las necesidades de los usuarios “descubiertos” del párrafo anterior pueden calificarse como altas o bajas, lo que le da más información sobre la priorización.

Los equipos de desarrollo y sus gerentes discuten sin cesar sobre la importancia de la mantenibilidad y la calidad. Una matriz de trazabilidad con necesidades de usuario priorizadas termina esos argumentos al decirle exactamente cuán importantes son estas cosas según las necesidades del usuario.

La construcción de matrices de trazabilidad es una herramienta sofisticada que requiere disciplina para ejercer correctamente. No es fácil para equipos o personas sin experiencia, pero se mejora rápidamente una vez que lo intenta.

Quality Function Deployment es una herramienta gráfica que se puede utilizar para realizar análisis de trazabilidad. Hay software para ayudar con la creación de gráficos QFD. QFD es una herramienta que puede ser ridículamente usada en exceso. Algunos libros abogan por literalmente docenas de matrices. Sin embargo, puede hacer un QFD muy simple que rastrea las necesidades del usuario para diseñar y obtener muchos beneficios. El American Supplier Institute solía ofrecer clases de capacitación en QFD. También hay consultores por ahí. Existen otros tipos de herramientas de trazabilidad en el mercado, y los consultores en los que participaron.

La matriz de trazabilidad es un mapeo entre un requisito comercial a su requisito funcional correspondiente hasta los casos de prueba correspondientes.
Si falla un caso de prueba, la trazabilidad ayuda a determinar la funcionalidad correspondiente fácilmente.
También ayuda a garantizar que se prueben todos los requisitos.
Dos tipos 1) Matriz de trazabilidad hacia adelante 2) Matriz de trazabilidad hacia atrás.

¿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 (compilación correcta del producto): simplemente 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.

Además de los puntos en la excelente respuesta de Alastairs, hay un uso que no se menciona que es permitir una correlación, a través de requisitos, entre casos de prueba y módulos / funciones de código. En sistemas altamente rastreables como los desarrollados de acuerdo con DO-178, puede rastrear desde una prueba fallida o un conjunto de pruebas hasta los requisitos que están validando y volver al código que está intentando implementar El comportamiento requerido. Esto es extremadamente valioso en sistemas complejos, ya que permite a los desarrolladores localizar rápidamente el código que debe analizarse para abordar las fallas de prueba; también ayuda a identificar elementos de especificación deficientes e implementaciones de prueba defectuosas al permitir el comportamiento que se está probando rápidamente . Desafortunadamente, algunos tipos de administración también intentarán usarlo para asignar la culpa, ya que el X% del código defectuoso fue desarrollado por un individuo / equipo determinado; a menudo se ignora que esto podría deberse a que no es tan bueno o podría ser que es porque son la (s) estrella (s) que obtienen los bits difíciles de hacer.

La matriz de trazabilidad es una herramienta o metodología para conectar los requisitos empresariales / funcionales con casos de prueba. Esto también puede extenderse al código (dependiendo de las herramientas de desarrollo / administración que use), pero mi experiencia se centra más en los requisitos y casos de prueba.

El propósito es asegurar que todos los requisitos estén cubiertos por los casos de prueba, pudiendo “rastrear” un caso de prueba, incluidos los resultados esperados y reales, directamente de regreso al requisito individual que cubre.

El siguiente será un ejemplo muy básico:

Requisito 1.0: el usuario puede finalizar la sesión cuando usa el mouse para hacer clic en el ícono X

Caso de prueba 1.0.a: el usuario hace clic en el icono X

1.0.a resultado esperado: la sesión ha finalizado

Los requisitos individuales pueden tener muchos casos de prueba asociados (1.0.a, 1.0.b, 1.0.c).

Los analistas de calidad profesionales deben ser hábiles para construir estas matrices y pueden ayudar a los analistas de negocios a desarrollar convenciones de nomenclatura efectivas.

Espero que ayude.

En las pruebas de software, hay muchos módulos que debe probar. La trazabilidad mateix se usa solo para referir el módulo exacto. Supongamos que hay un proyecto complejo. Desde la fecha de inicio de la prueba, día a día, sus datos de prueba aumentan. Al final de la prueba (o suponga que ha cubierto aproximadamente la mitad de los casos de prueba), se dio cuenta de que hay algún cambio en el módulo x. Booom … ¿cómo podría ubicar dónde está exactamente el cambio y cuántos más casos de prueba se requieren para cubrir el área? Aquí se introduce el concepto de trazabilidad mateix.

Para mantener el registro exacto, se utiliza la matriz de trazabilidad. Con la ayuda de este documento, podríamos referir exactamente el área afectada que requiere una nueva prueba (o cualquier otra metodología de prueba).

Algo que aún no he mencionado es que las matrices de trazabilidad son vitales para realizar análisis de impacto de cambio. ¿Desea modificar, eliminar o agregar algunos requisitos nuevos? Para planificar adecuadamente ese cambio, debe analizar los efectos secundarios de hacerlo en sus actividades de desarrollo y verificación, a través de todo su sistema. Si no tiene una buena trazabilidad bidireccional, no puede hacerlo de manera efectiva.

En un contexto DO-178, las autoridades de aviación requerirán que clasifique los cambios posteriores a la aprobación como mayores o menores en función de su análisis de los rastros. Usarán esto para establecer su nivel de participación y mejor retendrá el agua.

La Matriz de trazabilidad de requisitos es el proceso de preparación de enlaces entre los requisitos del usuario y todas las iniciativas que tome para cumplir con los requisitos. Crear matriz de trazabilidad de requisitos es la primera etapa del proceso de prueba.

Requerimientos de trazabilidad matriz

• Todos los requisitos de software.
• Codificación de software
• Especificación de diseño de software
• Planificación de prueba

Con la ayuda de la Matriz de trazabilidad de requisitos, el equipo de gestión de proyectos sabrá qué parte del código se refiere a los requisitos del cliente. A través de la Matriz de trazabilidad de requisitos, el equipo de prueba llega a saber qué tipo de casos de prueba deben preparar. La matriz de trazabilidad de requisitos es la parte de la fase de gestión de requisitos del ciclo de vida de desarrollo de software .

Con la ayuda de la matriz de requisitos, se capturan los requisitos del usuario y del sistema. En un solo documento, se capturan todos los requisitos para facilitar el proceso. La matriz de trazabilidad de requisitos se utiliza para preparar la relación de los requisitos con el desarrollo, el diseño, las pruebas y la versión final del software. Si existe alguna posibilidad de cambio en los requisitos, eso también se registra en RTM. Este documento es muy importante para el seguimiento del tiempo del proyecto, la gestión de riesgos y la gestión de cambios. El efecto posterior al cambio también se puede mantener con la ayuda de esta matriz.

La matriz de trazabilidad de requisitos es como una tabla completa que consta de análisis de riesgos, tipo de requisito, descripción de requisitos, especificación de diseño, casos de prueba de unidad, casos de prueba de integración, casos de prueba del sistema, casos de prueba de aceptación del usuario y algunos otros componentes. La forma de la documentación varía de una compañía a otra, pero pocas cosas básicas siempre estarán disponibles.

Es un intento de demostrar que los requisitos tienen una cobertura de caso de prueba (sistema) adecuada. En general, un requisito se asigna a muchos casos de prueba, sin embargo, un caso de prueba puede exponer aspectos de requisitos múltiples, por lo tanto, en casi todos los casos de sistemas complejos, se trata de una relación de muchos a muchos. La matriz de trazabilidad, en su forma más simple, está diseñada para demostrar la cobertura del caso de prueba (al menos adecuada) e iluminar las brechas potenciales en su régimen de prueba. También ayuda a identificar casos de prueba que cubren muchos aspectos de los requisitos; puede considerarlos como casos de prueba de alto valor que brindan una buena cobertura del requisito general cuando los ejecuta, por lo que es ideal para las pruebas de regresión (como ejemplo).

Nota: también existen técnicas paralelas para mapear los requisitos de los casos de prueba de unidades y componentes, sin embargo, para el resto de esta respuesta, me centraré principalmente en las pruebas del sistema.

El concepto de requisitos de mapeo para casos de prueba a menudo se puede usar como una ayuda de diseño. Los casos de prueba, debido a que describen con gran detalle cómo probar cada aspecto del producto, a menudo tienen mayor mérito técnico que los requisitos mismos. Los requisitos tienen una perspectiva del Cliente, mientras que los casos de prueba los traducen a una perspectiva de ingeniería. Entonces, si un ingeniero de diseño lee la especificación y también lee los casos de prueba, puede proporcionar información al diseñador / codificador sobre cómo diseñar e implementar el producto de manera eficiente con el menor número de pasos en falso. Este proceso puede parecer un sacrilegio para quienes creen firmemente en la “prueba de caja negra”, sin embargo, la prueba de caja negra en un producto complejo es extremadamente ineficiente y, a veces, ineficaz.

Por lo general, cuando administro un producto, veo la documentación (y otras entregas) como persistente o transitoria. Un documento persistente es aquel que proporciona información valiosa sobre el producto durante todo el ciclo de vida de un producto; puede considerarlos como entregas finales. Su atributo clave es que vale la pena mantenerlos y archivarlos. Todo lo demás es transitorio, en última instancia desechable, y debe tratarse como tal. Generalmente considero los casos de prueba y la matriz de trazabilidad como dos de los entregables finales clave.

Debo decir que también he desarrollado un “sistema de ponderación” que me permite compilar pruebas de unidad, regresión, integración y sistema eficientes. Este enfoque me permite analizar la contribución que cada caso de prueba hace a las diversas fases de la prueba; en cierto sentido, ¡esta es una matriz de trazabilidad en tres dimensiones!

Finalmente, uso diagramas de matriz de trazabilidad cuando hablo con la gerencia. El problema es (y perdone mi cinismo) que los gerentes de nivel medio necesitan ver cuántos casos de prueba se han ejecutado (lo llaman porcentaje completo), mientras que en muchos casos los ingenieros y la gerencia de primera línea ejecutarán muchas pruebas sin valor para cumplir con las curvas de porcentaje completo anticipadas. Sin embargo, esto puede significar que están descuidando los casos de prueba de alto valor (y a menudo bastante retorcidos) que son realmente valiosos para el proyecto y la entrega final. Por lo tanto, la matriz de trazabilidad es una herramienta que utilizo para impresionar en la administración el verdadero valor de las pruebas que realizamos semana a semana.

Una matriz de trazabilidad es una herramienta de gestión de culpa utilizada por los probadores para mantener la presión de encontrar errores en un entorno autoritario a un nivel tolerable.

Quienes solicitan su uso hacen los siguientes supuestos:

1. Existen dos conjuntos de cosas que son importantes sobre el desarrollo de software: requisitos y pruebas.
2. Estos conjuntos se pueden conocer y articular en su totalidad en un momento arbitrario antes de la creación del software.
3. Cada requisito se puede verificar ejecutando una o más pruebas escritas.
4. Cada prueba se relaciona con uno o más requisitos escritos.
5. El conjunto completo de relaciones puede documentarse.

Los intentos de hacer que estas condiciones sean reales dan como resultado un documento de requisitos, un conjunto de casos de prueba y una matriz de trazabilidad que señala qué requisito existe para verificar cada prueba. La matriz no puede ser más que una hoja de cálculo con dos columnas: la primera que contiene el ID de requisito y la segunda que contiene todos los ID de casos de prueba relacionados.

La utilidad práctica de tal disposición es nula, al menos para escribir código y encontrar errores. El propósito de todo esto es dar influencia a varios departamentos para que puedan obtener lo que quieren y golpearse mutuamente cuando no lo obtienen.

*********************

Una metodología ágil, donde las pruebas = el código = el requisito, funciona mucho mejor. Las historias son el requisito. Las pruebas unitarias son el requisito, indicado como código. Las pruebas de aceptación son el requisito, establecido como comportamiento observable del producto. Luego, el código se escribe, pasa las pruebas, cumple simultáneamente con los requisitos y se libera inmediatamente para el consumo.

Hola,

La Matriz de trazabilidad de requisitos (RTM) es una tabla (principalmente una hoja de cálculo) que muestra si cada requisito tiene un caso / casos de prueba respectivos para asegurarse de que el requisito esté cubierto para la prueba.

El siguiente artículo le dará información detallada sobre cómo crear RTM y una muestra gratuita de RTM para descargar

Cómo crear la matriz de trazabilidad de requisitos (RTM): muestra gratis para descargar – opencodez

Espero que esto ayude !

Matriz de trazabilidad de requisitos (RTM)

Cuando el requerimiento del usuario con casos de prueba mapea y rastrea en forma de documento. La razón principal de la matriz de trazabilidad de requisitos es ver que todos los casos de prueba están cubiertos para que no falte ninguna funcionalidad durante la prueba. Sobre todo cubría toda la funcionalidad de una aplicación.

Visite aquí para ver el artículo completo: Cómo crear la Matriz de trazabilidad de requisitos

Gracias,
Tecnologías Oodles

¿Para qué tipo de aplicación?

Nosotros (uTest) compartimos constantemente la matriz de prueba en nuestros blogs y hemos incluido algunos en nuestros libros blancos: http://www.utest.com/free-custom …

iOS y Android son probablemente los más solicitados.
iOS App Matrix WP: http://www.utest.com/landing-int …
Aplicación de Android Matrix WP: http://www.utest.com/landing-int …

RTM o matriz de trazabilidad de requisitos asegura que todos los requisitos estén cubiertos y que haya al menos uno o más casos de prueba para cada requisito.