Cuando trabajamos con un área de QA que es global y transversal, es muy importante la realización de una buena planificación y organización para poder dar soporte a todos los proyectos en los que nos vayamos a involucrar.
Las personas que engloban el área, tienen que tener claro donde van a trabajar y en que momento van a pasar de un proyecto a otro. Esto les sirve para planificarse, rebajar incertidumbre y poder centrarse mucho más rápido en lo que van a realizar, si no existe esto, la persona, acabará perdiendo el foco y se sentirá que está dando bandazos.
Dependiendo de la manera de trabajar, podemos encontrarnos, con varias situaciones.
Por ejemplo, si estamos trabajando en un proyecto donde cada equipo realiza sus propios ciclos de trabajo, enfocados en un modelo más en cascada, es imprescindible que el equipo de QA, tenga una visión transversal de todo lo que sucede, para que cuando, le llegue el trabajo, pueda ofrecer lo mejor de si mismo. En este modelo, que no es el más adecuado, el ciclo de pruebas, comienza al final del todo, imposibilitando cualquier reacción ágil si encontramos un problema crítico o grave. Una posible solución, es que, desde desarrollo, vayan entregando funcionalidades o secciones, según vayan terminando, de esta manera, podremos jugar mejor con los tiempos.
En otro modelo, todos trabajan en el mismo ciclo o sprint, de esta manera, vamos de la mano y probando todo lo que vayan soltando desde desarrollo o desde el área que aplique y mientras unas personas realizan su trabajo, nosotros podemos comenzar a realizar los casos de prueba o involucrarnos en la realización de BDD y testing de integración. El modelo más eficiente y el que mejores resultados me ha dado es el de ciclos de tres semanas.
También, como bien comentaba anteriormente, puede existir la posibilidad de que el área de QA sea transversal e independiente, de esta manera, podemos dar soporte a varios proyectos a la vez, sin tener perfiles involucrados. Esto es bueno, ya que los picos de trabajo se pueden solventar entre todos, pero es menos eficiente de cara a interactuar en los proyectos y trabajar mano a mano con el resto de personas. Cada punto y cada manera de trabajar, tiene sus partes positivas y sus partes negativas.
En este caso, es totalmente imprescindible tener una planificación independiente y única para el área, añadiendo todos los proyectos y viendo si no existen solapamientos de perfiles y de entregas que supongan que se produzcan cuellos de botella.
Si el equipo es lo suficientemente grande como para asumir varias entregas a la vez, contaremos con la ventaja de que existirá apoyo entre diferentes personas y podremos sacar las pruebas mucho más rápido que si cada perfil se encarga de una única cosa. Además, se podría aventajar con dos perfiles realizando pruebas manuales y a la vez automatizando.
Otra ventaja que tiene este formato, es que, si la detección de defectos es muy grande, la reprueba de los mismos, va a ser mucho más rápida, ya que podemos poner a varios perfiles en paralelo, trabajando en ello y a la vez, realizando pruebas exploratorias y de humo, para cerrar completamente la entrega.
En estos modelos de trabajo, se reduce los posibles picos individuales, pero se aumenta el distanciamiento con el resto de personas de la organización, ya que no ven al perfil de QA, como alguien cercano a ellos y que está trabajando mano a mano.
También contamos que la planificación va a ser un poco más compleja, porque tenemos que ver con antelación los huecos libres de los perfiles del área, para realizar los casos de prueba o escribir los test en Gherkin, por ejemplo. En estos casos, puede ser que nos pillemos los dedos y nos encontremos con que estamos más apretados de lo que nos esperábamos.
Lo que, si que tenemos que tener muy en cuenta, es que el esfuerzo de persecución que se debe de hacer para que las entregas estén en fecha y que se realicen planificaciones certeras desde los proyectos, tiene que ser muy alto. Por ello, debemos de ser nosotros mismos, como líderes del área o tener un perfil casi en exclusiva, que se dedique a esta labor y, sobre todo, hacer entender que las pruebas son el núcleo central del proyecto y que, sin ellas, seguramente acabará desmoronándose.
0 Comentarios