Testing, porqué, como, cuando y dónde

Bueno, en este mi segundo post voy a hablar de testing. Como ya comentó Rodrigo Corral en un post hace tiempo, En el software, la calidad, no es opcional. La siguiente pregunta que tenemos que hacernos es ¿Qué es la calidad en el software? La primera distinción que debemos hacer es entre calidad interna y calidad externa. Calidad interna es toda aquella propiedad de nuestro software que el usuario final no va a observar directamente como pueden ser la mantenibilidad del mismo, la flexibilidad, etc. Son más bien propiedades de “diseño”. Calidad externa es toda aquella propiedad de nuestro software que es observable directamente por el usuario final como puede ser la fiabilidad, experiencia de usuario, rendimiento, adecuación del sistema a los requisitos, etc.

Por tanto, dado que en nuestros desarrollos tenemos que proporcionar calidad a nuestros clientes, necesitamos establecer mecanismos y métricas que nos permitan garantizar de forma razonable que estamos alcanzando los niveles de calidad requeridos. Es aquí donde entra en juego el Testing. El testing es el mecanismo que establecemos para asegurar la calidad de nuestro software y los criterios de testing que establecemos en nuestros proyectos son las métricas que luego nos permiten afirmar que nuestro software dispone de una determinada calidad. El siguiente paso es categorizar los tipos de tests existentes y ver qué afirmaciones nos permiten establecer sobre nuestro software.

Unit testing: Es toda prueba que se realiza sobre la unidad más pequeña de código ejecutable disponible para comprobar que dicho código se comporta y produce los resultados que esperamos. Estos tests deben ser FIRST: Fast, Isolated, Repeatable, Self-Validating, Timely. Es decir, los tests deben ser rápidos, independientes (aislados del entorno), repetibles (escribir una vez, ejecutar miles), validarse por sí mismos (es correcto, falla) y escribirse justro tras el código que prueban o antes del mismo (TDD en el último caso).

Integration Testing: Es toda prueba que se realiza sobre dos o más componentes para asegurar que su funcionamiento conjunto y sus interacciones con el entorno son correctas en términos de funcionalidad. La idea es asegurar que las propiedades comprobadas para cada componente en los tests unitarios siguen siendo válidas cuando se integran con otros componentes y con el entorno y que las comunicaciones entre componentes son válidas. Es decir, que todos los componentes respetan las condiciones de interacción establecidas por cada uno de los componentes con los que se relacionan.

Smoke Testing: Es toda prueba que se realiza sobre un sistema para asegurar que funciona correctamente durante un tiempo determinado bajo unas condiciones de carga regulares y bajas. Este tipo de tests nos ayuda a comprobar que no se nos hayan escapado fallos durante las pruebas unitarias y los tests de integración y es una prueba directa de que nuestro sistema funciona correctamente bajo condiciones favorables durante un periodo de tiempo prolongado.

Stress Testing: Es toda prueba que se realiza sobre un sistema para asegurar que sigue funcionando o mejor dicho “satisface unas determinadas propiedades” bajo condiciones adversas. Este tipo de pruebas incluyen la simulación de todo tipo de condiciones adversas como gran carga y picos fuertes de trabajo, problemas de conectividad, problemas de memoria, etc. Lo que nos permiten comprobar este tipo de pruebas es que ante hechos adversos como por ejemplo la caida de un nodo del cluster de la base de datos de nuestro sistema, este siga funcionando correctamente.

Performance Testing:  Es toda prueba que realizamos sobre un componente, módulo o sistema para comprobar el tiempo de respuesta y el throughput del mismo. Este tipo de pruebas nos permite determinar el tiempo de respuesta del sistema y la cantidad de peticiones por segundo que puede soportar. Permite identificar cuellos de botella en el sistema y analizar cual es la mejor parte del sistema a mejorar para conseguir un mejor rendimiento. Para ello nos podemos ayudar de la famosa ley de Amdahl.

Capacity Testing: Es toda prueba que realizamos sobre nuestro sistema para ver como se comporta ante distintos niveles de carga. Mediante estas pruebas podemos hacer una valoración de los recursos necesarios para que nuestro sistema cumpla con los requisitos de rendimiento, tiempo de respuesta y carga de trabajo que espera nuestro cliente. Estos tests comienzan con una carga de trabajo baja y la van aumentando regularmente hasta un nivel equivalente al de una prueba de stress testing. De esta forma podemos ver los recursos que necesitaremos y como se comportará el sistema con los recursos actuales ante distintas cargas de trabajo.

Una vez hemos establecido los tests que podemos realizar a nuestro sistema, nos queda resolver cómo hacer dichos tests. Los pasos a seguir son:

Unit testing: Comprobar que nuestro código hace lo que queremos.

Integration Testing: Comprobar que las distintas partes de nuestro código se comunican adecuadamente entre sí y con el entorno.

Smoke testing: Comprobar que nuestro sistema es capaz de funcionar sin fallos durante un periodo prolongado de tiempo bajo condiciones aceptables de carga de trabajo.

Capacity Testing: Comprobar como escala nuestro sistema ante el aumento de carga de trabajo.

Performance Testing: Comprobar que nuestro sistema cumple las espectativas de tiempo de respuesta y carga de trabajo con los recursos actuales e identificar cuellos de botella del sistema.

Stress Testing: Comprobar que nuestro sistema se comporta adecuadamente ante cargas de trabajo superiores a las previstas y posibles problemas de red, memoria, disco, CPU, etc.

 

Y bueno, como tampoco quiero extenderme hasta el infinito lo dejamos aquí por hoy. En el siguiente post Unit Testing a fondo: metodología, técnicas y herramientas. Veremos como hacer un buen test unitario, como diseñar nuestro código para que sea fácil de testear, cómo medir la calidad de nuestros test, como usar contratos y herramientas de verificación estáticas para detectar errores antes de realizar pruebas y cómo utilizar herramientas automáticas como PEX para testear nuestro código en base a especificaciones y generar automáticamente casos de prueba concretos.

 

Un saludo, espero que lo disfrutéis,

Javier.

2 comentarios en “Testing, porqué, como, cuando y dónde”

  1. Estoy deseoso de ver el siguiente post!!!
    Muy buena forma de empezar!! me encanta!!
    Una cuestión, sin animo de tocar las narices, ¿Realizas todo este tipo de pruebas en los desarrollos que haces?

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *