En el post de la semana pasada (¿Para automatizar pruebas necesitas saber programar?) hablaba de que en mi opinión, para automatizar pruebas son necesarios conocimientos de programación, en concreto tener muy claros los requisitos que implica la automatización de pruebas y programar código mantenible.
¿Pero qué pasa si en mi equipo queremos empezar a automatizar pruebas, pero todos los testers son manuales? ¿Y si no quiero contratar a un equipo exclusivo de automatización de pruebas? ¿Y si veo interesante que los testers manuales también automaticen? ¿Cómo empezamos?
Habiendo pasado por alguna situación similar, en este post voy a darte algunos consejos y explicarte qué es lo que mejor me ha funcionado para gestionar este tema, y fomentar la creación de perfiles mixtos (automatización y manual).
Este post es pura opinión mía, y como siempre digo, cada situación es un mundo distinto. Por ello, si también has vivido algún caso parecido, te animo a que cuentes tu experiencia en los comentarios del post. ¡Vamos allá! 🙂
Lo primero es sentar las bases de la automatización de pruebas
En primer lugar, por los motivos que mencioné en el post de la semana pasada, te aconsejaría que al menos contrataras a una o varias personas especializadas en automatización de pruebas, que sienten las bases de la automatización a nivel de programación.
Estas personas empezarán a formar el equipo de automatización de pruebas (paralelo al manual) y se encargarán de, entre otras cosas:
– Elaborar de un framework que dé soporte a las pruebas automáticas (reportes, logs, librerías necesarias, mecanismo de paralelización de los tests etc.).
Además, estando en el caso de que queremos que el resto del equipo participe en la automatización pero no saben programar, os aconsejaría que crearais un framework que permita automatizar casos de prueba de la forma más simple posible (para ir introduciendo a los testers en la automatización progresivamente), por ejemplo, mediante palabras clave (lo que se llama keyword driven, en este mundillo).
Digamos que la gente con más conocimientos de programación se encargará de crear “métodos” a nivel de código, que programen funcionalidad compleja y común: un login con comandos de Selenium, rellenar un campo de un formulario, una llamada de API, un paso en una prueba de integración, etc. y dichos métodos o palabras clave podrán utilizarse para construir un caso de prueba automatizado (cosa que pueden hacer los testers con menos experiencia de programación).
Otra buena técnica es que el framework sea dirigido por datos (Data Driven). Los datos se abstraen de los tests (incluso se pueden meter en ficheros aparte), y así (además de otros beneficios que tiene tener un data driven framework) gente con pocos conocimientos de programación insertando nuevos datos, nuevas combinatorias en dichos ficheros, puede construir casos de prueba.
– Estas personas expertas también se encargarán de gestionar una buena infraestructura que permita escalabilidad y buenos tiempos en la ejecución de pruebas.
– Abstraer al máximo el código, los datos, realizar un buen diseño de pruebas automáticas.
– Parametrizar lo máximo posible el framework, los tests, para que de forma sencilla podamos ejecutar los tests en distintos entornos, navegadores, etc. sin cambiar el código.
– Refactorizar el framework y el código: imprescindible para que el código sea mantenible con el tiempo, y más necesario incluso en el caso que tratamos en el post, con mucha gente con pocos conocimientos de programación.
– Y algo muy importante: estas personas expertas deben mentorizar y enseñar poco a poco al resto de testers a automatizar, a crear código mantenible.
Mentoring y colaboración
Una vez que ya estén sentadas las bases de la automatización de pruebas (el framework, la infraestructura, las tecnologías a utilizar), o incluso a la par que se van desarrollando, hay que hacer una labor de mentorización personalizada para esos testers manuales.
Debemos introducirles en el mundillo de la automatización, de la programación, a la par que continúan con sus pruebas manuales, para que poco a poco vayan adquiriendo ese perfil mixto de automatización y manual.
Digo mentorización personalizada, porque muchas veces los propios testers tienen distintos niveles de conocimiento. Unos habrán tocado algo de programación en la carrera, puede que algunos hayan utilizado alguna herramienta de record & play, incluso habrá otros que no les guste programar. Habla primero con ellos para saber sus intereses y conocimientos de partida, en función de eso, podrás ir asignándoles distintas tareas de automatización, a distintos niveles.
En muchas ocasiones a ciertos testers les motiva aprender a automatizar pruebas e involucrarse en el equipo de automatización. A día de hoy, suele verse como una mejora personal y profesional, ya que muchas ofertas de trabajo de tester piden saber automatizar pruebas.
Como áreas de mentoring te aconsejo:
– Enseñarles a programar progresivamente, en los lenguajes de programación que se vayan a utilizar para automatizar. Yo aconsejaría un lenguaje orientado a objetos, más entendible, con abstracciones a nivel del mundo real, y haría mucho hincapié en enseñar buenas prácticas de programación.
– Enseñarles a utilizar librerías sencillas de automatización que emplee el framework, con palabras clave y que empiecen a automatizar pruebas pequeñas y simples, para que se sientan motivados y quieran aprender más.
– Enseñarles a utilizar el control de versiones, el entorno de desarrollo: IDE, Maven si lo utilizas, instalar la JDK… Todo de forma sencilla y práctica, solo lo necesario para empezar a trabajar.
– Involucrarles y enseñarles el proceso de desarrollo que sigue el equipo de automatización: forma de trabajo, control de versiones, política de ramas, flujo de trabajo (p.e: cuando cojo una historia de usuario de automatizar un caso de prueba tengo que crear una rama, programar el código, probarlo, que lo revise un compañero…etc.).
– Pair reviews, revisiones de código con el mentor, antes de integrar el código de los más juniors con el resto. Para mí es una de las mejores formas de aprender, tanto el que revisa como el que ha hecho el código. Otra persona puede detectar fallos a nivel de programación, puede indicarte cómo modularizar mejor el código, asegurarse de que se siguen los estándares de codificación…en definitiva, así promovemos que los «testers programadores» juniors aprendan buenas prácticas y fomentamos que piensen las soluciones y porqués antes de programar.
– Pair programming (actividades de programación conjunta del mentor con el alumno) y mucha colaboración. Para mí la mezcla de tester manual y automático es muy bueno, chocan distintas visiones y a alguien se le pueden ocurrir cosas que a otros no.
Dentro del plan de aprendizaje que definamos para cada tester, iremos involucrándoles en tareas de automatización de distinta forma: a veces automatización de casos de prueba sencillos, interpretar reportes, generar nuevos casos de prueba a través de nuevas combinatorias cambiando los datos de los ficheros del test, con palabras clave, test automáticos + peer reviews, etc. Hasta que finalmente llegue el día en el que dicha persona incluso se atreva a programar nuevas funcionalidades complejas, aquellas que abstraemos mediante palabras clave.
Terminando…
Estos son consejos de cosas que me han funcionado, pero lo mejor sin duda, es ver lo que quiere cada tester manual, sus inquietudes, dificultades, y aprender y mejorar el proceso de mentoring cada vez, con el feedback que se va recogiendo de ellos y los resultados que se van obteniendo.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Tan claro y lógico y tan lejos de la realidad cuando la vocación brilla por su ausencia en el mercado.
Muy buen post.
Trabajo hace 10 años en testing, en las últimas 3 empresas que estuve se quiso automatizar y nunca se pudo, por desgano, porque nadie se quiere hacer cargo, no se sabe por qué. Yo realizo testing manual y por el momento me va bien, no necesito automatizar. Para mí la automatización sirve para hacer pruebas de smoke, el resto tiene que ser manual porque siempre el cliente quiere cambiar algunas cosas. El problema que el perfil de un tester de automatización tiene que se desarrollador, y los desarrolladores no quieren testear, quieren desarrollar, creo que ese es el problema que hay, entonces no hay gente que lo haga. Igual como dice, solo sirve para smoke, o sea, un 10 o 20 % de los casos de prueba que uno diseña, el otro 80 o 90 % de los casos de pruebas se hacen manual
Saludos!!!
Hola fernando mas claro no lo pudiste decir
Hola Fernando, actualmente estoy interesandome por la automatización de pruebas sin embargo en mi empresa no hay nadie que pueda mentorear. Solo desarrolladores y testers manuales. Hay algún curso que recomiendes para llevarlo de manera autodidacta?