Concepto: Estrategia de prueba
En esta directriz se explica cómo desarrollar una estrategia de prueba cuyo objetivo sea describir el enfoque general y los objetivos de las tareas de prueba.
Relaciones
Descripción principal

Una estrategia para la parte de prueba de un proyecto describe el enfoque y los objetivos generales de las tareas de prueba. Incluye las fases de prueba (unidad, integración y sistema) que se deben seguir y las clases de pruebas (función, rendimiento, carga, tensión) que se deben realizar.

La estrategia define:

  • Herramientas y técnicas de prueba que se deben utilizar.
  • Qué criterios de satisfacción y terminación se utilizarán. Por ejemplo, los criterios pueden permitir que el software avance hasta la prueba de aceptación cuando se haya ejecutado satisfactoriamente el 95% de los guiones de prueba. Otro criterio es la cobertura de código. Este criterio puede ser, en un sistema de seguridad crítica, que las pruebas deben cubrir el 100% del código.
  • Los requisitos de recursos se ven afectados por consideraciones especiales, o tienen implicaciones de planificación, como:
  • probar todas las interfaces en sistemas externos
  • simular daño físico o amenaza a la seguridad

Algunas empresas tienen estrategias de prueba corporativas definidas; en este caso, su trabajo consiste en aplicar dichas estrategias al proyecto específico.

La dimensiones más importantes en torno a las cuales debe planear las tareas de prueba son:

  • ¿En qué iteración se encuentra y cuáles son los objetivos de dicha iteración?
  • ¿Qué fase de la prueba (prueba de unidad, prueba de integración, prueba del sistema) está realizando? Puede trabajar en todas las fases de prueba de una iteración.

Ahora observe cómo cambian las características de las tareas de prueba en función de dónde se encuentre en las dimensiones de prueba mencionadas previamente. Hay que tener en cuenta muchas características, por ejemplo, los recursos necesarios y el tiempo invertido; pero, en este punto, céntrese en lo importante para definir la estrategia de prueba, como:

  • tipos de prueba (funcional, de tensión, de volumen, de rendimiento, de utilización, de distribución, etc)
  • criterios de evaluación utilizados (cobertura de la prueba basada en código, cobertura de la prueba basada en requisitos, número de defectos, tiempo medio entre errores, etc.)
  • técnicas de prueba utilizadas (manuales y automáticas)

No existe ningún patrón general sobre cómo distribuir estos tipos de pruebas en los ciclos de prueba. Céntrese en tipos de pruebas diferentes en función del número de iteraciones, el tamaño de la iteración y la clase de proyecto que esté probando.

Verá que la fase de prueba del sistema se centra especialmente en asegurarse de que cubre todos los requisitos que se pueden probar expresados en términos de un conjunto de guiones de prueba. Esto significa que los criterios de terminación se centrarán en la cobertura de la prueba basada en requisitos. En las fases de prueba de integración y de unidad, verá que la cobertura de la prueba basada en código es un criterio de terminación más adecuado. La siguiente figura muestra cómo puede cambiar la utilización de estos dos tipos de medidas de cobertura de la prueba a medida que desarrolla iteraciones de software nuevas.

  • El plan de prueba deber definir conjuntos de criterios de terminación para las pruebas de unidad, de integración y del sistema.
  • Puede definir conjuntos diferentes de criterios de completitud para las iteraciones individuales.

Requisitos y áreas basadas en código de una imagen de tabla de pruebas

En su proyecto, considere la automatización de las pruebas lo máximo posible, específicamente la clase de pruebas que repite varias veces (pruebas de regresión). Recuerde que la creación y el mantenimiento de pruebas automatizadas cuesta tiempo y recursos. Todos los proyectos tienen siempre una parte de prueba manual. En la figura siguiente se ilustra cuándo y en qué fases de prueba se realizarán, seguramente, las pruebas manuales.

Tabla de pruebas con la imagen de las áreas de prueba manual encerradas en un círculo

Ejemplo

En las tablas siguientes se muestra cuándo se identifican los diferentes tipos de pruebas y se proporciona un ejemplo del criterio de terminación que se debe definir. La primera tabla muestra un proyecto MIS "típico".

