Un tema sobre el que me pongo un poco «pesado» cuando trabajo para nuestros clientes es el de la Calidad de los artefactos que generamos, software o no software.
Dentro de los variados y potentes aspectos que se tratan en la Calidad, el Testing es uno de los más comentados, pruebas unitarias, testers agile, testing en equipos independientes, regresión, UAT, stress, y así un montón más de términos, conceptos, técnicas, herramientas, etc.
Una de las cosas que más me llaman la atención es cuando pregunto a las personas que participan en el proyecto sobre los tipos de prueba que se realizarán y que garantizarán el buen funcionamiento del producto y del sistema. Es cierto que no siempre pasa y que hay organizaciones que todo esto lo tienen muy trabajado, pero hay veces que cuando hablo de la estrategia de pruebas a seguir las caras que ponen son un poema.
Sobre los diferentes pruebas que se pueden hacer (dependerá de cada situación concreta), hace un par de años empecé a trabajar sobre una clasificación propuesta inicialmente por Brian Marick y refinada después por Lisa Crispin y Janet Gregory en su libro «Agile Testing«. El objetivo era poner el Testing Ágil en contexto y guiar a los equipos y gerencia sobre cómo integrar el Testing en sus prácticas de desarrollo iterativo a través de los cuatro cuadrantes del Testing Agile.
Estuve en un curso con Lisa Crispin y ahí pude aprovechar para comentar y entender de qué iba esta taxonomía, os dejo una breve explicación:
Los cuadrantes representan los diferentes propósitos y tipos de pruebas de software que podemos realizar en un entorno Ágil. Aquí tenemos una imagen de los cuadrantes del Testing Ágil:
Pruebas de apoyo al equipo (Supporting the Team)
Destinadas a apoyar al equipo de desarrollo en la medida que este desarrolla el producto. El concepto es nuevo para muchos testers ya que el Testing tradicional es 
para encontrar errores.
Se realizan en los cuadrantes 1 y 2 del Testing Ágil.
La explicación de que son pruebas de apoyo al equipo, es debido a que las pruebas del cuadrante 1 y 2 se convierten prácticamente en la base de un equipo de desarrollo ágil.
Estas pruebas primeramente guían el desarrollo de la funcionalidad, y luego cuando se automatizan sirven para apoyar la refactorización y la inclusión de nuevo código sin causar resultados inesperados en el comportamiento del sistema.
Pruebas de críticas al producto (Critique the product)
Para un cliente es muy difícil saber de antemano lo que quiere hasta verlo plasmado en un producto de características mínimas.
Se realizan en los cuadrantes 3 y 4 del Testing Ágil.
Cuando se indica “críticas al producto”, no tiene necesariamente un sentido negativo, pues éstas pueden ser inclusive para resaltar aspectos positivos o inclusive sugerir mejoras.
En siguientes posts comentaré más en detalle sobre cada cuadrante pero ahora unas notas sobre el Uso de los cuatro cuadrantes:
- Los 4 cuadrantes son una taxonomía para ayudar en la planificación del Testing Ágil.
- La idea de usarlos es asegurar que se tomen en cuenta todos los recursos y métodos necesarios para logar la producción de software de calidad.
- Los 4 cuadrantes no son reglas rígidas ni en su contenido ni orden. Cada equipo de desarrollo de software debe adaptarlos a su situación particular con amplia libertad.
- Los 4 cuadrantes no deben ejecutarse en orden del 1 al 4, pues eso sería aplicar una metodología predictiva y no Agile.
- La numeración de los cuadrantes es arbitraria y es para que, por ejemplo, un interlocutor pueda referirse al “cuadrante 1” en lugar de “pruebas de tecnología de cara a cliente”.
- Por qué cuadrante comenzar:
- La mayoría de los proyectos comenzarían por el cuadrante 2 que contempla ejemplos de comportamiento, pruebas de las historias y prototipos.
- Sin embargo, no es descartable que un proyecto comience por ejemplo con pruebas de desempeño (cuadrante 4) si es el aspecto más crítico del proyecto.
- Si existe incertidumbre sobre algunos requisitos, que no están del todo definidos cuando comienzas, podrías comenzar con testing exploratorio (cuadrante 3). El Testing exploratorio es para obtener información sobre el comportamiento y no para probar si esta correcto o no.
No se trata de seguir la taxonomía, se trata de que nos sirva para pensar y plantear qué necesitamos en nuestros trabajos.