Nuestro rol actual está muy lejos de solo diseñar y ejecutar casos de prueba. Ya no estamos para encontrar errores o “asegurar” que estamos cumpliendo requisitos y mucho menos, para romper el software.

Formamos parte de equipos de ingeniería de software, en el que hacemos “code management”, manejamos riesgos e impacto de los cambios para los usuarios, del tiempo, de escala, entre otros… y aportamos herramientas, prácticas y conocimiento necesario para hacer sistemas, aplicaciones y/o plataforma colaborando al máximo con el resto de partes que logramos estos productos/servicios.

Todos entendemos la importancia del código y las actividades de desarrollo pero muchas veces olvidamos el impacto del testing en estimaciones, tiempos de entrega y esfuerzo.

Todos pensamos en cómo vamos a desarrollar una funcionalidad, hacemos levantamiento de requisitos, diseñamos soluciones, validamos en distintas etapas del proceso con nuestros clientes y usuarios; y entonces, por qué no pensamos también en cómo vamos a testear?

También pensamos en buenas prácticas de desarrollo para lograr sistemas más mantenibles; pero, alguna vez pensamos en cómo hacer nuestros productos/servicios (apps, webs, sistemas, plataformas) más testeables?

Pensamos en hacer los procesos de nuestro equipo más eficientes, más allá del testing?

¿Qué actividades deberíamos estar haciendo desde nuestro rol de testers para aportar más valor a nuestros equipos?

En primer lugar, tenemos que desprendernos de esa mentalidad de “rompe-software” para convertirnos en verdaderas fuentes de valor para nuestro equipo requiere bastante de ésto:

Iniciando el proyecto o el sprint

Al inicio del proyecto debemos buscar entendimiento del negocio. Cuál es nuestro producto/servicio y su propósito? qué necesidad queremos resolver? cuál es la industria en la que nos estamos adentrando y sus perspectivas de futuro?

Esto nos permite comenzar a visualizar el “big picture” de nuestro proyecto/producto/servicio y así poder probar mucho mejor.

También ésto nos ayuda a establecer nuestro estándar o filosofía de calidad. qué significa calidad para nosotros? qué significa calidad para nuestros clientes/usuarios?

En algunos proyectos se aplica “cero tolerancia a errores” mientras que en otros se aplica que si está menos roto que ayer, hacemos release. En algunos proyectos podemos hacer releases diarios (como plataformas web), en otros es muy difícil (como software de escritorio). Necesitamos adaptar nuestras prácticas para integrarnos lo mejor posible en nuestro ciclo de desarrollo de software sin sacrificar calidad.

Planificando

Cuando estamos planificando releases o historias/features debemos participar activamente haciendo las preguntas correctas, diseñando historias, definiendo buenos criterios de aceptación de usuario y pruebas de aceptación de usuarios, trayendo sobre la mesa los posibles riesgos y siempre cuestionando nuestros supuestos acerca del producto/servicio/negocio.

En cada iteración

estimamos historias/tareas, monitoreamos las suites de regresión (y todos los tests necesarios) y sus resultados, colaboramos con todo nuestro equipo (managers, desarrolladores, analistas de negocio), escribimos, automatizamos y ejecutamos pruebas, hacemos pair sessions con desarrolladores u otros testers.

Entregas

Monitoreamos el ambiente de producción, y participamos en las retrospectivas.

Sin duda alguna las retrospectivas están entre las reuniones más importantes de nuestro equipo y es nuestra oportunidad perfecta para traer sobre la mesa qué hicimos bien, qué hicimos mal, qué podemos mejorar, qué nuevas técnicas/herramientas/acciones podemos implementar para mejorar la calidad del producto y también del equipo.

Agile Testing for the Whole Team

Este enfoque de Calidad consiste en:

  • No dejamos las pruebas para el final.
  • El equipo resuelve los problemas juntos.
  • Todo el equipo piensa en las pruebas.
  • Todo el equipo está comprometido con la calidad.

Esto significa que el tester no es el único responsable de la calidad, todo el equipo es responsable.

Por supuesto, implica un cambio de mentalidad, ya no estamos aquí para encontrar defectos/errores, ni para “asegurar” que los requisitos se están cumpliendo ni para “romper el software”. Tenemos que preguntarnos “cómo puedo colaborar más y mejor para entregar a usuarios y clientes software de calidad?”.

Entonces ¿cómo agregamos más valor a nuestros equipos y proyectos?

Entendiendo el negocio

Mientras más entendemos el negocio, más podemos entender el producto o servicio, la industria de la que formamos parte, quiénes son nuestros usuarios y qué valor le aporta nuestro producto/servicio a la industria.

Ésto nos permite entender los desafíos que nuestro equipo va a resolver y nos lleva a hacer las preguntas correctas, participar en los procesos de definición y refinamiento de historias y épicas, y constantemente validar con el negocio.

También nos permite cuestionarnos nuestros supuestos.

Entendiendo los desafíos técnicos

Entender los desafíos técnicos nos ayuda a diseñar mejores tests.

Si nuestro proyecto está desarrollado en React y Laravel, debemos entender cómo funcionan. No significa que vamos a saber/entender todo sobre estos frameworks pero sí cuál es la arquitectura, cuáles son las mejores prácticas para hacerlo más testeable y todo aquello que nos ayude a preveer posibles riesgos asociados a las tecnologías que estamos utilizando.

