En el último artículo hablamos del V-Model, como uno de los estándares de SQA (aseguramiento de la calidad de software) utilizado para describir las actividades de prueba como parte del proceso de desarrollo de software. Hoy vamos a profundizar en las actividades de prueba descritas en este modelo, divididos en niveles de pruebas de software.

Cada una de ellas está relacionada con una fase de desarrollo del software específica, como puedes ver en esta imagen:

En el diseño de casos de prueba existen dos enfoques principales:

• Estructural o de caja blanca. Se verifica la estructura interna del componente con independencia de la funcionalidad establecida para el mismo.
  Por tanto, no se comprueba la corrección de los resultados si éstos se producen. Ejemplos de este tipo de pruebas pueden ser ejecutar todas las instrucciones del programa, localizar código no usado, comprobar los caminos lógicos del programa, etc.
• Funcional o de caja negra. Se comprueba el correcto funcionamiento de los componentes del sistema de información, analizando las entradas y salidas y verificando que el resultado es el esperado. Se consideran exclusivamente las entradas y salidas del sistema sin preocuparse por la estructura interna del mismo.

El enfoque que suele adoptarse para una prueba unitaria, la primera fase de pruebas establecida en el V-Model, está claramente orientado al diseño de casos de caja blanca, aunque se complemente con caja negra.

1. Pruebas Unitarias.

Comenzamos por las pruebas unitarias, también conocidas como unit testing.

Las pruebas unitarias normalmente las realizan los programadores, mediante las cuales se prueban unidades individuales de código fuente para determinar si son aptas para su uso.

Estas pruebas verifican que los componentes más pequeños del programa funcionan correctamente. Dependiendo del lenguaje de programación, un componente puede ser un módulo, una unidad o una clase.

Según esto, las pruebas se llamarán pruebas de módulo, pruebas de unidad o pruebas de clase.

Las pruebas de componentes comprueban la salida del componente después de proporcionar una entrada basada en la especificación del componente.

La principal característica de las pruebas de componentes es que los componentes individuales se prueban de forma aislada y sin interactuar con otros componentes. Como no hay otros componentes implicados, es mucho más fácil localizar los defectos.

Normalmente, la implementación de las pruebas se realiza con la ayuda de un framework de pruebas, por ejemplo, JUnit, CPPUnit o PyUnit, por nombrar algunos de los frameworks de pruebas unitarias populares. 

Además de las pruebas funcionales, las pruebas de componentes pueden referirse a aspectos no funcionales como la eficiencia (por ejemplo, el consumo de almacenamiento) y la mantenibilidad (por ejemplo, la complejidad del código).

Las pruebas unitarias tienen como objetivo verificar la funcionalidad y estructura de cada componente individualmente una vez que ha sido codificado.

Los pasos necesarios para llevar a cabo las pruebas unitarias son los siguientes:

• Ejecutar todos los casos de prueba asociados a cada verificación establecida en el plan de pruebas, registrando su resultado. Los casos de prueba deben contemplar tanto las condiciones válidas y esperadas como las inválidas e inesperadas.
• Corregir los errores o defectos encontrados y repetir las pruebas que los detectaron. Si se considera necesario, debido a su implicación o importancia, se repetirán otros casos de prueba ya realizados con anterioridad.

La prueba unitaria se da por finalizada cuando se hayan realizado todas las verificaciones establecidas y no se encuentre ningún defecto, o bien se determine su suspensión.

2. Pruebas de Integración.

Después de completar las pruebas unitarias se realizan las pruebas de integración.

El objetivo de las pruebas de integración es verificar el correcto ensamblaje entre los distintos componentes una vez que han sido probados unitariamente con el fin de comprobar que interactúan correctamente a través de sus interfaces, tanto internas como externas, cubren la funcionalidad establecida y se ajustan a los requisitos no funcionales especificados en las verificaciones correspondientes.

Las pruebas pueden abarcar sólo dos componentes específicos, grupos de componentes o incluso subsistemas independientes de un sistema de software. Las pruebas de integración suelen realizarse después de que los componentes hayan sido probados en la fase de pruebas de componentes inferiores.

