Entrevista con Katrina Clokie

Siendo hoy el día del tester (¡feliz día para todos!), creo que es un excelente día para compartir este post en el que resumo una entrevista con Katrina Clokie, a quien respeto mucho como tester. Estoy preparando un curso de testing ágil como conté en post anterior, y a su vez estoy leyendo el libro “A practical guide to testing in DevOps”, cuya combinación me hizo twittear y finalmente proponerle a Katrina (su autora) tener una call para hacerle algunas preguntas. Quiero dejar acá algunos puntos a destacar de esa charla con Katrina que tuve el placer de tener, ya que realmente fue muy inspiradora y aprendí mucho de lo que conversamos (además que es encantadora, y terminamos hablando hasta de lo lindo que es vivir en Nueva Zelanda).

El rol del tester

Según Katrina, el testing está siendo empujado en dos sentidos, en estar más involucrado con el negocio, y en estar más involucrado con la gente de operaciones e infraestructura (Ops). Hay muchas formas de llamarle a lo mismo pero son todas tendencias que impulsan hacia el mismo lado (DevOps, shift-left testing, QE role, agile). Acá se marca la importancia del T-shaped skills (que pueden ver a Katrina hablando sobre esto y sobre otras cuantas cosas bien interesantes en esta charla).

Ella ve dos caminos posibles para el rol del tester en el futuro:

#1 – El rol del tester triunfa y subsiste: El rol del tester es el de ese que logra unir todas las piezas de las distintas perspectivas. Los testers que van a triunfar son esos que tengan la capacidad de hablar con la gente de Ops sobre armar un pipeline o un dashboard, hablar con los desarrolladores sobre las pruebas unitarias, cobertura y code review, etc., con los de negocio, etc., y con todos con cierto nivel de entendimiento como para aprovechar esas conversaciones al máximo.

#2 – el rol del tester desaparece: Hay empresas que han comenzado en este camino, como Google o Microsoft. Testing es absorbido por otros roles.  Me recomendó esta charla donde cuentan cómo en el equipo no tienen testers, sino que apuntan a que los desarrolladores tengan skills de testing.

En cualquiera de los caminos, las personas que hoy son testers tienen que aprender a tener conversaciones con distintos roles, aprender más aspectos técnicos de desarrollo de software.

También me recomendó este post que habla que en unos años cualquier niño va a saber programar, así que mejor que hoy vayamos aprendiendo también o vamos a quedar obsoletos. Tenemos que exponernos a esto, y seguro que con nuestro conocimiento sobre testing vamos a poder colaborar en muchos sentidos.

¿Cómo convencerías a alguien para que lea tu libro?

La respuesta de Katrina a esta pregunta fue así: mucha gente está insegura sobre cómo el rol del tester está cambiando. El libro está pensado para compartir ideas prácticas y experiencias de personas de la industria que cuentan cómo se están dando esos cambios y cómo luce el nuevo rol del tester, así como mostrar que el rol aún es valioso cuando esos cambios sucedan en las empresas.

Agile testing quadrants

Este es el cuadrante que Lisa Crispin adaptó. Como Katrina lo nombra en el libro, le pedí me cuente cómo lo suele usar, para qué o cómo se lo explicaría a alguien.

Katrina indicó que no usa tanto los cuadrantes, pero la utilidad es principalmente para generar conversaciones sobre la estrategia. La idea principal es ver que en la estrategia de pruebas haya un balance, tanto de las actividades que hay arriba y abajo, como izquierda y derecha. Con respecto a izquierda vs derecha, la diferencia está en probar que el software funciona vs buscar lo que no funciona o lo que puede salir mal.

Las nubes de las esquinas no son útiles para ella, incluso para mí agregan alguna contradicción, como por ejemplo al querer ubicar la actividad de “code review”, ya que es una actividad con foco tecnológico (abajo) y que da soporte al equipo (izquierda), pero el cuadrante Q1 indica que eso debería incluir tareas automatizadas, y el code review no es automatizado.

