T5. Documentación de Testing

Para que NO nos sirve la documentación de testing?

• Estimar el esfuerzo necesario del testing

• Estimar la cobertura de las pruebas

• Realizar el seguimiento de los recursos

• Ejecutar los casos de prueba

La principal razón de la creación de documentación de pruebas es reducir o eliminar cualquier incertidumbre sobre las actividades de pruebas.

• Verdad

• Falso

• No se sabe

• Depende de las circunstancias

Una razon para crear escenarios de pruebas es que garantiza que el software funcione para los casos de uso más comunes.

• Verdad

• Falso

• No se sabe

• Depende de las circunstancias

Conviene crear escenarios de pruebas cuando La aplicación bajo prueba es complicada, inestable y hay una crisis de tiempo en el proyecto

• Verdad

• Falso

• No se sabe

• Depende de las circunstancias

Un caso de prueba contiene pasos de prueba, datos de prueba, condiciones previas, condiciones posteriores desarrolladas para un escenario de prueba específico para verificar cualquier requisito.

• Verdad

• Falso

• No se sabe

• Depende de las circunstancias

Los casos de prueba son bastante vagos y cubren una amplia gama de posibilidades. Los escenarios de prueba tratan de ser mas específico

• Verdad

• Falso

• No se sabe

• Depende de las circunstancias

La Matriz de Trazabilidad sirve para:

• Documento que correlaciona los escenarios con los casos de prueba

• Documentar los requerimientos de un sistema y probarlos

• Realizar un seguimiento de los requisitos y comprobar que se cumplen.

• Trazar el camino de ejecución de cada caso de prueba

El objetivo de la Matriz de Trazabilidad de Requerimientos es:

• Graficar el seguimiento de los casos de prueba

• Validar que los requisitos se verifiquen a través de casos de prueba, tal que ninguna funcionalidad quede sin verificar.

• Saber el camino de ejecución de los casos de prueba

• Mapear los requerimientos con los escenarios de prueba

Cual NO es una de las ventajas de la Matriz de Trazabilidad de requerimientos

• Confirma el 100% de cobertura de pruebas

• Resalta cualquier falta de requerimientos o inconsistencia

• Descubrir la mayor cantidad de bugs con ayuda de los casos de prueba

• Ayuda a estimar el impacto en el trabajo del equipo de QA con respecto a volver a trabajar en los casos de prueba.