Según el Comité Internacional de Calificación en Pruebas de Software (ISTQB) hay cuatro niveles a cumplir para llevar a cabo un buen aseguramiento de la calidad. Los niveles de pruebas que se contempla son:
- Pruebas de componentes,
- de integración,
- Pruebas de sistema,
- de aceptación.
Esos niveles se caracterizan por unos atributos específicos, que los diferencia.
Objetivos concretos
Base de prueba
Objetos de prueba
Defectos y fallos típicos
Enfoques y responsabilidades específicas
En esta ocasión, vamos a hablar del primer nivel, «Pruebas de componente«. En este nivel se evalúa la calidad de una unidad o módulo del sistema de información, que se puede probar de forma individual. Independientemente del nivel en el que nos encontremos tenemos una tipología de pruebas que hay que ir cumpliendo en cada nivel. En el post: Tipos de pruebas para el aseguramiento de la calidad encontrarás información al respecto.
Índice de contenidos
Objetivos de las pruebas de componentes
La importancia de las pruebas de componentes en el aseguramiento de la calidad
Estas pruebas se realizan para asegurar que un módulo o unidad especifica del sistema cumple con su funcionalidad, características no funcionales o propiedades tal y como se ha diseñado. Se pretende dar confianza en la calidad de esa pieza del sistema, reduciendo los riegos y encontrando defectos desde el comienzo. Se prevé que esos fallos causen incidencias más graves en niveles de pruebas más elevados.
Para su ejecución se suele utilizar herramientas de apoyo. La utilización de objetos simulados, controladores, código usado como sustituto (Stubs) o virtualización de servicios son algunas de ellas.
Desarrollo incrementales e iterativos
Si nos encontramos en entornos ágiles, donde se suceden actualizaciones del producto por nuevas funcionalidades, esté tipo de pruebas toma un caracter crítico.
En este sentido, nuestro mejor aliado será la automatización. Será una ventaja competitiva tener una batería de pruebas de regresión automatizadas que nos asegure la calidad de nuestro sistema. Tras los últimos cambios aplicados (estas actualizaciones o mejoras), tenemos que estar seguros de que no se ha roto nada.
Base de las pruebas, nuestras herramientas para trabajar
Para el desarrollo de este nivel de pruebas necesitamos disponer de las especificaciones del componente o módulo, el diseño detallado del mismo, el modelo de datos y por último el código.
Es de vital importancia tener una documentación completa (aunque a la vez, clara y concisa) que nos permita conocer los requerimientos del sistema. Esto no permitirá tener un punto de partida y también será nuestro apoyo a lo largo del ciclo de vida del proyecto. Esta información debe estar actualizado y sea veraz, de ahí la importancia de llevar a cabo una buena trazabilidad entre requerimientos del proyecto y casos de uso, entre otros.
Objeto a asegurar su calidad
Como he mencionado al comienzo, se van a probar módulos, unidades o componentes concretos, clases, código y estructura de datos o módulos de BBDD.
Defectos y fallas que se suelen encontrar en el primer nivel
Se suelen detectar funcionalidades que no cumplen con las especificaciones, problemas en el flujo de datos, errores en el código o lógica incorrecta. Este tipo de fallas, se suelen solventar rápidamente. Es común que los propios desarrolladores sean quién las detectan y no requieren de procesos extra por parte de otro miembro del equipo.
Enfoques y responsabilidades especificas de las pruebas de componentes
El nivel de pruebas de componente son realizadas, en gran medida, por el propio usuario que ha desarrollado la funcionalidad o código. El usuario suele alternar tareas de desarrollo y de testing para verificar el correcto funcionamiento de sus tareas antes de darla por válidas.
En entornos de desarrollo ágiles, es frecuente realizar estas tareas en orden inverso: Primero se desarrolla la prueba o batería de pruebas que debe validar la funcionalidad; y posteriormente sé desarrollada el código. Esta técnica es llamada Desarrollo guiado por pruebas (TDD) y se apoya, nuevamente, en la automatización para ser más óptimos.
Si deseas conocer las ventajas del desarrollo guiado por pruebas, puedes acceder aquí.
Conclusión
Para alcanzar un aseguramiento de la calidad óptimo, es necesario cumplir todos los niveles de pruebas. Es recomendable disponer de un conjunto de pruebas mínimo para cada nivel, que asegure la calidad del sistema. En las pruebas de componentes, nos aseguramos que las piezas funcionan correctamente antes del siguiente paso, detectar que la integración de esas piezas es correcta.
El no detectar incidencias en un nivel bajo, donde las fallas son fáciles de solventar, puede ocasionar un elevando costo de resolución en niveles posteriores, o mucho peor, si es detectado una vez está en producción.
Si te ha gustado este post y quieres saber un poco más de calidad, suscríbete a mi blog o déjame un comentario y conversamos al respecto.
