Testing, porqu, como, cuando y dnde

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 distincin 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 ms bien propiedades de diseo. 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, adecuacin del
sistema a los requisitos, etc.
Por tanto, dado que en nuestros desarrollos tenemos que proporcionar calidad a nuestros
clientes, necesitamos establecer mecanismos y mtricas 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
mtricas 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 ms pequea de cdigo
ejecutable disponible para comprobar que dicho cdigo 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 rpidos, independientes (aislados del entorno), repetibles (escribir
una vez, ejecutar miles), validarse por s mismos (es correcto, falla) y escribirse justro tras el
cdigo que prueban o antes del mismo (TDD en el ltimo caso).
Integration Testing: Es toda prueba que se realiza sobre dos o ms componentes
para asegurar que su funcionamiento conjunto y sus interacciones con el entorno son correctas
en trminos de funcionalidad. La idea es asegurar que las propiedades comprobadas para cada
componente en los tests unitarios siguen siendo vlidas cuando se integran con otros
componentes y con el entorno y que las comunicaciones entre componentes son vlidas. Es
decir, que todos los componentes respetan las condiciones de interaccin 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 integracin 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 simulacin 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,
mdulo 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
valoracin 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
cmo hacer dichos tests. Los pasos a seguir son:
Unit testing: Comprobar que nuestro cdigo hace lo que queremos.
Integration Testing: Comprobar que las distintas partes de nuestro cdigo 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.