¿Cómo revisar tu estrategia de pruebas?

En este post quiero compartir lo que estuvimos conversando con varios equipos de diferentes clientes la semana pasada, que a su vez fue lo que presenté en la charla del meetup de testing en Chile y de Nahual en Uruguay. Tiene que ver con entender lo que se conoce como estrategia de pruebas, viendo por qué es importante planificarlas y revisarlas. Además, estuve compartiendo algunas ideas de qué puede hacer cada uno o cada equipo para mejorar la visibilidad que tenemos como equipo sobre estas estrategias, buscando mejorarla de manera continua.

Material de la Charla

Te comparto también la grabación que quedó de cuando di esta charla en el meetup de Nahual. La particularidad es que por el público al que está apuntado, la bajé bastante de nivel, explicando cosas bastante introductorias, lo cual puede resultar muy útil también.

Estrategia

La estrategia tiene que ver con la dirección que queremos tomar para alcanzar un objetivo. Por otro lado tenemos la táctica, que es el detalle de cómo vamos a poner la estrategia a trabajar, qué herramientas usaremos y cómo. La estrategia tiene una visión más de largo plazo mientras la táctica se centra en el corto plazo y en las acciones. La siguiente imagen tomada de acá me parece que refleja muy bien estas ideas y diferencias.

Algunos errores típicos al respecto son:

• No se planifica la estrategia (falta de dedicar tiempo, pensar que es solo para empresas grandes).
• Se va directo a lo táctico (porque le funcionó al vecino, porque está de moda, etc.).

Lo que nosotros consideramos indispensable es poder tomar un tiempo de manera habitual, no solo para planificar la estrategia sino para revisarla, analizar cuál es el contexto, cuáles han sido los avances, dónde estamos parados y a dónde podemos aspirar a llegar, definiendo los siguientes pasos para acercarnos a ese horizonte.

¿Quién es el responsable de revisar la estrategia de pruebas?

La calidad no puede asegurarse, eso ya lo hemos conversado. La calidad debería verse como una responsabilidad compartida, no es el tester el responsable de calidad ni tampoco el culpable de cuando no hay calidad. Ahora, según cómo yo lo veo, deberíamos ser responsables del testing. Con esto no digo que seamos los que ejecutamos todas las actividades de testing, ya que por ejemplo el testing unitario es una tarea de los desarrolladores. Pero, deberíamos poder brindar información sobre la calidad del producto al que le sirva para tomar decisiones (al PM, al equipo, al CEO, a quien sea). Esto último es justamente la definición de testing. Como testers responsables tenemos que informar sobre distintos aspectos de calidad, considerando diferentes aspectos, incluso la cobertura de las pruebas unitarias. ¿Cómo? Sí, porque eso nos va a permitir tomar mejores decisiones de qué automatizar o qué probar en otros niveles, teniendo una visión más transversal sobre los riesgos y su gestión.

Volviendo a qué es lo que buscamos con el testing, al informar sobre la calidad del producto:

• Contar sobre los riesgos y problemas actuales.
• Informar sobre lo que estamos probando y qué tan bien o mal lo estamos probando (considerando contexto y restricciones).
• Informar sobre lo que no estamos probando (ya que ahí existen riesgos incluso por desconocimiento).

Modelo de estrategia de pruebas

Lo que terminamos haciendo fue un modelo con todos los aspectos que consideramos que inciden en la calidad (en base a lo aprendido en 12 años y más de 300 proyectos ejecutados). Este modelo lo representamos en la siguiente imagen:

El crédito de la imagen se lo lleva Ale, mi esposa, que le di una servilleta con unas líneas sobre la idea que tenía y ella me devolvió este lindo esquema.

El aspecto más importante al que le prestamos atención es la línea de tiempo que hay entre que tenemos una nueva idea o requerimiento y este es llevado a producción, en manos de los usuarios. Eso en Continuous Delivery se lo conoce como “lead time”. Lo que siempre buscaremos es de cómo podemos mejorar esta métrica (que es la que más le importa al negocio). Buscaremos entonces desperdicios, ya sea de tiempo o calidad, qué herramientas podemos incorporar, qué ajustes le podemos hacer al proceso, etc.

