Cuando el tester es transversal

Hoy, como en muchas cosas, uno tiene que intentar tener conocimientos de todo lo que pueda, tiene que intentar empaparse de cualquier cosa que pueda y en nuestro trabajo no podía ser menos.











Cuando tenemos un proyecto en el que hay varios equipos y en cada equipo tenemos un tester (o varios) al final esa persona será especialista en exactamente lo que se dedica ese equipo y dejará un poco de lado el resto.



Para evitar esto hay varias medidas que podemos tomar, una de ellas, que exista un departamento de testing en el que un grupo trabaje mano a mano indistintamente de los equipos de desarrollo, cuando llega algo para probar, lo podrá coger cualquiera de ellos.



Este método, desde mi punto de vista tiene un pero, que la gente que pruebe será "menos" especialista en una cierta zona de la aplicación y puede no tener toda la información.



Otra medida que se puede tomar es que cada cierto tiempo, el tester se mueva de equipo, hacer rotaciones, así no se cogerán malos hábitos, costumbres y se podrán tocar todos los palos para probar. El pero de esta "técnica" es la falta de "confianza" con el equipo, el trastorno de estar cambiando contantemente de posición y el "jet lag" que suponen estos cambios hasta que se acostumbra al tester a lo nuevo.



Para mi la mejor solución, aunque muchas empresas sean reticentes a nivel económico, sobre todo, es que exista un tester transversal.



Cada equipo tiene su propio tester, que probará y será un experto en esa zona, teniendo conocimientos de las otras zonas pero mínimo. Como apoyo para estos tester, existir.a un tester transversal (o varios) que irán de equipo en equipo dependiendo de las necesidades y de la carga de trabajo, apoyando a los tester "fijos" y ayudándoles en su trabajo.



Estos tester tendrán toda la información global de la aplicación y podrán ayudar al resto sin ningún problema. Cuando acaben con ese pico de trabajo puntual, irá a otro equipo ayudando y gestionando el trabajo en base a la pila pendiente que tenga.



De esta manera podremos tener un trabajo constante en todos los equipos de desarrollo y se podrán apoyar unos a otros para que, entre otras cosas, no existan diferencias de horarios, que unos equipos tengan menos trabajo y otros estén saturados y no estén apoyados entre si.



Al final, cada proyecto tendrá su propia filosofía y sus propias ideas para hacer testing de la mejor manera, pero creo que estas ideas se pueden aplicar siempre a practicamente todos nuestros grupos de trabajo.

0 Comentarios