En agile y Scrum en particular, cuando hablamos de testing nos referimos a toda una batería de prácticas que nos permiten no solo crear código de calidad y mantenible, con minimización de deuda técnica, sino un producto adecuado para el mercado. Por cierto, aunque tengamos a testers dedicados, el testing es responsabilidad de todo el equipo en su conjunto. Ni el tester puede quedarse de brazos cruzados durante el Sprint, a la espera de que el trabajo de programación concluya, ni el resto del equipo puede desentenderse y echar la culpa al tester cuando se encuentran errores. No, eso no vale.

El gráfico de arriba clasifica los diversos tipos de tests en cuatro apartados. Los testers, junto con el cliente, suelen ocuparse de los tests orientados a negocio, mientras que los programadores harán lo propio con los orientados a tecnología. Pero, insisto, la responsabilidad de realizar el testing es compartida y ha de afrontarse de la forma más colaborativa posible.

Cuadrante 1

Este cuadrante alude al TDD o Test Driven Development, esto es, a la implementación de tests unitarios y de componentes. Al escribir primero los tests, los desarrolladores diseñan mejor código. Los tests unitarios verifican que pequeñas partes del sistema funcionan correctamente, como un objeto o método. Los tests de componentes, por su parte, verifican el funcionamiento de partes mayores, como un conjunto de clases. Todos estos tests son automáticos y se escriben en el mismo lenguaje que la aplicación de que se trate.

Estos tests determinan lo que Kent Beck llamó “calidad interna” del código, que no es negociada con los clientes, sino que es definida por los programadores.

Cuadrante 2

Comprende tests que también guían al equipo de desarrollo a la hora de diseñar el software, aunque desde un punto de vista más general y a nivel de negocio. Permiten confirmar que el comportamiento de una determinada funcionalidad es el deseado por el cliente o los expertos de negocio, que ayudan a escribir estos tests y en cuyo lenguaje se deben expresar. Hablamos aquí de satisfacer las condiciones de “calidad externa”.

Lo ideal será que la mayor parte de estos tests (scripts con parámetros de ejemplo, simulaciones, tests de validación de la interfaz de usuario, de APIs de terceros, etc.) estén automatizados y que sean parte del proceso de build e integración continua, dando feedback frecuente a los desarrolladores. No obstante, en este cuadrante incluimos, asimismo, prototipos y diseños que guían al equipo en cuanto a la interfaz de usuario y sus interacciones (que será parte del trabajo de discovery del equipo de producto).

Cuadrante 3 

Los tests de los cuadrantes 1 y 2 ayudaban al equipo a diseñar el producto. Sin embargo, es posible que, incluso habiendo implementado tests orientados a negocio, se hayan escapado o malentendido requerimientos del cliente. Que el software no sea lo que el cliente realmente quiere, o que no sea lo suficientemente competitivo. Es aquí donde el testeo manual se hace necesario: solo una persona, ya sea el cliente o alguien que se pone en su lugar, usando su intuición y creatividad, puede evaluar si el producto es, de verdad, el deseado. Este tipo de testing es el que normalmente permite encontrar los errores más relevantes.

Hablamos, en especial, del testeo exploratorio, en el que el tester diseña y ejecuta tests de manera simultánea. También de tests de usabilidad en entrevistas, focus groups, etc.

Cuadrante 4

Son todos aquellos tests dirigidos a cubrir requerimientos no funcionales como seguridad, velocidad de carga, escalabilidad, etc. En la medida de lo posible, los automatizaremos dentro del cuadrante 1 o 2, o utilizaremos herramientas para ello.

Para el Scrum Master, estos cuadrantes proporcionan una clasificación útil a considerar por parte del Equipo de Desarrollo, para, a partir de ahí, completar o adaptar nuestras prácticas de testing al contexto y proyecto en el que nos encontremos. Así, algunas cuestiones a tener en cuenta pueden ser las siguientes:

• ¿Utilizamos tests unitarios y de componentes?
• ¿Contamos con un automated build process que nos da feedback al instante sobre errores?
• ¿Estamos utilizando ejemplos facilitados por el cliente para testear que el software se comporta de la forma deseada?
• ¿Mostramos prototipos u diseños de UI a los clientes o usuarios, antes de empezar a programar?
• ¿Dejamos suficiente tiempo para hacer testeo exploratorio?
• ¿Cómo testeamos la usabilidad?
• ¿Estamos implicando al cliente o usuario en el testing?
• ¿Cómo testeamos la seguridad o el rendimiento de la aplicación?