El desarrollo de las pruebas de integración puede basarse en la especificación funcional, la arquitectura del sistema, los casos de uso o las descripciones del flujo de trabajo. Las pruebas de integración se centran en las interfaces de los componentes (o las interfaces de los subsistemas) y tratan de revelar los defectos que se activan a través de su interacción y que, de otro modo, no se activarían al probar los componentes aislados.

Las pruebas de integración también pueden centrarse en las interfaces con el entorno de la aplicación, como los sistemas de software o hardware externos. Esto suele denominarse pruebas de integración de sistemas, en contraste con las pruebas de integración de componentes.

En las pruebas de integración se examinan las interfaces entre grupos de componentes o subsistemas para asegurar que son llamados cuando es necesario y que los datos o mensajes que se transmiten son los requeridos.

A menudo se combinan las prueba unitarias con las de integración, ya que en las unitarias es necesario crear módulos auxiliares que simulen las acciones de los componentes invocados por el que se está probando y  también se crean a componentes para establecer las precondiciones necesarias, llamar al componente objeto de la prueba y examinar los resultados de la prueba.

Los tipos principales de integración son:

• Integración incremental: se combina el siguiente componente que se debe probar con el conjunto de componentes que ya están probados y se va incrementando progresivamente el número de componentes a probar.
  Con el tipo de prueba incremental lo más probable es que los problemas que surjan al incorporar un nuevo componente o un grupo de componentes previamente probado, sean debidos a este último o a las interfaces entre este y los demás componentes. 
• Integración no incremental: se prueba cada componente por separado y posteriormente se integran todos a la vez realizando las pruebas pertinentes. Este tipo de integración se denomina también “Big-Bang” (gran explosión). 

Las pruebas de integración se realizan en la fase de diseño de la arquitectura.

3. Pruebas de sistema.

Estas pruebas permiten probar el sistema en su conjunto y con otros sistemas con los que se relaciona para verificar que las especificaciones funcionales y técnicas se cumplen.

Tienen la finalidad de verificar cómo se comporta el producto tomando como referencia al usuario final y su interacción con el sistema.

Se llevan a cabo cuando se chequea que la integración de los sistemas actúa correctamente, por lo tanto, se comprueba la funcionalidad y se deben realizar en un ambiente similar al real, verificando que todo funcione de acuerdo con las especificaciones y requisitos planteados desde el principio por el cliente. Reflejan una visión muy similar a su comportamiento en el entorno de producción.

La fase de pruebas del sistema abarca el sistema de software en su conjunto. Mientras que las pruebas de integración se basan principalmente en las especificaciones técnicas, las pruebas del sistema se crean teniendo en cuenta el punto de vista del usuario y se centran en los requisitos funcionales y no funcionales de la aplicación. Estas últimas pueden incluir pruebas de rendimiento, carga y estrés.

Aunque los componentes y su integración ya han sido probados, las pruebas del sistema son necesarias para validar que se cumplen los requisitos funcionales del software. Algunas funcionalidades no pueden probarse en absoluto sin ejecutar los sistemas de software completos. Las pruebas del sistema suelen incluir otros documentos, como la documentación del usuario o los documentos de análisis de riesgos.

El entorno de pruebas del sistema debe ser lo más parecido posible al entorno de producción. Si es posible, hay que utilizar el mismo hardware, sistemas operativos, controladores, infraestructura de red o sistemas externos, y evitar en lo posible los marcadores de posición, simplemente para reproducir el comportamiento del sistema de producción. Sin embargo, el entorno de producción no debe utilizarse como entorno de prueba, ya que cualquier defecto provocado por la prueba del sistema podría repercutir en el sistema de producción.

Las pruebas de sistema deberían ser automatizadas para reducir el tiempo asociado a las pruebas manuales. 

Tipos de pruebas de sistema:

