Introducción
Quienes están familiarizados con las prácticas de desarrollo ágil TDD, y ATDD habrán notado que estas se orientan principalmente a lo funcional descuidando un poco la verificación de los atributos de calidad del software, mas concretamente los requisitos de nivel de servicio.
De hecho muchos equipos al hacer la transición al esquema ágil, delegan toda la responsabilidad de la calidad del producto a las pruebas unitarias y pruebas de aceptación, pues en este tipo de metodologías un área separada de aseguramiento de calidad pierde importancia al hacer de la calidad un preocupación de todos los miembros del equipo. El problema con este enfoque es que inicialmente no todos tenemos los skills necesarios para garantizar esto y con el tiempo la calidad de los productos construidos tiende a decrecer generando una mala percepción en los usuarios finales.
Si bien es importante mantener el concepto de calidad como responsabilidad compartida, es preciso también tener en cuenta otros aspectos que deben ser verificados para garantizar un producto de calidad.
 |
| Cuadrantes de testing ágil |
A continuación quiero compartir con ustedes una forma para integrar las pruebas de desempeño dentro del ciclo de TDD y ATDD, lo cual nos llevará con el tiempo a hacer continous performance testing (Verificación constante del desempeño del aplicativo). Este se basa en los cuadrantes de testing ágil concepto inicialmente definido por Brian Marick‘s.
Abstracción de alto nivel de un software
 |
| Abstracción de alto nivel de un software |
Desde el punto de abstracción mas alto, un software se puede ver como un conjunto de UNIDADES FUNCIONALES (Probadas unitariamente), que en conjunto forman COMPONENTES DE SOFTWARE, los cuales a su vez constituyen FUNCIONALIDADES DE NEGOCIO. Las funcionalidades de negocio normalmente no conviven por si solas y requieren interactuar con sistemas externos para entregar el resultado final.
Consideraciones previas
Antes de entrar en la definición del proceso debemos tener claro que las pruebas de desempeño normalmente están asociadas a pruebas de estress (Alcanzar el punto de quiebre del sistema), y a pruebas de escalabilidad (Como se afecta el desempeño al incrementar la carga de usuarios concurrentes en el mismo). Probar estos aspectos requiere no solo herramientas adecuadas sino también recursos de hardware para poder generar la carga suficiente. Adicional a esto el tiempo de ejecución puede variar dependiendo de la maquina en la que se ejecuten las pruebas por lo que lograr un nivel de confiabilidad adecuado requiere que estas se ejecuten en ambientes muy similares a los productivos.
El proceso de pruebas de desempeño que se plantea en esta entrada plantea tres diferentes perspectivas que permitirán aumentar la confiabilidad en la verificación de los niveles de servicio de forma gradual.
- Pruebas sobre COMPONENTE DE SOFTWARE sin integración externa: Al hacer esto verificamos que el código implementado sea potenciamente escalable (Si lo comparamos con el consumo de recursos), que tenga el throughput y los tiempos de respuesta que se requieren para cumplir con los niveles de servicio de la funcionalidad de negocio (Funcionalidad de negocio= Suma de los componentes). Las pruebas de performance son mas costosas de mantener en el tiempo respecto a las pruebas unitarias, por esto sugiero que no sean aplicadas a las unidades funcionales.
- Pruebas sobre COMPONENTE DE SOFTWARE con integración externa: Cuando existe dependencia con otros componentes de software las pruebas de vuelven incluso mas difíciles de mantener pues debemos lidiar con los datos. Por esta razón la cantidad de pruebas de este tipo que se realicen debe ser menor en comparación con la perspectiva anterior. Tenga en cuenta que al hacer este tipo de pruebas se debe garantizar que sean repetibles asegurando que los datos que se requieren como insumo se encuentren en el sistema externo y que los datos en los repositorios de información vuelvan al estado previo a la ejecución. Al realizar pruebas en esta perspectiva garantizamos que la integración con los sistemas externos sea adecuada
- Pruebas de escalabilidad y estress sobre FUNCIONALIDAD DE NEGOCIO: Como ya lo mencioné probar escalabilidad y estress requieren recursos importantes de hardware y skills mas avanzados para lograr una verificación confiable. Por esta razón es importante que un equipo especializado las realice. Se puede utilizar la estrategia de Parallel independent Testing
Independiente de la perspectiva en la que se realicen las pruebas, es importante que estas puedan ser ejecutadas de forma automática por un servidor de integración continua y que se defina una linea base que permita ver como varia el desempeño en el tiempo al agregar mas funcionalidades o modificar el código existente.
Proceso
Las pruebas en las dos primeras perspectivas deben ser realizadas por el equipo de desarrollo, por esta razón se plantea el siguiente esquema en el que se integran las pruebas de performance dentro del ciclo ATDD.
La idea es que una vez se tenga construido un componente de software (En el ciclo TDD) y/o una funcionalidad de negocio (En el ciclo ATDD), se ejecute el ciclo interno de verificación del desempeño.
La idea es que una vez se tenga construido un componente de software (En el ciclo TDD) y/o una funcionalidad de negocio (En el ciclo ATDD), se ejecute el ciclo interno de verificación del desempeño.
Implementación
A continuación un vídeo que muestra paso a paso como implementar las pruebas en la primera perspectiva.
El código fuente se encuentra en Git-Hub https://github.com/mauro2357/Agil-Architecture/tree/master/Ordenamiento.