Prueba de iteración Prueba del sistema Prueba de integración Prueba de unidad
Iteración 1 Prueba de rendimiento automatizada para todos los guiones de uso.
· Se han ejecutado todas las pruebas planeadas.
· Se han atendido todos los defectos de gravedad 1.
· Se han vuelto a ejecutar todas las pruebas planeadas y no se ha identificado ningún defecto de gravedad 1 nuevo.
Ninguna Prueba informal
Iteración 2 Pruebas de funcionalidad y rendimiento automatizadas para todos los guiones de uso nuevos y los anteriores como prueba de regresión.
· Se han ejecutado todas las pruebas planeadas.
· Se han atendido todos los defectos de gravedad 1 y 2.
· Se han vuelto a ejecutar todas las pruebas planeadas y no se ha identificado ningún defecto de gravedad 1 o 2 nuevo.
Ninguna Prueba informal
Iteración 3 Pruebas negativas y de funcionalidad automatizadas para todos los guiones de uso nuevos, y todas las anteriores como prueba de regresión; debe pasar el 95% de los guiones de prueba.
· Se han ejecutado todas las pruebas planeadas.
· Se han identificado todos los defectos de gravedad 1, 2 y 3.
Prueba automatizada, cobertura de código del 70%. Prueba informal
Iteración 4 Pruebas negativas y de funcionalidad automatizadas para todos los guiones de uso, prueba manual para todos los componentes que no están automatizados, y todas las anteriores como prueba de regresión. Debe pasar el 100% de los guiones de prueba.
· Se han ejecutado todas las pruebas planeadas.
· Se han atendido todos los defectos de gravedad 1, 2 y 3.
· Se han vuelto a ejecutar todas las pruebas planeadas y no se ha identificado ningún defecto de gravedad 1 o 2 nuevo.
Prueba automatizada, cobertura de código del 80%. Prueba informal

En la segunda tabla se muestran los tipos de criterios de prueba y terminación que se aplican a un sistema de seguridad crítica típico.

Prueba de iteración Prueba del sistema Prueba de integración Prueba de unidad
Iteración 1 Prueba de rendimiento automatizada para todos los guiones de uso; cobertura de guiones de prueba del 100%.
· Se han ejecutado todas las pruebas planeadas.
· Se han atendido todos los defectos de gravedad 1.
· Se han vuelto a ejecutar todas las pruebas planeadas y no se ha identificado ningún defecto nuevo.
Ninguna Ninguna
Iteración 2 Pruebas negativas, de funcionalidad y de rendimiento automatizadas para todos los guiones de uso; cobertura de guiones de prueba del 100%.
· Se han ejecutado todas las pruebas planeadas.
· Se han atendido todos los defectos de gravedad 1 o 2.
· Se han vuelto a ejecutar todas las pruebas planeadas y no se ha identificado ningún defecto nuevo.
Prueba de rendimiento automatizada Prueba informal
Iteración 3 Pruebas de documentación, de utilización negativa, de funcionalidad y de rendimiento automatizadas para todos los guiones de uso; cobertura de guiones de prueba del 100%.
· Se han ejecutado todas las pruebas planeadas.
· Se han atendido todos los defectos de gravedad 1, 2 y 3.
· Se han vuelto a ejecutar todas las pruebas planeadas y no se ha identificado ningún defecto nuevo.
Prueba de rendimiento automatizada y la anterior como prueba de regresión Prueba automatizada, cobertura de código del 70%
Iteración 4 Pruebas de documentación, de utilización negativa, de funcionalidad y de rendimiento automatizadas para todos los guiones de uso; cobertura de guiones de prueba del 100%.
· Se han ejecutado todas las pruebas planeadas.
· Se han atendido todos los defectos de gravedad 1, 2 y 3.
· Se han vuelto a ejecutar todas las pruebas planeadas y no se ha identificado ningún defecto.
Prueba de rendimiento automatizada y la anterior como prueba de regresión Prueba automatizada, cobertura de código del 80%