Para el aseguramiento de la calidad de un sistema de información, se pueden definir cuatro tipos de grupos de pruebas en función de los objetivos de las pruebas específicas, según el ISTQB.
Para la realización de un plan de pruebas que verifique el adecuado funcionamiento de un SI, se deben evaluar los siguientes parámetros: la integridad, exactitud, pertinencia, confiabilidad, eficiencia del rendimiento, compatibilidad, usabilidad y seguridad. Se debe verificar si la estructura o arquitectura concuerda con las especificaciones y verificar que efectos ha tenido en el sistema los cambios acontecidos bien sea para resolver errores o por el efecto de las regresiones.
Ejemplo para una mejor explicación
Supongamos que estamos integrando en una aplicación web de ecommerce un sistema de monitorización de las notificaciones enviadas al cliente. Se desea conocer las conversiones y para ello se mostrará datos y métricas usuales:
- la apertura del mail,
- número de clic realizados y en qué punto de la notificación han sido,
- la acción aplicada por el usuario una vez llega a la web,
- debe almacenar ciertos valores estadísticos de calidad introducidos por el usuario: encuesta de calidad y comentario sobre el producto adquirido.
Una de esas notificaciones es en el que les damos las «gracias por la compra realizada». En ella se le pide valoración sobre el producto recibido y la opción de participar en una encuesta. Además, le mostramos una selección de productos relacionados con su compra que le podría interesar.
Índice de contenidos
A continuación, os muestro en cada uno de los tipos en los que se agrupan las pruebas ilustrándolo con un ejemplo de qué prueba podría tener.
Pruebas funcionales - "Lo qué" el sistema debe hacer
Con este tipo de pruebas se desea verificar que los requisitos funcionales se cumplan. Es importante tener definidos esos requisitos en los diferentes productos existentes. Se pueden almacenar en historias de usuarios o epopeyas (en el caso de las metodologías ágiles) o casos de uso, especificaciones funcionales o comerciales (en metodologías estándar). Aunque también se puede dar el caso de no estar documentados.
Este tipo de pruebas se deben realizar en todos los niveles: pruebas de componente, de integración, de sistema y de aceptación (profundizaremos más sobre esos niveles en un próximo post). Sin embargo, en cada uno de los niveles este conjunto de pruebas toman un carácter y enfoque distintos.
Para desarrollar las pruebas sé necesita tener un conocimiento amplio del producto que estamos desarrollando, de la necesidad que tiene nuestro cliente y también conocimientos del software que implementa la solución.
Ejemplo de prueba funcional
Una prueba sería verificar los resultados almacenados de una notificación de «Gracias por su compra» que ha recibido un cliente. Se debe verificar que se pueda visualizar el dato de apertura (donde este sea positivo), poder visualizar el número y el listado de clics. Por último, se debe mostrar si ha tenido conversión (mostrará el comentario si lo ha dejado, mostrará si ha realizado la encuesta o no, o si ha comprado o añadido a favoritos otro producto de los recomendados).
Pruebas no funcionales - "Qué tan bien" se porta el sistema
Son aquellas pruebas en las que se verifican parámetros no funcionales pero si necesarios, como pueden ser la usabilidad, la seguridad o la eficiencia del rendimiento. Es de vital importancia empezar a realizar estas pruebas desde el comienzo del desarrollo y en todos los niveles de las pruebas para alcanzar un buen nivel de aseguramiento de la calidad.
Para desarrollarlas es necesario tener conocimiento del volumen de datos con el que se prevé trabajar en condiciones favorables y las limitaciones que puede tener nuestra tecnología en este sentido.
Ejemplo de prueba no funcional
Un ejemplo de prueba, sería verificar el diseño cumple con una versión responsive adecuada que permite acceder a la información de forma intuitiva.
Pruebas de caja blanca - "Cómo hace" lo que hace
En estas, se revisan las tripas de la funcionalidad: corrección y optimización del código, tipo de arquitectura, flujos de trabajo o de datos que componen el sistema. Se hace una revisión de cómo se ha realizado la funcionalidad el sistema de información para optimizar su desarrollo.
Para definirlas, se requieren de conocimientos amplios en distintas especialidades: código, BBDD o conocer a fondo el software con el que se está trabajando. En este tipo de pruebas es frecuente que esté implicado en gran medida el departamento de desarrollo.
Ejemplo de prueba de caja blanca
Imaginando que estamos trabajando en un eCommers con Drupal 7, tendríamos que revisar el módulo que realiza esta funcionalidad y verificar que la estructura del código PHP es óptima, o que se aplica de forma correcta el MVC según Symfony.
Pruebas relacionadas con el cambio - "Qué se ha tocado", que ahora esto otro no funciona
Estás pruebas son quizás una de las más importantes en el aseguramiento de la calidad. Creo que todo el que se dedica al desarrollo de software o testeo se ha encontrado con esta situación más de cien veces. Es de vital importancia, verificar el correcto funcionamiento del SI tras una corrección o un cambio del entorno. En este sentido podemos diferenciar dos tipos de conjuntos de pruebas:
Pruebas de confirmación - "todo está ok, tras la última correción"
En este conjunto de pruebas se debe verificar que la incidencia detectada que causo la corrección ya está solucionada. Y añadir nuevas pruebas relacionadas, que abarquen de forma minuciosa esa funcionalidad para evitar defectos relacionados. Este tipo de pruebas se realizan en todos los niveles y son igual de necesarias en gestión de proyectos iterativos como incrementales.
Ejemplo de pruebas de confirmación
Se ha detectado que se mostraba como realizado el comentario de los clientes, al haber hecho el clic en el formulario de registro de valoraciones. Lo correcto hubiera sido que se debía marcar como realizado, al almacenar los datos del comentario. Tras realizar la corrección, se debe verificar que no muestra la valoración añadida a menos que se hayan salvado los cambios de la valoración realizada por el usuario.
Además se deberá añadir una nueva prueba. Se debe verificar si en el caso de registro de encuestas, el sistema se comporta de la misma forma: si marca como realizada la encuesta aunque el cliente no haya almacenado los cambios.
Pruebas de regresión - Los "efectos secundarios" no deseados
Es necesario tener actualizados los sistemas, realizando cambios a nivel del SSOO o de BBDD, o sencillamente de versiones del software utilizado. Es importarte proteger el sistema de vulnerabilidades de seguridad. En estos casos, surgen incidencias que se deben corregir. Por ello, se debe realizar una batería de pruebas que verifiquen el correcto funcionamiento del software, sobre todo de un conjunto crítico de funcionalidades.
Este tipo de pruebas son el gran candidato a la automatización debido a su poca variabilidad y a qué se deben ejecutar reiteradas veces.
Ejemplo de prueba de regresión
Un ejemplo de esta prueba es verificar la correcta visualización y el correcto almacenamiento de los datos, como se definió en el ejemplo de la prueba funcional.
Conclusión: Se deben abarcar todos los tipos de pruebas para aplicar un buen aseguramiento de la calidad
Cada conjunto de pruebas tiene un objetivo a cumplir y por ello es necesario tenerlas presentes en los distintos niveles para llevar a cabo un correcto aseguramiento de la calidad.
En este sentido, cabe señalar la importancia de tener una buena trazabilidad entre requerimientos del proyecto y casos de prueba. Se debe comenzar con seguir una buena trazabilidad entre requisitos y casos de uso. Si deseas más información puedes hacer clic en el post.
Si te ha gustado este post, déjame un comentario sobre si estás de acuerdo o no; o indícame algún tema sobre el que te gustaría que hablara.
