Está en la página 1de 2

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.