Aspectos a revisar frecuentemente

A continuación dejo algunos temas de los que revisamos y que estuvimos compartiendo en la charla. Nada de esto es innovador, simplemente es un listado de aspectos que revisamos por su importancia y porque muchas veces se dejan de lado.

Objetivos:

• Conocer la empresa, proyecto y/o producto así como su planificación y objetivos. Tener una visión compartida de hacia dónde vamos.
• Conocer problemas actuales, riesgos, principales preocupaciones.
• Conocer criterios de calidad, exigencias, regulaciones, estándares a cumplir.
• Cuál es la sensación de calidad de los clientes y cuál es la del equipo.

Equipo:

• Conocer cómo esta conformado el equipo, cómo son sus interacciones, qué tal es la relación y qué tan unido está.
• Conocer roles y skills de los miembros del equipo.
• Conocer la metodología de trabajo para el desarrollo del producto (Scrum, Kanban, XP, Cascada, etc.).
• Conocer la participación del equipo en las distintas instancias de desarrollo.

Shift left testing:

• ¿Qué tan temprano se involucra testing en los requerimientos?
• Trazabilidad entre testing, desarrollo y requerimientos.

Shift right testing:

• ¿Qué tanta información de producción obtenemos para mejorar el proceso? Por ejemplo, revisamos los errores que obtienen los usuarios, los logs, la monitorización, análisis de qué tanto usan cada parte del sistema los usuarios, etc.

Estrategia de testing funcional:

• No dividir entre “testing manual” y “testing automatizado”, sino definiendo una estrategia de testing que tenga una visión más completa del testing, pensando en qué ejecutamos en forma “manual” y cómo nos apoyamos en la automatización en las diferentes capas.
• Revisar la aplicación de heurísticas de testing.

Pruebas no funcionales:

• Revisar cada uno de los atributos de calidad y cómo lo estamos probando, para lo cual recomendamos revisarlo en base a la norma ISO 25010.
• En particular por ejemplo, analizar si es necesario realizar pruebas de accesibilidad.

Entornos y plataformas:

• Revisar el uso de ambientes y entornos de pruebas. Analizar si todos conocen el objetivo de cada una y si hay algo para mejorar.
• Analizar cuáles son las plataformas desde donde acceden los usuarios (usando Google Analytics o revisando logs) y lograr que en testing se utilice lo más similar posible. Para esto se pueden usar diversas plataformas online como Saucelabs o Browserstack.

Calidad de código:

• Darle visibilidad a la gestión de código, la estrategia de branching, etc. Esto es útil para estar alineados en cuanto a los riesgos que hay en esta gestión.
• ¿Se realizan pair-reviews o pair programming?
• ¿Se utilizan herramientas de verificación estática de código, tal como SonarQube? Revisar estrategia para gestionar deuda técnica.

CI/CD:

• Dar visibilidad a la estrategia en cuanto a CI/CD es fundamental para que todos estén alineados, entiendan para qué sirve y que todos aporten en cómo mejorar el proceso.

Y hasta acá el modelo, lo que revisamos, lo que sabemos que tenemos que revisar. Luego está lo más complicado que es pensar en lo que no sabemos que no sabemos. Para eso en la charla planteé varias estrategias, entre otras desarrollar nuestro pensamiento crítico.

También te recomiendo revisar los posts que he armado con diferentes dinámicas para darle visibilidad a la estrategia de pruebas y discutirla con todo el equipo, por ejemplo:

• Dinámica basada en los agile testing quadrants.
• Dinámica llamada test strategy retrospective.
• Requirements journey map.
• Dinámica basada en matriz de riesgo.

Cerrando

Esto fue solo un resumen de los aspectos más importantes de la charla. Próximamente estaré compartiendo este mismo contenido en formato de webinar. Para eso te recomiendo seguir la cuenta de Abstracta Tech Talks, donde estamos organizando diferentes charlas online sobre diversos temas alrededor a la calidad de software.

Me gustaría saber si tenés la costumbre de revisar estos aspectos de forma periódica, o incluso, qué otros aspectos considerás que debería agregar al modelo. Animate y comentá.