Según avanzamos por el proceso de fabricación de software, nos apoyaremos en pruebas a diversos niveles para mantener la confianza en el producto final. A continuación os presentamos estos Modelos de Pruebas Software y sus distintos niveles utilizando un modelo de representación en capas, porque …

Las cebollas están hechas de capas sucesivas,
siendo cada capa más potente e intensa que la anterior.
Además, las cebollas -a veces- nos hacen llorar.

Las actividades de construcción y las de pruebas software deben de convivir armoniosamente. Una concepción aislada del «Testing» no es productiva. Por tanto, se requieren planteamientos de pruebas acordes a los diversos ciclos de vida de desarrollo.

Así en un ciclo de vida del tipo modelo en V o secuencial, típicamente buscaremos relacionar los niveles de construcción con los niveles de pruebas de componentes, integración, sistema y aceptación.

Si por el contrario optamos por modelos de construcción iterativos (o incrementales), como los modelos de desarrollo ágil por ejemplo, aplicaremos al resultado de cada iteración niveles de pruebas software (componentes, integración, sistema y aceptación) acordes a su tamaño y alcance. La naturaleza incremental del proceso nos llevará de forma natural a potenciar aspectos como regresión o automatización a todos los niveles (por pura supervivencia ;).

El modelo de capas de cebolla para los Niveles de Pruebas Software (según ISTQB) que hemos elaborado para vosotros permite visualizar el volumen potencial de cada nivel, su interdependencia y su criticidad (o sabor).

La capa más externa nos presenta las Pruebas Unitarias. Suelen ser unas pruebas relativamente pequeñas y numerosas. Se tiende a envolver con ellas buena parte de los objetos, clases o módulos construidos. Se pueden incluir pruebas funcionales y no funcionales, lanzándose típicamente con acceso al código en construcción y con el apoyo de entornos de desarrollo. Suele dar lugar a la detección de defectos que son corregidos rápidamente por el desarrollador.

El siguiente nivel, Pruebas de Componentes, es muy similar al de Pruebas Unitarias. La complejidad de los elementos a probar nos marca si existe diferencia entre ellas y el aislamiento del resto de elementos a probar nos marca la frontera con la siguiente capa.

Llegamos a una capa más sabrosa, el nivel de Pruebas de Integración. Estas pruebas suelen ser realizadas por el equipo de desarrollo y permiten comprobar que los componentes del software interactúan correctamente, entre sí y con otras partes del sistema (como sistemas operativos, sistemas de archivos o hardware). El foco de las pruebas es la interacción. Saltan las primeras chispas.

Avanzamos, el nivel de Pruebas de Sistema es la siguiente capa de nuestra cebolla. Cosa seria, algunas lágrimas están casi garantizadas. El comportamiento global del producto construido hasta el momento será la referencia. que concretaremos en un Plan de Pruebas para este nivel (si queremos acabar las pruebas algún día). Cualquier aspecto de interés deberá ser retado: riesgos,  requisitos, casos de uso, interacciones, configuraciones, rendimientos, comentarios del cliente en whatsapp, etc. Además, esta actividad la suele realizar un equipo de pruebas independiente que, típicamente, utiliza un entorno de pruebas que sea lo más similar posible al entorno de producción.

¡Ya tenemos un SISTEMA funcionando!

Llega el momento de la verdad. Estamos en el corazón de nuestro modelo y aquí nos esperan las experiencias más intensas. Toca mirar cara a cara a los usuarios del sistema, buscamos su confianza. El nivel de Pruebas de Aceptación nos revelará si cumplimos con sus expectativas, ¿será dulce o amargo este último bocado?

Las habituales implicaciones contractuales derivadas del resultado de las Pruebas de Aceptación han dado lugar a una amplia variedad de matices en la forma de materializarlas: pruebas de aceptación de usuario, pruebas de aceptación operativa o pruebas de cumplimiento regulatorio son algunos ejemplo. Es más, si se realizan en casa del fabricante se denominan pruebas Alpha (todavía queda un atisbo de sospecha) mientras que, si son en casa del comprador, se denominan pruebas Beta (¡por fin!).

Gracias al modelo de Capas de Pruebas Software presentado,
podemos visualizar cómo organizarnos
para llegar hasta la esencia de toda actividad de fabricación de software,
la satisfacción de las expectativas del cliente.

En todo caso, quizás os hayáis preguntado: PERO, ¿cómo se sabe si estamos construyendo el producto correctamente? (es decir, conforme a sus especificaciones) o ¿estamos satisfaciendo las expectativas del cliente? Estas inquietudes, que nos acompañan durante todo el ciclo de vida, nos permiten introducir un último concepto:

Los Tipos de Pruebas Software.  ¿Los conocéis?

• Blog Pruebas del Software, por Javier Zapata S.
• Herramientas para pruebas software (entre otros) en el blog de Javier Garzás.
• Creating the onion model, artículo de Mike Clayton.

Algunas referencias interesantes sobre este tema, que hemos consultado, son: