how create requirements traceability matrix
¿Qué es la Matriz de trazabilidad de requisitos (RTM) en las pruebas de software: guía paso a paso para crear la Matriz de trazabilidad con ejemplos y plantilla de muestra?
El tutorial de hoy trata sobre una importante herramienta de control de calidad, que se simplifica demasiado (se pasa por alto) o se enfatiza demasiado, es decir, Matriz de trazabilidad (TM).
La mayoría de las veces, la elaboración, revisión o intercambio de una matriz de trazabilidad no es uno de los entregables primarios del proceso de garantía de calidad, por lo que no se concentra principalmente en él, lo que provoca un énfasis insuficiente. Por el contrario, algunos clientes esperan que una MT revele facetas trascendentales sobre su producto (bajo prueba) y están decepcionados.
“Cuando se usa correctamente, una matriz de trazabilidad puede ser su GPS para su viaje de control de calidad”.
Como es una práctica general en STH , veremos los aspectos 'Qué' y 'Cómo' de una MT en este artículo.
Lo que vas a aprender:
- ¿Qué es la matriz de trazabilidad de requisitos?
- Cobertura de prueba y trazabilidad de requisitos
- Cómo crear una matriz de trazabilidad de requisitos
¿Qué es la matriz de trazabilidad de requisitos?
En Matriz de trazabilidad de requisitos o RTM, configuramos un proceso de documentación de los vínculos entre los requisitos del usuario propuestos por el cliente y el sistema que se está construyendo. En resumen, es un documento de alto nivel para mapear y rastrear los requisitos del usuario con casos de prueba para garantizar que para todos y cada uno de los requisitos se alcance el nivel adecuado de pruebas.
El proceso para revisar todos los casos de prueba que se definen para cualquier requisito se denomina Trazabilidad. La trazabilidad nos permite determinar qué requisitos generaron la mayor cantidad de defectos durante el proceso de prueba.
El enfoque de cualquier compromiso de prueba es y debe ser la máxima cobertura de prueba. Por cobertura, simplemente significa que tenemos que probar todo lo que hay que probar. El objetivo de cualquier proyecto de prueba debe ser una cobertura de prueba del 100%.
La Matriz de Trazabilidad de Requisitos establece una forma de asegurarnos de que realizamos controles en el aspecto de cobertura. Ayuda a crear una instantánea para identificar las brechas de cobertura. En resumen, también se pueden denominar métricas que determinan el número de casos de prueba ejecutados, aprobados, fallidos o bloqueados, etc. para cada requisito.
¿Por qué se requiere la trazabilidad de requisitos?
La Matriz de trazabilidad de requisitos ayuda a vincular los requisitos, Casos de prueba y defectos con precisión. Toda la aplicación se prueba mediante la trazabilidad de requisitos ( Prueba de extremo a extremo de una aplicación).
fusionar ordenar c ++ recursivo
La trazabilidad de requisitos asegura una buena 'calidad' de la aplicación, ya que se prueban todas las funciones. Control de calidad se puede lograr a medida que el software se prueba para escenarios imprevistos con defectos mínimos y se satisfacen todos los requisitos funcionales y no funcionales.
La Matriz de Trazabilidad de Requisitos ayuda a que la aplicación de software se pruebe en el tiempo estipulado, el alcance del proyecto está bien determinado y su implementación se logra de acuerdo con los requisitos y necesidades del cliente y el costo del proyecto está bien controlado.
Las fugas de defectos se evitan ya que se prueba una aplicación completa para cumplir con sus requisitos.
Tipos de matriz de trazabilidad
Trazabilidad hacia adelante
En 'Requisitos de trazabilidad hacia adelante' para los casos de prueba. Garantiza que el proyecto progrese según la dirección deseada y que todos los requisitos se prueben a fondo.
Trazabilidad hacia atrás
Los casos de prueba se asignan con los requisitos en 'Trazabilidad hacia atrás'. Su objetivo principal es garantizar que el producto actual que se está desarrollando esté en el camino correcto. También ayuda a determinar que no se agregan funcionalidades adicionales no especificadas y, por lo tanto, el alcance del proyecto se ve afectado.
Trazabilidad bidireccional
(Adelante + Atrás): Una matriz de buena trazabilidad tiene referencias desde casos de prueba a requisitos y viceversa (requisitos a casos de prueba). Esto se conoce como trazabilidad 'bidireccional'. Garantiza que todos los casos de prueba se puedan rastrear hasta los requisitos y que todos y cada uno de los requisitos especificados tengan casos de prueba precisos y válidos para ellos.
Ejemplos de RTM
# 1) Requisito comercial
BR1 : La opción de escritura de correos electrónicos debe estar disponible.
Escenario de prueba (especificación técnica) para BR1
TS1 : Se proporciona la opción Redactar correo.
Casos de prueba:
Caso de prueba 1 (TS1.TC1) : La opción Redactar correo está habilitada y funciona correctamente.
Caso de prueba 2 (TS1.TC2) : La opción Redactar correo está deshabilitada.
# 2) Defectos
Después de ejecutar los casos de prueba, si se encuentra algún defecto, también se puede enumerar y mapear con los requisitos comerciales, escenarios de prueba y casos de prueba.
Por ejemplo, Si TS1.TC1 falla, es decir, la opción Redactar correo, aunque habilitada, no funciona correctamente, se puede registrar un defecto. Suponga que el número de ID de defecto generado automáticamente o asignado manualmente es D01, luego se puede asignar con los números BR1, TS1 y TS1.TC1.
Por tanto, todos los requisitos se pueden representar en formato de tabla.
Requisito de negocio # | Escenario de prueba n.º | Caso de prueba # | Defectos # |
---|---|---|---|
BR1 | TS1 | TS1.TC1 TS1.TC2 | D01 |
BR2 | TS2 | TS2.TC1 TS2, TC2 TS2.TC3 | D02 D03 |
BR3 | TS3 | TS1.TC1 TS2.TC1 TS3.TC1 TS3.TC2 | NULO |
Cobertura de prueba y trazabilidad de requisitos
¿Qué es la cobertura de la prueba?
La cobertura de prueba indica qué requisitos de los clientes deben verificarse cuando comienza la fase de prueba. Cobertura de prueba es un término que determina si los casos de prueba se escriben y ejecutan para asegurarse de probar la aplicación de software por completo, de tal manera que se informen defectos mínimos o NIL.
¿Cómo lograr la cobertura de la prueba?
La cobertura de prueba máxima se puede lograr estableciendo una buena 'Trazabilidad de requisitos'.
- Mapeo de todos los defectos internos a los casos de prueba diseñados
- Mapeo de todos los defectos reportados por el cliente (CRD) a casos de prueba individuales para el futuro conjunto de pruebas de regresión
Tipos de especificaciones de requisitos
# 1) Requisitos comerciales
Los requisitos reales de los clientes se enumeran en un documento conocido como Documento de requisitos comerciales (BRS) . Este BRS es una lista de requisitos de alto nivel obtenida minuciosamente, después de una breve interacción con el cliente.
Por lo general, lo preparan 'Analistas de negocios' o el 'Arquitecto' del proyecto (según la organización o la estructura del proyecto). El documento 'Especificaciones de requisitos de software' (SRS) se deriva de BRS.
# 2) Documento de especificación de requisitos de software (SRS)
Es un documento detallado que contiene todos los detalles meticulosos de todos los requisitos funcionales y no funcionales. Este SRS es la base para diseñar y desarrollar aplicaciones de software.
# 3) Documentos de requisitos del proyecto (PRD)
El PRD es un documento de referencia para todos los miembros del equipo en un proyecto para decirles exactamente qué debe hacer un producto. Se puede dividir en secciones como Propósito del producto, Características del producto, Criterios de lanzamiento y Presupuesto y programación del proyecto.
# 4) Documento de caso de uso
Es el documento que ayuda a diseñar e implementar el software según las necesidades comerciales. Traza las interacciones entre un actor y un evento con un rol que debe realizarse para lograr un objetivo. Es una descripción detallada paso a paso de cómo se debe realizar una tarea.
Por ejemplo,
Actor: Cliente
Papel: Descárgate el juego
La descarga del juego se realizó correctamente.
Los casos de uso también pueden ser una parte incluida en el documento SRS según el proceso de trabajo de la organización.
# 5) Documento de verificación de defectos
Está documentado que contiene todos los detalles relacionados con los defectos. El equipo puede mantener un documento de 'Verificación de defectos' para corregir y volver a probar los defectos. Los evaluadores pueden consultar el documento de 'Verificación de defectos', cuando quieran verificar si los defectos están arreglados o no, volver a probar los defectos en diferentes sistemas operativos, dispositivos, configuraciones de sistemas diferentes, etc.
El documento 'Verificación de defectos' es útil e importante cuando hay una fase dedicada a la corrección y verificación de defectos.
# 6) Historias de usuarios
La historia del usuario se utiliza principalmente en el desarrollo 'ágil' para describir una función de software desde la perspectiva del usuario final. Las historias de usuario definen los tipos de usuarios y de qué manera y por qué quieren una determinada característica. El requisito se simplifica creando historias de usuarios.
Actualmente, todas las industrias de software se están moviendo hacia el uso de User Stories y Agile Development y las herramientas de software correspondientes para registrar los requisitos.
Desafíos para la recopilación de requisitos
#1) Los Requisitos recopilados deben ser detallados, inequívocos, precisos y bien especificados. Pero hay NO medida adecuada para calcular estos detalles, falta de ambigüedad, precisión y especificaciones bien definidas que se necesitan para la recopilación de requisitos.
#2) La interpretación del 'Analista de negocios' o 'Propietario del producto', quien proporciona la información de los requisitos, es fundamental. Asimismo, el equipo que recibe la información debe plantear las aclaraciones adecuadas para comprender las expectativas de los grupos de interés.
La comprensión debe estar sincronizada tanto con las necesidades comerciales como con los esfuerzos reales necesarios para la implementación de la aplicación.
#3) La información también debe derivarse del punto de vista del usuario final.
#4) El estado de las partes interesadas tiene requisitos contradictorios o contradictorios en diferentes momentos.
#5) El punto de vista del usuario final no se considera debido a múltiples razones y otras partes interesadas piensan que comprenden 'completamente' lo que se requiere para un producto, lo que generalmente no es el caso.
#6) Falta de recursos de habilidades para la aplicación desarrollada.
#7) Cambios frecuentes de 'alcance' de aplicación o cambio de prioridad para los módulos.
#8) Requisitos omitidos, implícitos o indocumentados.
#9) Requisitos inconsistentes o vagos determinados por los clientes.
#10) La conclusión de todos los factores indicados anteriormente es que el 'éxito' o 'fracaso' de un proyecto depende considerablemente de un requisito.
Cómo puede ayudar la trazabilidad de requisitos
# 1) ¿Dónde se implementa un requisito?
Por ejemplo,
Requisito: Implemente la funcionalidad 'Redactar correo' en una aplicación de correo.
Implementación: En qué lugar de la página principal se debe colocar y acceder al botón 'Redactar correo'.
# 2) ¿Es necesario un requisito?
Por ejemplo,
Requisito: Implemente la funcionalidad 'Redactar correo' en una aplicación de correo solo para ciertos usuarios.
Implementación: Según los derechos de acceso del usuario, si la bandeja de entrada del correo electrónico es 'Solo lectura', en este caso no se requerirá el botón 'Redactar correo'.
# 3) ¿Cómo interpreto un requisito?
Por ejemplo,
Requisito: 'Redactar correo' Funcionalidad en una aplicación de correo con fuentes y archivos adjuntos.
Implementación: Cuando se hace clic en 'Redactar correo', ¿qué funciones deben proporcionarse?
- Cuerpo de texto para escribir correos electrónicos y editarlos en diferentes tipos de fuentes y también en negrita, cursiva, subrayarlos
- Tipos de archivos adjuntos (imágenes, documentos, otros correos electrónicos, etc.)
- Tamaño de los archivos adjuntos (tamaño máximo permitido)
Por lo tanto, los requisitos se dividen en sub-requisitos.
# 4) ¿Qué decisiones de diseño afectan la implementación de un requisito?
Por ejemplo,
Requisito: Todos los elementos 'Bandeja de entrada', 'Correo enviado', 'Borradores', 'Spam', 'Papelera', etc. deben estar claramente visibles.
Implementación: Los elementos que deben ser visibles deben mostrarse en formato 'Árbol' o formato 'Pestaña'.
# 5) ¿Están asignados todos los requisitos?
Por ejemplo,
servidor privado gratuito de world of warcraft
Requisito: Se proporciona la opción de correo 'Papelera'.
Implementación: Si se ha proporcionado la opción de correo 'Papelera', la opción 'Eliminar' correos electrónicos (requisito) debe implementarse inicialmente y debe funcionar correctamente. Si la opción de correo 'Eliminar' funciona correctamente, solo los correos electrónicos eliminados se recopilarán en la 'Papelera' y la implementación de la opción de correo 'Papelera' (requisito) tendrá sentido (será útil).
Ventajas de la cobertura de prueba y RTM
#1) La compilación desarrollada y probada tiene la funcionalidad requerida que satisface las necesidades y expectativas de los 'Clientes' / 'Usuarios'. El cliente debe conseguir lo que quiere. Sorprender al cliente con una aplicación que no hace lo que se espera que haga no es una experiencia satisfactoria para nadie.
#2) El producto final (Aplicación de software) desarrollado y entregado al cliente debe abarcar solo la funcionalidad que se necesita y se espera. Las características adicionales proporcionadas en la aplicación de software pueden parecer atractivas al principio hasta que haya una sobrecarga de tiempo, dinero y esfuerzo para desarrollarlas.
La característica adicional también puede convertirse en una fuente de defectos, que pueden causar problemas al cliente después de la instalación.
#3) La tarea inicial del desarrollador se define claramente, ya que trabajan primero en la implementación de los requisitos, que son de alta prioridad, según el requisito del cliente. Si los requisitos de alta prioridad del cliente se especifican claramente, entonces esos componentes de código se pueden desarrollar e implementar en primera prioridad.
Por lo tanto, se garantiza que las posibilidades de que el producto final se envíe al cliente cumplan con los requisitos más altos y se cumplan con el programa.
#4) Los probadores verifican primero la funcionalidad más importante implementada por los desarrolladores. Como la verificación (prueba) del componente de software prioritario se realiza primero, ayuda a determinar cuándo y si las primeras versiones del sistema están listas para ser lanzadas.
#5) Planes de prueba precisos, los casos de prueba se escriben y ejecutan que verifican que todos los requisitos de la aplicación se implementan correctamente. El mapeo de casos de prueba con los requisitos ayuda a garantizar que no se pierdan defectos importantes. Además, ayuda a implementar un producto de calidad según las expectativas del cliente.
#6) En caso de que haya una 'Solicitud de cambio' del cliente, todos los componentes de la aplicación que se ven afectados por la solicitud de cambio se modifican y no se pasa por alto nada. Esto mejora aún más al evaluar el impacto que tiene una solicitud de cambio en la aplicación de software.
#7) Una solicitud de cambio aparentemente simple podría implicar modificaciones que deben realizarse en varias partes de la aplicación. Es mejor sacar una conclusión sobre cuánto esfuerzo se requerirá antes de aceptar realizar el cambio.
Desafíos en la cobertura de la prueba
# 1) Buen canal de comunicación
Si hay cambios sugeridos por el Partes interesadas , lo mismo debe comunicarse a los equipos de Desarrollo y Pruebas en las fases anteriores del desarrollo. Sin esto a tiempo No se puede garantizar el desarrollo, las pruebas de aplicación y la captura / corrección de defectos.
# 2) Priorizar los escenarios de prueba es importante
Identificar cuáles son los escenarios de prueba de alta prioridad, complejos e importantes es una tarea difícil. Tratando de probar todos los Escenarios de prueba es una tarea casi inalcanzable. El objetivo de probar los escenarios debe ser muy claro desde el punto de vista comercial y del usuario final.
# 3) Implementación de procesos
El proceso de prueba debe estar claramente definido considerando factores como infraestructura técnica e implementaciones, habilidades del equipo, experiencias pasadas, estructuras organizacionales y procesos seguidos, estimaciones del proyecto relacionadas con el costo, tiempo y recursos y ubicación del equipo según las zonas horarias.
Una implementación uniforme del proceso considerando los factores mencionados asegura que todas las personas involucradas con el proyecto estén en la misma página. Esto ayuda a un flujo fluido de todos los procesos relacionados con el desarrollo de aplicaciones.
# 4) Disponibilidad de recursos
Los recursos son de dos tipos, probadores específicos de dominios especializados y las herramientas de prueba utilizadas por los probadores. Si los evaluadores tienen el conocimiento adecuado del dominio, pueden escribir e implementar escenarios de prueba y scripts efectivos. Para implementar estos escenarios y scripts, los evaluadores deben estar bien equipados con las 'Herramientas de prueba' adecuadas.
La buena implementación y la entrega a tiempo de la aplicación al cliente pueden garantizarse mediante el único evaluador calificado y las herramientas de prueba adecuadas.
# 5) Implementación efectiva de la estrategia de prueba
‘ Test Strategy 'en sí mismo es un tema de discusión amplio e independiente. Pero aquí para 'Cobertura de prueba', una implementación de estrategia de prueba efectiva asegura que la ' Calidad' de la aplicación es bien y es mantenido durante el período de tiempo en todas partes.
Una 'estrategia de prueba' eficaz juega un papel importante en la planificación anticipada para todo tipo de desafíos críticos, lo que ayuda aún más a desarrollar una mejor aplicación.
Cómo crear una matriz de trazabilidad de requisitos
Para estar con nosotros necesitamos saber exactamente qué es lo que se debe rastrear o rastrear.
Los evaluadores 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 especificaciones funcionales y documento de Diseño Técnico (opcional).
Supongamos que lo siguiente es nuestro Documento de requisitos comerciales (BRD): ( Descargue este BRD de muestra en formato excel )
(Haz click en cualquier imagen para hacerla mas grande)
A continuación se muestra nuestro Documento de Especificaciones Funcionales (FSD) basado en la interpretación del Documento de Requisitos de Negocio (BRD) y la adaptación del mismo a aplicaciones informáticas. Idealmente, todos los aspectos de FSD deben abordarse en el BRD. Pero en aras de la simplicidad, solo he utilizado los puntos 1 y 2.
Muestra FSD de BRD superior: ( Descargue este FSD de muestra en formato excel )
Nota : Los equipos de control de calidad no documentan el BRD ni el FSD. Somos meros consumidores de los documentos junto con los demás equipos de proyecto.
Basándonos en los dos documentos de entrada anteriores, como equipo de control de calidad, creamos la siguiente lista de escenarios de alto nivel para que probáramos.
Ejemplos de escenarios de prueba de los BRD y FSD anteriores: ( Descargar este archivo de escenarios de prueba de muestra )
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 única, vamos a utilizar los números de sección del documento para realizar un seguimiento.
(Puede elegir realizar un seguimiento según los números de línea o los números 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 seguimiento 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 pruebas ha tenido en cuenta todos los aspectos de los requisitos iniciales para crear sus conjuntos de pruebas.
Puedes dejarlo así. Sin embargo, para que sea más legible, prefiero incluir los nombres de las secciones. Esto mejorará la comprensión cuando este documento se comparta con el cliente o cualquier otro equipo.
El resultado es el siguiente:
Nuevamente, la elección de utilizar el formato anterior o el posterior es suya.
Esta es la versión preliminar de su TM pero, en general, no cumple su propósito cuando se detiene aquí. Se pueden obtener los máximos beneficios cuando se extrapola hasta los defectos.
¿Cuál no es uno de los tipos de elementos que se prueban durante las pruebas del sistema?
Veamos cómo.
Para cada escenario de prueba que se le ocurrió, tendrá al menos 1 o más casos de prueba. Por lo tanto, incluya otra columna cuando llegue allí y escriba los ID de los casos de prueba como se muestra a continuación:
En esta etapa, la Matriz de trazabilidad se puede utilizar para encontrar brechas. Por ejemplo, En la Matriz de trazabilidad anterior, verá que no hay casos de prueba escritos para la sección 1.2 de FSD.
Como regla general, los espacios vacíos en la Matriz de trazabilidad son áreas potenciales de investigación. Entonces, una brecha como esta puede significar una de las dos cosas:
- El equipo de prueba de alguna manera no ha tenido en cuenta la funcionalidad de 'Usuario existente'.
- La funcionalidad 'Usuario existente' se ha pospuesto para más adelante o se ha eliminado de los requisitos de funcionalidad de la aplicación. En este caso, la TM muestra una inconsistencia en el FSD o BRD, lo que significa que se debe realizar una actualización de los documentos FSD y / o BRD.
Si es el escenario 1, indicará los lugares donde el equipo de prueba debe trabajar un poco más para asegurar una cobertura del 100%.
En los escenarios 2, TM no solo muestra lagunas, sino que apunta a documentación incorrecta que necesita una corrección inmediata.
Ampliemos ahora la TM para incluir defectos y estado de ejecución de casos de prueba.
La siguiente versión de la matriz de trazabilidad generalmente se prepara durante o después de la ejecución de la prueba:
Descargue la plantilla Matriz de trazabilidad de requisitos:
=> Plantilla de matriz de trazabilidad en formato Excel
Puntos importantes a tener en cuenta
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 avanza el trabajo.
# 2) Defectos: Cuando esta columna se usa para establecer la trazabilidad hacia atrás, podemos decir que la funcionalidad de 'Nuevo usuario' es la más defectuosa. En lugar de informar que tal o cual casos de prueba fallaron, TM brinda transparencia al requisito comercial que tiene la mayoría de los defectos, mostrando así la Calidad en términos de lo que el cliente desea.
#3) Como paso adicional, puede codificar con colores el ID del defecto para representar sus estados. Por ejemplo, El ID de defecto en rojo puede significar que todavía está abierto, en verde puede significar que está cerrado. Cuando se hace esto, la TM funciona como un informe de verificación de estado que muestra el estado de los defectos correspondientes a una determinada 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, RTM ayuda a:
- Garantizar una cobertura de prueba del 100%
- Mostrando inconsistencias de requisitos / documentos
- Visualización del estado general de Defecto / Ejecución con un enfoque en los Requisitos comerciales.
- Si un determinado requisito comercial y / o funcional cambiara, una MT ayuda a estimar o analizar el impacto en el trabajo del equipo de control de calidad en términos de revisión / reelaboración de los casos de prueba.
Adicionalmente,
- Una matriz de trazabilidad no es una herramienta específica de pruebas manuales, sino que 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.
- Tampoco es una herramienta que pueda ser utilizada solo por los QA. El equipo de desarrollo puede usar lo mismo para mapear los requisitos de BRD / FSD a bloques / unidades / condiciones de código creado para asegurarse de que se desarrollen todos los requisitos.
- 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 quela forma en que mantiene y actualiza su Matriz de trazabilidad 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í sola no es digna de usarse.
Conclusión
La Matriz de Trazabilidad de Requisitos es el medio para mapa y rastreo todos los requisitos del cliente con los casos de prueba y defectos descubiertos. Es un documento único que tiene el propósito principal de que no se pierda ningún caso de prueba y, por lo tanto, todas las funciones de la aplicación están cubiertas y probadas.
Una buena 'Cobertura de prueba' que se planifica con anticipación evita tareas repetitivas en las fases de prueba y fugas de defectos. Un recuento alto de defectos indica que las pruebas se realizan bien y, por lo tanto, la 'calidad' de la aplicación está aumentando. De manera similar, un recuento de defectos muy bajo indica que las pruebas no se realizan hasta la marca y esto obstaculiza la 'calidad' de la aplicación de manera negativa.
Si la cobertura de la prueba se realiza a fondo, entonces se puede justificar un recuento bajo de defectos y este recuento de defectos se puede considerar como estadísticas de apoyo y no como una estadística primaria. La calidad de una aplicación se denomina 'buena' o 'satisfactoria' cuando se maximiza la cobertura de la prueba y se minimiza el número de defectos.
Sobre el Autor: Urmila P., miembro del equipo de STH, es una profesional de control de calidad con experiencia alta calidad pruebas y habilidades de seguimiento de problemas.
¿Ha creado una Matriz de Trazabilidad de Requisitos en sus proyectos? ¿Qué tan similar o diferente es de lo que hemos creado en este artículo? Comparta sus experiencias, comentarios, pensamientos y sugerencias sobre este artículo a través de sus comentarios.
Lectura recomendada
- Plantilla de plan de prueba de software de muestra con formato y contenido
- Cómo escribir un informe de resumen de prueba eficaz (Descarga de informe de muestra)
- Plantilla de caso de prueba de muestra con ejemplos de casos de prueba (Descargar)
- Plantilla de muestra para el informe de prueba de aceptación con ejemplos
- Cómo escribir un documento de estrategia de prueba (con una plantilla de estrategia de prueba de muestra)
- ¿Cómo probar la especificación de requisitos de software (SRS)?
- Las 20 mejores herramientas de gestión de requisitos (la lista completa)
- Las listas de verificación de pruebas de software de control de calidad (listas de verificación de muestra incluidas)