Cuando participé del Agile Testing Days en Boston, Estados Unidos, tomé un workshop de dos días de Rob Sabourin, con el nombre “Agile test automation”. Durante el curso tomé algunas notas que quería compartir.
El curso está muy bueno, RobSab (como se hace llamar él) muestra diversos contenidos teóricos, y va tomando ejemplos de proyectos reales donde él ha participado. Los temas tocados fueron:
- Agile project test automation
- Automation strategies and technologies
- Story testing
- Non functional testing
- Experience and exploration
- Static and dynamic analysis
- Structural testing
El curso no va en profundidad a ningún tema, pero sirve como para tener un paneo general de lo que existe hoy en la industria como para tener en cuenta en las pruebas automatizadas y cómo aplicarlo en equipos ágiles.
Arrancó con este video, haciendo referencia a lo que pasa hoy en la industria, que se entrega producto que no está terminado, y se va armando en el camino. Esto es lo que plantea en cierta forma (y llevado muy al absurdo) en metodologías ágiles.
RobSab mencionó el concepto de “Testing Inspired Development”, como una forma de generalizar el enfoque de “test-first” y similares. Esto promueve la testability, y nos hace actuar en base a querer probar lo que vamos a entregar al usuario. No hay nada malo en hacer que el código sea fácil de probar, ¿cierto?Esta forma de pensar está alineada con algo que plantea Steven Covey, “begin with the end in mind”. Deberíamos tener un objetivo y una forma de demostrar que llegamos a ese objetivo.
¿Cómo logramos esto? Un ejemplo concreto es pensar desde el inicio en la “observability”. Toda funcionalidad se debería poder controlar y observar desde el exterior, con un programa. Esto es lo que permitiría automatizar fácilmente una prueba.
¿Cuándo comenzamos a automatizar al trabajar en scrum? Al comenzar a especificar una feature y sus criterios de aceptación. Esto se logra aplicando un enfoque ATDD o BDD, usando herramientas como Cucumber. RobSab planteaba que deberíamos apuntar a automatizar tres tipos de escenarios en este orden:
- Flujo principal
- Flujos alternativos
- Flujos de error
El enfoque a darle a esto debería ser más orientado a pedir ejemplos de negocio que a pedir criterios de aceptación. Cuando un desarrollador pide ejemplos de los requerimientos, lo que está haciendo es validando o refutando su hipótesis actual, la solución que se está imaginando. Un tester en cambio, investiga por condiciones adicionales, escenarios alternativos, fuera de la solución que se está creando.
Un consejo que dio fue el de evitar la palabra “test” como un verbo al describir tareas, esto genera rechazo en los desarrolladores. Una alternativa puede ser usar “aprender”, “verificar”, “chequear”.
Algo que mencionó para la gente que le gustan las métricas. Qué tal si medimos cuánto tiempo gastamos en retrabajo, en contraposición con el tiempo que invertimos en desarrollar nuevas cosas. Esto se podría cruzar con el famoso cuadrante de la deuda técnica para calcularlo. Y ya que estamos hablando de deuda técnica y aspectos de calidad de código, algo que nombró relacionado a esto que no había pensado antes, es que si estamos usando herramientas como SonarQube en nuestra estrategia de Integración Continua, deberíamos revisar que si algún módulo cambia la complejidad ciclomática de forma drástica (ya sea que aumente o que disminuya) deberíamos probar todo lo que usa ese código, porque tal vez el desarrollador fue “naive” y simplificó demasiado, o bajo presión agregó lógica que se podría mejorar.
Algo que mencionó, muy alineado a lo que conté acá, es que la cobertura de código sirve para encontrar huecos en nuestra automatización, pero no sirve para hablar de la calidad de los tests que tenemos, hablaría más de la calidad de los tests que aún no tenemos.
En muchos cursos de testing que doy, hablo en algún momento de la importancia que tiene hacer primero los tests positivos, esos que apuntan al usuario que “hace todo bien” y verifican que “le funciona todo bien”. Recién luego de tener eso uno debería ir a los escenarios alternativos. Esto RobSab lo explicó pensando en TDD. En TDD uno desarrolla una prueba, luego hace el código que hace que esa prueba pase, y luego se mejora el código. Si seguimos un enfoque ágil, de hacer primero lo que más valor le da al negocio, deberíamos implementar primero esas pruebas que más valor le dan al negocio, ya que eso hará que se desarrolle primero la funcionalidad que más valor le da al negocio. Claramente, el caso positivo es el que debería hacerse primero, luego los alternativos, luego los casos negativos.
En resumen, el curso estuvo bárbaro. Me quedo tranquilo que no vi nada nuevo, lo cual me hace pensar que más o menos venimos trabajando en los frentes más importantes en Abstracta, pero a la vez aprendí mucho al ver distintas formas de ver los mismos temas, o distintas formas de explicarlos. Por sobre todas las cosas, un placer conocer a uno de los primeros referentes que tuve cuando comencé en el mundo del testing, y más contento aún porque él sabía quién era yo… tremendo honor sentí.
