Pruebas de software: documentación
La documentación de prueba implica la documentación de los artefactos que deben desarrollarse antes o durante la prueba del Software.
La documentación para las pruebas de software ayuda a estimar el esfuerzo de prueba requerido, la cobertura de la prueba, el seguimiento / seguimiento de los requisitos, etc. Esta sección describe algunos de los artefactos documentados de uso común relacionados con las pruebas de software, tales como:
- Plan de prueba
- Escenario de prueba
- Caso de prueba
- Matriz de trazabilidad
Plan de prueba
Un plan de prueba describe la estrategia que se utilizará para probar una aplicación, los recursos que se utilizarán, el entorno de prueba en el que se realizarán las pruebas y las limitaciones de las pruebas y el calendario de actividades de prueba. Por lo general, el líder del equipo de garantía de calidad será responsable de redactar un plan de prueba.
Un plan de prueba incluye lo siguiente:
- Introducción al documento del plan de prueba
- Supuestos al probar la aplicación
- Lista de casos de prueba incluidos en la prueba de la aplicación
- Lista de características a probar
- Qué tipo de enfoque utilizar al probar el software
- Lista de entregables que deben probarse
- Los recursos asignados para probar la aplicación
- Cualquier riesgo involucrado durante el proceso de prueba
- Un cronograma de tareas e hitos a alcanzar.
Escenario de prueba
Es una declaración de una línea que notifica qué área de la aplicación se probará. Los escenarios de prueba se utilizan para garantizar que todos los flujos de proceso se prueben de un extremo a otro. Un área particular de una aplicación puede tener desde un escenario de prueba hasta unos cientos de escenarios, dependiendo de la magnitud y complejidad de la aplicación.
Los términos 'escenario de prueba' y 'casos de prueba' se usan indistintamente, sin embargo, un escenario de prueba tiene varios pasos, mientras que un caso de prueba tiene un solo paso. Visto desde esta perspectiva, los escenarios de prueba son casos de prueba, pero incluyen varios casos de prueba y la secuencia en la que deben ejecutarse. Aparte de esto, cada prueba depende del resultado de la prueba anterior.
Caso de prueba
Los casos de prueba implican un conjunto de pasos, condiciones y entradas que se pueden usar mientras se realizan tareas de prueba. La intención principal de esta actividad es asegurar si un software pasa o falla en términos de su funcionalidad y otros aspectos. Hay muchos tipos de casos de prueba, como casos de prueba funcionales, negativos, de error, lógicos, casos de prueba físicos, casos de prueba de IU, etc.
Además, los casos de prueba se escriben para realizar un seguimiento de la cobertura de prueba de un software. Generalmente, no hay plantillas formales que se puedan usar durante la redacción de casos de prueba. Sin embargo, los siguientes componentes siempre están disponibles e incluidos en cada caso de prueba:
- ID de caso de prueba
- Módulo de producto
- Version del producto
- Revisión histórica
- Purpose
- Assumptions
- Pre-conditions
- Steps
- Gastos esperados
- Resultado real
- Post-conditions
Muchos casos de prueba pueden derivarse de un único escenario de prueba. Además, a veces se escriben varios casos de prueba para un solo software que se conocen colectivamente como conjuntos de pruebas.
Matriz de trazabilidad
La Matriz de trazabilidad (también conocida como Matriz de trazabilidad de requisitos - RTM) es una tabla que se utiliza para rastrear los requisitos durante el ciclo de vida del desarrollo de software. Se puede utilizar para el seguimiento hacia adelante (es decir, de los requisitos al diseño o la codificación) o hacia atrás (es decir, de la codificación a los requisitos). Hay muchas plantillas definidas por el usuario para RTM.
Cada requisito del documento RTM está vinculado con su caso de prueba asociado para que las pruebas se puedan realizar según los requisitos mencionados. Además, Bug ID también está incluido y vinculado con sus requisitos asociados y caso de prueba. Los principales objetivos de esta matriz son:
- Asegúrese de que el software se desarrolle según los requisitos mencionados.
- Ayuda a encontrar la causa raíz de cualquier error.
- Ayuda a rastrear los documentos desarrollados durante las diferentes fases de SDLC.