Frecuentemente escucho preguntas como:
“¿Si el equipo tiene un solo tester y se va de vacaciones o por un asunto médico, o por cualquier razón, está bien que el equipo haga un release sin que estemos nosotros?”
“¿Si en un squad el analista de calidad sale por vacaciones, enfermedad o cualquier razón por un período de 2 semanas, y el squad necesita hacer entregas, sugieren que los devs puedan hacer pruebas funcionales en el ambiente de calidad?”
Esto se apoya en afirmaciones tales como:
“Si bien es un equipo multidisciplinario, solo los analistas de calidad tienen la experticia necesaria para este rol.”
Y sí, somos los testers quienes tenemos la experticia para realizar pruebas, pero has pensado en los miles de equipos de desarrollo que no tienen testers dedicados al rol de testing? Qué hacen distinto esos equipos? por qué no tienen testers y aún tienen productos/servicios que entregan regulamente a sus clientes/usuarios?
¿Alguna vez te has cuestionado si el testing es un rol o una actividad?
Para la mayoría de los testers, el testing es un rol, diseñamos, planificamos, ejecutamos pruebas, medimos resultados, hacemos informes, mantenemos al equipo informado del status del proyecto (producto/servicio), trabajamos con desarrolladores y equipo de producto, también automatizamos y documentamos, pero… ¿somos los únicos que podemos testear?
¿Podemos separar el testing como rol del testing como actividad?
Sin duda, SI! otros miembros del equipo pueden testear! Y yo pienso que ese es el estado ideal de los equipos, pero qué necesitamos para que eso sea posible:
En primer lugar, el equipo completo debe estar comprometido con la calidad y eso implica que entre todos decidimos/establecemos cuál es nuestro estándar de calidad? qué significa calidad para nuestro equipo?
Estar comprometidos con la calidad nos lleva a:
- Todo el equipo sabe qué, cómo y cuándo testeamos; y no significa que saben al pie de la letra cada detalle, pero sí que saben qué suites vamos a correr en cada release, si es que hay o no una suite automatizada de regresión, si es que hacemos testing de performance, o de accesibilidad… y ¿cómo las corremos si el tester no está y cómo vemos el informe a ver si algo falló y lo tenemos que arreglar?
- Debemos documentar adecuadamente nuestros casos/escenarios de prueba.
- Debemos documentar nuestros procesos de testing (plan y estrategia de testing, ciclos de testing).
- Debemos automatizar todo lo que podamos, y si no sabemos de código, hoy día hay muchas herramientas low code con los que podemos automatizar nuestras pruebas. También podemos hacer que las pruebas corran en pipelines automáticamente y así, nadie tiene que activar la corrida de los tests de forma manual.
Imagina que estás de vacaciones 2 semanas y nadie del equipo puede hacer un testing manual ni correr pruebas automatizadas, qué hacen? no van a producción porque el tester no está? y si renunciamos y somos el único tester del equipo… no hay más entregas hasta que un nuevo tester se una al equipo y se adapte a la empresa/proceso y obtenga el conocimiento suficiente sobre el producto para poder contribuir activamente?
Definitivamente NO! no es el proceso que queremos implantar en ningún equipo/proyecto/organización. No podemos convertirnos en un cuello de botella, especialmente si trabajamos en una startup o equipo ágil en el que queremos entregar cambios a nuestros clientes y usuarios lo más pronto posible y recibir feedback lo más pronto posible.
¿Cómo logramos que todos participen de las pruebas?
Todo el equipo debe saber cómo, cuándo y qué testeamos. Y de ese proceso (de decidir qué pruebas se aplican) debería participar todo el equipo. ¿qué tipos de prueba hacemos? quién las implementa y diseña? con qué frecuencia las aplicamos?
La documentación es importante, ten siempre actualizados los casos, escenarios, plan y estrategia de prueba. Si te ausentas 2 semanas y hay que hacer entregas, tienen los desarrolladores/gente de producto de tu equipo el acceso a tus herramientas de manejo de casos de prueba para consultar los casos de prueba (en los que describes cómo probar cada caso: precondiciones, acción y resultado esperado)? dejaste una suite con las pruebas que se deben correr para comprobar que podemos entregar a los clientes/usuarios con confianza esta nueva versión del producto/servicio? El resto del equipo debe saber qué buscar y dónde para poder aplicar las pruebas.
Ahora imagina algo aún mejor: Lograste crear/actualizar todos los casos de prueba necesarios para los tickets/historias/requerimientos en el sprint actual cuando aún el ticket estaba en To Do o In Progress, y el desarrollador puede ver los casos de prueba (que adjuntaste en el ticket) y puede correr esas pruebas localmente (antes de subir sus cambios y pedir un Code Review y antes que lleguen a Testing). Si logras ésto, créeme que vas a lograr reducir un montón los errores que descubrimos mientras testeamos. Si encontramos algún error, va a ser algún caso que no contemplamos al principio o un caso de muy baja probabilidad de ocurrencia o de muy baja severidad, y el proceso va a mejorar para todo el equipo.
Imagina que tenemos un release de emergencia, y tenemos solo 2 horas para probar y la suite de regresión (que corremos manual) tarda 2 días en ejecutarse (por una sola persona), si tienes casos/escenarios bien documentados, podemos dividir los tests/escenarios entre todos los miembros del equipo (priorizando los más importantes) y así en 2 horas podemos ir a producción (porque a todos nos importa por igual la calidad).
Si tenemos suites automatizadas, podemos correrlas con frecuencia (no solo cuando estamos en medio de un release), quizás una vez por día y podemos capturar rápidamente si rompimos algo en el release o si un API dejó de funcionar en cualquier momento, si el sistema está muy lento, y así, muchos escenarios más.
Involucrar a otros miembros del equipo también ayuda a que todos entiendan mejor por qué no completamos la regresión en 15 minutos y que no estamos nada más esperando a que las features estén listas para ser testeadas. Hay mucho detrás del testing: planificar, documentar, buscar información, escribir pruebas, generar informes, estar preparados en todo momento. Y si agregamos estas acciones que describí antes, vamos a convertirnos en un equipo que avanza más rápido sin sacrificar calidad y te aseguro que podemos hacerlo si le damos a nuestros equipos las herramientas adecuadas.