• Pruebas funcionales: asegurar que el sistema realiza correctamente todas las funciones que se han detallado en las especificaciones dadas por el usuario.
• Pruebas de comunicaciones: determinan que las interfaces entre los componentes del sistema funcionan adecuadamente, tanto a través de dispositivos remotos, como locales. Asimismo, se han de probar las interfaces hombre/máquina.
• Pruebas de rendimiento: comprueban que los tiempos de respuesta están dentro de los intervalos establecidos en las especificaciones del sistema.
• Pruebas de volumen: examinan el funcionamiento del sistema cuando está trabajando con grandes volúmenes de datos, simulando las cargas de trabajo esperadas.
• Pruebas de sobrecarga: comprueban el funcionamiento del sistema en el umbral límite de los recursos, sometiéndole a cargas masivas. El objetivo es establecer los puntos extremos en los cuales el sistema empieza a operar por debajo de los requisitos establecidos.
• Pruebas de disponibilidad de datos: consisten en demostrar que el sistema puede recuperarse ante fallos, tanto de equipo físico como lógico, sin comprometer la integridad de los datos.
• Pruebas de facilidad de uso: comprueban la adaptabilidad del sistema a las necesidades de los usuarios, tanto para asegurar que se acomoda a su modo habitual de trabajo, como para determinar las facilidades que aporta al introducir datos en el sistema y obtener los resultados.
• Pruebas de operación: comprueban la correcta implementación de los procedimientos de operación, incluyendo la planificación y control de trabajos, arranque y rearranque del sistema, etc.
• Pruebas de entorno: verifican las interacciones del sistema con otros sistemas dentro del mismo entorno.
• Pruebas de seguridad: verifican los mecanismos de control de acceso al sistema para evitar alteraciones indebidas en los datos.

4. Pruebas de aceptación.

Estas pruebas van dirigidas a comprobar que el sistema cumple los requisitos de funcionamiento esperado, recogidos en la definición de requisitos y en los criterios de aceptación con el fin de conseguir la aceptación final del sistema, desde el punto de vista de su funcionalidad y rendimiento, por parte del usuario.

Las pruebas de aceptación son definidas por el usuario del sistema y preparadas por el equipo de testing, aunque la ejecución y aprobación final corresponden al usuario.

El responsable de usuarios debe revisar los criterios de aceptación que se especificaron previamente en el plan de pruebas del sistema y, posteriormente, dirigir las pruebas de aceptación final.

La validación del sistema se consigue mediante la realización de pruebas de caja negra que demuestran la conformidad con los requisitos y que se recogen en el plan de pruebas.

Las pruebas de aceptación pueden ser:

• Internas, por ejemplo, para una versión de un software que aún no se ha lanzado. Estas pruebas de aceptación internas las realizan quienes no participan en el desarrollo o las pruebas.
• Externas, realizadas por la empresa que pidió el desarrollo o los usuarios finales del software.
  En el caso de las pruebas de aceptación por parte del cliente, incluso puede ser responsabilidad de éste, parcial o totalmente, decidir si la versión final del software cumple los requisitos de alto nivel. Se crean informes para documentar los resultados de las pruebas y para la discusión entre la entidad desarrolladora y el cliente.
  A diferencia de las pruebas de aceptación por parte del cliente, las pruebas de aceptación por parte del usuario (UAT) pueden ser el último paso antes del lanzamiento final del software. Se trata de una prueba centrada en el usuario para verificar que un software ofrece realmente los flujos de trabajo que se pretenden. Estas pruebas pueden llegar a cubrir aspectos de usabilidad y la experiencia general del usuario.

Las pruebas de aceptación suelen ser manuales y, a menudo, sólo se automatiza una pequeña parte de ellas. Pero si pensamos en el arduo trabajo que supone realizar las pruebas de aceptación de numerosas versiones a lo largo del ciclo de vida del software o de las numerosas iteraciones en los proyectos ágiles, a medio y largo plazo, la automatización de pruebas sería la mejor solución.

Es aquí dónde TAST , Test Automation System Tool, gana distancia entre otras herramientas de automatización de pruebas, ya que:

• Al ser una herramienta codeless se facilita la participación del usuario final o cliente, involucrándolo, ya no sólo en la aceptación, si no en todo el proceso de pruebas.
• Es una herramienta intuitiva con una interfaz amigable para el usuario, el cual podrá dibujar casos de prueba siguiendo reglas básicas y de sentido común.

Lo que nos lleva al objetivo final de las pruebas de Software:
alcanzar la máxima calidad para ofrecer al usuario un producto excelente.

Si este contenido te ha parecido interesante, síguenos en nuestro LinkedIn para estar al día.