Testing en Agile

El problema que ve muchas veces al ir de Waterfall a Agile en cuanto al testing, es que al principio uno no sabe qué es lo que necesita hacer. Algunos usan algún modelo y se atan al mismo, como por ejemplo lo que se apunta en el Definition of Done (DoD). Esto trae el problema que dan una ilusión de certeza sobre lo que hay que hacer, y eso es riesgoso. La gente podría asumir que tienen que seguir haciendo determinadas tareas, incluso si las cosas cambian. Lo importante es no evitar las conversaciones por la falsa sensación de sentirse seguros en cierto modelo, y no querer cambiarlo.
En su caso el DoD es estático, entonces ella observa ese riesgo en ese tipo de equipos.

Katrina trabaja en un banco con distintos equipos, algunos siguiendo Scrum, otros con Kanban y otros Waterfall. En los equipos que siguen Scrum también tienen testers. La calidad es propiedad del equipo, pero igual hay testers. Hay tareas de testing que son hechas por todo el equipo, y además, se discute entre todos cuándo algo está listo para probar, cuándo el testing se puede dar por terminado.

Los criterios de aceptación los escriben los testers durante el sprint, pero son discutidos con el equipo durante el sprint (no se hacen en la planning solamente). El tester tiene que revisar que el criterio sea verificable, pensar en la cobertura, generando una conversación sobre todo esto. De esta forma se puede generar un test plan para cada historia, y hay quienes lo hacen con un mindmap, otros charters, otros ideas de prueba en Jira o en una Wiki, etc. Al fin de cuentas tiene que ser algo que sirva para discutir con el resto del equipo como para ver si su idea de qué probar es completa. En algunos casos algunos testers automatizan. Muchos hacen test exploratorio.

Luego el proceso de release implica hacer un code freeze donde se reserva medio día sobre el final del sprint (en realidad lo hacen por dos horas pero se reservan toda la mañana por ejemplo) y ahí hacen un bug bash. Entre todos los distintos equipos que tienen distintos productos, suman un total de 10 testers. De los 10 testers, 5 se quedan probando lo que trabajaron en el sprint, y los otros 5 miran algo nuevo como para contar con una mirada fresca y otra experiente sobre cada producto, y de esa forma logran asegurar que todo está pronto para liberar. Esa es la “regresión manual” que hacen.

Los testers también miran los logs de la aplicación en producción y conversan con el equipo de soporte, y a partir de ahí agregan nuevos requerimientos o incidentes al backlog.

¿Cómo evitar Waterfall dentro de un sprint?

Ella participó en un equipo donde sucedía eso, que al inicio el tester no tenía nada para hacer, y al final estaba sobrecargado y los desarrolladores no.  Una forma de evitar esta situación es comenzar las conversaciones sobre testing antes de comenzar a codificar. Los desarrolladores necesitan feedback rápido, y la automatización también ayuda en este sentido.

Lo ideal sería mantener al tester y al desarrollador en la misma historia al mismo tiempo, enfocados sobre lo mismo, es la forma de explotar el máximo potencial. Esto se puede lograr si el tester va preparando datos de prueba, automatización (quizá con un enfoque BDD usando Cucumber o similar), preparando las sesiones de prueba, checklists, casos de prueba o lo que vaya a usar para probar. Mientras eso sucede, el desarrollador completa su implementación, y ahí el tester debería ser capaz de entregar feedback rápido como para lograr que ambos sigan trabajando juntos hasta que terminan la historia, ya que si el desarrollador se pone a trabajar en otras cosas, y el tester encuentra algún problema, esa historia ¿vuelve al backlog?

Cerrando

Quedé muy agradecido con Katrina, ya que para poder coordinar una llamada (considerando que entre semana ella no podía por su trabajo) tuvimos que hacerla un sábado de noche en Uruguay, correspondiendo a un domingo de mañana en Nueva Zelanda. ¡Una genia!