Asegurando que los recursos de testing están disponibles

Ésto no es una tarea sólo del tester. En cada equipo debemos buscar que todos los recursos estén disponibles. Cuentas a servicios, servidores, data y lo que sea necesario de acuerdo a nuestro proyecto.

Planificar actividades de release

Debemos participar activamente en la planificación de releases. Cómo los vamos a testear? Cuándo consideramos que están listos para ser entregados al usuario final? qué dependencias tenemos y cómo gestionamos el packaging de features?

Entrenar, documentar e interactuar con terceros

También tenemos que involucrar al resto del equipo en actividades de testing y sobre todo, traer al equipo el entendimiento de que la calidad es responsabilidad de todos.

Podemos entrenar a otros en actividades de testing (sin necesariamente convertirlos en testers ni requieran gran conocimiento acerca del testing).

Podemos documentar nuestros tests, riesgos y mucho más; de manera que en nuestra ausencia, cualquier otra persona pueda consultar esa documentación y ejecutar actividades en pro de la calidad. Esta documentación también ayuda a que nuestro equipo tenga visibilidad total acerca de cuáles son los tests que aplicamos.

Debemos lograr que todo el equipo piense en la calidad y en qué tests vamos a aplicar en nuestro proyecto/producto. Para esto podemos apoyarnos en los cuadrantes de testing.

Podemos planificar sesiones 1:1 con desarrolladores para conversar acerca de cómo una funcionalidad va a ser probada. De seguro ésto ayuda incluso a mejorar los tests de integración que escriben. También puede darse esta colaboración en sesiones de refinamiento y de planificación en los que se encuentra todo el equipo.

Comunicando constantemente (Visibilidad)

Una de las cosas que más espera nuestro equipo de nosotros es que, constantemente, comuniquemos cuál es el estado actual de nuestra plataforma/app/sistema. También se traduce en Visibilidad. De esta manera podemos cambiar prioridades en función de nuestro estado actual.

Cómo podemos planear mejor?

Haciendo las preguntas correctas al momento de refinar, de planear, de definir cómo vamos a testear y para validar constantemente con nuestros clientes/usuarios si vamos por el camino correcto.

Definiendo mejores Criterios de Aceptación de Usuarios y Tests de Aceptación de Usuarios. Nuevamente, no es una tarea sólo del tester.

Entendiendo nuestros objetivos a corto, mediano y largo plazo. Ésto nos dejar ver del “big picture” de lo que estamos construyendo y cómo aportamos valor a nuestros usuarios/equipos/proyectos.

Participando activamente en la definición y estimación de épicas, historias, tareas. Especialmente la estimación, ya que en muchos equipos es común que sólo se toman en cuenta los esfuerzos de desarrollo cuando estimamos, pero hay muchas otras actividades que realizamos para finalmente entregar esa funcionalidad en producción y todo este esfuerzo/complejidad debe ser tomado en cuenta también.

Cómo hacemos que el equipo se involucre aún más en calidad?

  • Trayendo conversaciones sobre calidad. Qué es calidad para nosotros? cuáles son nuestros estándares? qué estamos haciendo para mejorar la calidad a lo largo de todo el ciclo de software?
  • Tomando las decisiones de calidad en conjunto. No somos los tester quienes tomamos las decisiones de calidad. Debemos involucrar a todo el equipo.
  • Sesiones en pares, con desarrolladores, con otros testers, con la gente de negocio, para maximizar la colaboración.
  • Participar activamente en las retrospectivas señalando aspectos relacionados a cómo mejorar la calidad y el trabajo en equipo. Esta reunión es la ocasión perfecta para proponer ideas, mostrar nuevas formas de trabajo y para reflexionar qué hicimos bien, qué no salió tan bien y cómo podemos mejorar un aspecto a la vez.
  • Trayendo riesgos sobre la mesa.. qué es lo peor que puede pasar?
  • Documentando procesos, casos, cómo usamos determinadas tecnologías o servicios externos.

Conclusión

El mundo ya no necesita más cazadores de bugs.

Eres parte de un equipo de ingeniería de software, estás participando de la creación y mantenimiento de software. Piensa en todo lo que eso implica, mucho más allá de diseñar y ejecutar casos de prueba (y automatizar).

Entender nuestro rol y el valor que aporta a nuestro equipo cambia totalmente la perspectiva de lo que hacemos.

Participar en todas las etapas del proceso de desarrollo de nuestro producto/servicio no solo nos permite ver “el big picture” de lo que estamos construyendo y su propósito, nos ayuda a entender nuestros desafíos técnicos y de negocio, con lo que será aún mayor el aporte que entregamos a nuestros equipos, y nos hace mucho mejores testers.

Nuestro equipos esperan de nosotros la visibilidad permanente del estado del nuestro producto/servicio, sin embargo, otras cosas también tienen muchísima relevancia, como traer sobre la mesa los riesgos, hacer que todo el equipo piense sobre las pruebas y que todos somos responsable de la calidad, no solo los testers.

Involucrarte en cada área del producto te hará mejor tester y mejorará la colaboración y el impacto de lo que hacemos día a día.