Niveles de Prueba

Los niveles de Prueba considerados por ISTQB son 4:

1.- Pruebas de Componente

Comprueban el funcionamiento de módulos de software, programas, objetos, clases, etc. Por separado.

Pueden utilizarse “stubs”, controladores y simuladores.

Por lo general, los defectos se corrigen en el momento en que se detectan, sin gestionarlos formalmente.

Las pruebas unitarias caen típicamente en este nivel por lo que es común que el equipo de desarrollo se encargue de ellas.

  

2.-  Pruebas de Integración.

Prueban las interfaces entre los componentes, las interacciones con distintas partes de un mismo sistema (como el sistema operativo, el sistema de archivos y el hardware), y las interfaces entre varios sistemas.

Es muy útil conocer la arquitectura del sistema para diseñar pruebas de integración eficientes.

Las pruebas se deben de enfocar solo en la integración entre sí, no en la funcionalidad.

Las pruebas No Funcionales (por ejemplo, de Rendimiento) pueden ser validadas en este nivel de pruebas

Dependiendo de la naturaleza de la aplicación y la complejidad para probar las integraciones en este nivel de pruebas suelen participar tanto el área de desarrollo como el área de pruebas

 

 3.- Pruebas de Sistema

Deben de estar enfocadas a detectar fallas en el objetivo principal del sistema.

Se pueden incluir las pruebas basadas en riesgos o en requerimientos, procesos de negocio, casos de uso u otras descripciones de alto nivel.

En estas pruebas se deben incluir pruebas Funcionales y No funcionales.

Típicamente realizadas por el área de pruebas.

En la siguiente imagen vemos 3 engranes, digamos que corresponden al funcionamiento interno de un reloj.

Basado en esta imagen las pruebas de Componente corresponden a las hechas para verificar que cada uno de los 3 engranes mostrados esta correctamente construido, las pruebas de Integración corresponden a verificar que estos 3 engranes funcionan juntos, en este caso tal vez confirmar que pueden girar sin problema al estar juntos.  Las pruebas de Sistema tendran que ver con verificar que el Reloj es el que funciona para dar la hora, no atrasarse o adelantarse, etc, etc.

4.- Pruebas de Aceptación.

El objetivo principal es verificar la idoneidad de uso del sistema por parte de los usuarios finales/comerciales.

Los criterios de aceptación deben establecerse en el momento en que las partes aceptan contraer dicho contrato.

Pruebas alfa: se llevan a cabo en la organización de desarrollo, pero no las realiza el equipo de desarrollo.

Pruebas beta: también conocidas como “pruebas de campo”, las realizan los clientes en sus propias instalaciones.

Por su naturaleza son normalmente ejecutadas por el usuario final aunque cabe señalar que en muchas ocasiones con cierto apoyo o guía de parte del área de pruebas.