Puede que en el nombre del movimiento este el problema: Dev y Ops, desarrollo y operaciones, lo cual tiene a poner a nuestras amigas QA(*) fuera del radar de esta tendencia, pero a poco de pensarlo bien debemos darnos cuenta de que ya están ahí… si es que hacemos las cosas adecuadamente, me explico.

Se espera que el software que desarrollamos y que se entregue tenga calidad (y ojo, no nos olvidemos que la calidad no es negociable) así que entra en acción el proceso de QA, tests, ratificación o ya en plan sofisticado “certificación”, pero lamentablemente en la gran mayoría de los casos estas pruebas se efectúan al final de cada etapa de desarrollo, a veces en un entorno dedicado, a veces en preproducción y otras (felizmente muy pocas) en el propio entorno de desarrollo, volviéndose un ejercicio incremental, pues como en cada ciclo o iteración de desarrollo se añaden nuevas funcionalidades (con suerte Historias de usuario) el equipo QA tiene que probar todo, incluyendo lo que se probo hace unas semanas, no vaya a ser que se caiga en una de las temidas “regresiones” y algo ya validado deje de funcionar.

Ah, ¿y se han percatado que dije “equipo QA”?, ¿no les causa ruido? pues esto es indicativo de que ese proceso esta vinculado a personas diferentes a la labor de desarrollo, asi que de generar sinergias ni hablar.

Pues si, lo usual, incluso en equipos que se denominan “agiles”, pero como bien nos recuerda Javier Garzas no se puede ser agil si se prueba en cascada, pues lo que hemos descrito anteriormente es efectivamente un proceso en cascada lo cual nos lleva a algo que tenemos asumido desde hace tiempo (y es parte de la raíz de este modo de trabajar en QA): el “ritual” del pase a entornos: descarga de ultima versión (si es que todo esta bien sincronizado), separar los archivos modificados, asegurarse de que los archivos de configuración este Ok, copia de archivos, reiniciar entornos… etc, y si el pase es a producción ya mejor ni hablar: gran amanecida bailable con desayuno incluido.

¿ Y del lado de QA esta forma de trabajar como les afecta? Simple: el entorno donde probar no esta actualizado de manera frecuente, asi que hay un gran delay entre el tiempo en que Desarrollo entrega nueva funcionalidad o corrige bugs y el que QA puede “verlos”, eso de manera evidente. Pero aun hay mas, como mencionaba al principio la validación es manual e incremental dándose el caso que vi de una QA que en cada iteración debía validar la aplicación contra una tabla de valores para verificar que los resultados siguieran siendo los esperados ¿no habría una forma de reducir el trabajo repetitivo de tal manera que el esfuerzo de las pruebas inevitablemente manuales se centre en las nuevas funcionalidades y lo que respecta a la validación de usuario?

Si que la hay, y ya hemos hablado frecuentemente de ello, tender a la Integración y Entrega Continua, buenas practicas (vitales del movimiento DevOps a fin de entregar valor constantemente) que facilitan y a la vez requieren el tener pruebas automatizadas que se ejecuten frecuentemente, acotando lo manual a lo necesario, pero mas aun: facilitando el que se caigan las barreras entre QA y Dev al generar (¡al fin!!!) equipos multidisciplinarios (y no bandos en pugna **) que se den feedaback periódicamente.

Pero aun hay mas, y esto nos lleva al titulo de este post, el escenario DevOps abre una gran oportunidad para QA de asumir liderazgo en este proceso, pero para lo cual algunas cosas deben de cambiar (como nos indica el enlace anterior):

Empoderar a QA para que recomiende o determine las herramientas (de automatización y pruebas)
Que QA migre a una mayor estrategia de tests
Dar a QA una mayor visibilidad dentro de la hoja de ruta
Cambiar QA a un enfoque mas productivo que reactivo
Permitir a QA evangelizar y educar en DevOps

Pero si, este cambio no es fácil, estamos hablando de una “cultura” ya establecida, que si ya nos esta costando evolucionar en tanto a la adopción del agilismo, por el lado de la forma de trabajar con QA existen retos diferentes:uno el trabajar como departamento separado, lo cual como recordamos anteriormente nos aleja del desarrollo de sinergias, pilar de lo que es DevOps;  por otro lado el hecho de que buena parte de quienes trabajan en QA se acercaron a dicha área porque de esa manera no tendrían que programar, si, esa es la verdad y es una pena, pero buena parte de la automatización de pruebas requiere habilidades de programación y esto es algo que ha venido para quedarse; y finalmente el factor económico, se asume erróneamente que introducir a QA desde la concepción del proyecto es un error por el costo que esto implica (asumiendo de partida que las pruebas se harán “al final”), siendo que el costo de tratar de corregir la falta de calidad en estadíos tardíos es mucho mayor que el que involucra trabajar con pruebas y alcances claros desde el principio.

El reto esta puesto, QA es totalmente necesario para lograr sinergias y entregar valor desde el principio, tal vez el propio nombre “DevOps” no ayuda a recordar que QA es parte del proceso, pero si que lo es, sin esa vital pieza no tenemos la figura completa. Espero sus opiniones para ver como podemos mejorar este proceso.

Referencias adicionales:
Los equipos modernos de desarrollo son multifuncionales, así disparan la velocidad y la productividad
Cuándo deberías hacer los pasos a producción dentro de un Sprint o iteración

(*)Si, en esta profesión tan bonita que es la informática se da el fenómeno que el sector de QA es terreno femenino en su gran mayoría, pero eso da para otra historia.

(**) Un QA tenia en su estatus la siguiente frase “Todo QA debe tener un corazón de desarrollador, guardado en un frasco”