Estructura del plan de prueba

Cada plan de prueba tendrá una estructura jerárquica, mediante la cual se intentará cubrir al máximo posible las funcionalidades presentes en el sistema que se quiere testear. Esta estructura jerárquica constará de varios niveles en donde la relación de cada nivel con el nivel siguiente será de 1 --> n. Lo niveles de los que se puede componer un plan de pruebas son:

• Sistema. El sistema es la aplicación en sí sobre la cual se hacen las pruebas definidas en el plan.
• Subsistema. El subsistema asocia grupos funcionales relacionados, de forma que éste debe funcionar de forma que sea lo más independiente posible al resto del sistema.
• Módulo. Cada módulo agrupa funcionalidades concretas las cuales integradas con las de otros módulos implementan la lógica del subsistema.
• Casos de uso. Los casos de uso describen un uso del sistema y cómo éste interactúa con el usuario. Los casos de uso deben responder a la pregunta de qué hace cada módulo desde el punto de vista del usuario.
• Casos de prueba. Mediante los casos de prueba se indica la sucesión de pasos a seguir por el usuario al utilizar una funcionalidad del caso de uso correspondiente. Estos pasos deberán de ser definidos de forma unívoca. Los casos de prueba se definirán para conjuntos de datos entrada-salida genéricos (no particularizados en tipos de datos, formatos, tamaño de ficheros, etc).
• Escenarios. Cada caso de prueba se podrá probar con varios juegos de datos de entrada-salida, a cada conjunto de datos que particularizan un caso de preuba se le llama escenario. Las entradas de un escenario serán los datos necesarios para ejecutar el caso de prueba correspondiente y los datos de salida serán los resultados esperados de dicho caso de prueba.

Esquema estructura jerárquica

Se tiene que tener en cuenta que no en todos los casos deberán estar presentes todos los niveles, dependiendo de la complejidad del grupo de funcionalidades que se quiera probar con el plan de test a diseñar.

Ventajas del testeo en base a planes de pruebas

• Se tienen definidas las pruebas de forma escrita

  Tener redactadas las pruebas hace que sean repetibles por cualquier usuario o tester, ya que para ejecutar las pruebas solamente tendrá que seguir de forma ordenada los pasos que se detallan en cada prueba.

• Se identifican fácilmente las áreas de la aplicación que han sido testeadas y también las que no

  La estructura jerárquica de cada conjunto de pruebas hace que sea muy simple identificar las funcionalidades que se han testeado. Por tanto también se podrá saber de forma rápida qué funcionalidades son las que tienen más probabilidad de contener errores o malcomportamientos.

• Monitorización del estado de la aplicación

  Los resultados de las ejecuciones de las pruebas se guardan junto con el plan de pruebas. Analizando el contenido de estos resultados puede hacer una estimación de la estabilidad del conjunto de la aplicación, y de cuáles son sus zonas de debilidad y riesgo.

• Se identifican errores que son consecuencia de correcciones de otros errores

  Una vez se corrige un error en el código puede suceder que esta corrección perjudique otra zona de la aplicación. Al pasar las mismas pruebas build tras build compilado, se tiene más probabilidad de encontrar este tipo de errores.