Acelerar el release sin comprometer la calidad?

En el desarrollo de software, la cadencia de las liberaciones puede decir mucho de una empresa de tecnología. Salvo varias excepciones donde nuevas versiones deben ser liberadas en fechas muy específicas; muchas empresas deciden adoptar una frecuencia de liberación de cada dos semanas para alinearse con la duración más común de los sprints en Scrum.

Si el último caso describe tu forma de trabajo, este post es para ti! Aquí hay una lista de recomendaciones enfocada a las actividades que como QA, puedes llevar a cabo para lograr una cadencia de dos semanas y no sacrificar tanto la calidad.

DOD (Definition of Done) debe ser claro para todos

Si no está claro para ti y para todo el equipo, acelerar el proceso de liberación simplemente no será posible…. y de suceder sí que se sacrificaría calidad en el proceso. Recuerda que la DOD es un acuerdo de todo el equipo de lo que para ustedes significa terminado. Es muy importante recordar también que “terminado” puede significar muchas cosas, como QA una de tus funciones siempre será velar por que la calidad sea parte de esta definición, por ejemplo como el cumplimiento de los criterios de aceptación.

En algunos equipos el DOD de las historias de usuario significa contar con cambios probados listos para UAT, mientras que en otros equipos el UAT podría ya estar considerado. He aquí la importancia de tener esto claro y bien comunicado con todo el equipo.

Estrategia de pruebas calidad compartida y que favorezca los releases

Si el DOD es claro, ahora es tiempo de establecer una estrategia de calidad compartida en la que participen todos. Si la estrategia de calidad no considera el DOD debes ajustarla junto con tu equipo hasta estar alineados.

La estrategia de calidad debe apoyar a que la última fase de validaciones sea lo más ágil posible. Aquí no hay una receta y dependerá mucho de como trabaje tu equipo, el área de desarrollo, DevOps y los recursos de infraestructura que tengas a tu disposición. Aquí algunos puntos que podrían ayudarte:

• La estrategia de calidad no solo incluye las pruebas. La etapa de análisis y definición debe proporcionar un entendimiento claro a todo el equipo, si esto no se da, propón cambios en cómo se formulan y analizan las historias de usuario (te recomiendo BDD). Ah y también es bueno no descuidar el tamaño de las historias, entre más pequeñas sean, mayores las posibilidades de concluirlas a tiempo.
• Las pruebas manuales son muy importantes pero toman tiempo, así que define claramente desde el principio cómo las llevarás a cabo. Empleando BDD se generan escenarios claros de manera colaborativa asegurando el entendimiento y participación de todo el equipo.
• Contar con pruebas de regresión automatizadas es una de las mejores inversiones que puedes hacer, considera la pirámide de pruebas como un patrón de referencia; éste indica que el mayor esfuerzo en validaciones automatizadas debe suceder en las pruebas unitarias, seguido por las pruebas de integración y finalmente las pruebas end2end que utilizan la UI.
• La estrategia de calidad debe ser algo que todo el equipo comparta, el ideal es que los desarrolladores realicen tantas pruebas unitarias como sea posible, que QA y desarrolladores compartan la creación de pruebas de integración y finalmente que QA elabore pruebas end2end de los flujos más críticos.
• Encuentra el balance, no todo puede ni debe de ser automatizado, piensa en lo que más se repite, en lo que demora más tiempo o en volumen. Recuerda que las pruebas manuales ayudan a liberar las nuevas features más rápido; las pruebas automatizadas solo reemplazan el esfuerzo manual de las pruebas de regresión incrementando la confianza en el release.
• Liberar sin bugs pendientes de resolver, es algo que todo QA comprometido busca, sin embargo esto no siempre será posible. Busca que la DOD refleje que tipo de bugs deben ser resueltos para considerar una historia de usuario completa, clasifica los bugs por tipo, criticidad, o algún otro atributo que te haga sentido, como el módulo de negocio al que pertenece. Los defectos de baja criticidad pueden ser corregidos en la siguiente iteración; recuerda que ser ágil significa que puedes cambiar y mejorar en cada nuevo ciclo, no que lo harás necesariamente más rápido o con cero defectos.

Ambientes de prueba

Sin importar como establezca tu DOD, el trabajo con los ambientes de prueba, es clave para lograr agilizar el proceso de liberación. De nuevo, esto dependerá de cómo el área de tecnología defina, sin embargo deberías contar con al menos un par de ambientes de prueba compartidos; uno para ejecutar pruebas de integración donde valides los cambios concurrentes de varios equipos, o donde por ejemplo; ejecutes las suites automatizadas de regresión. Además de otro ambiente compartido para las pruebas de usuario. La diferencia entre ambos estriba usualmente en los datos qué hay para probar. Aquí hay algunos aspectos a tomar en cuenta:

• El proceso de desarrollo debe tener establecido cómo es que estos ambientes aceptarán los nuevos cambios.
• La sincronización de ambientes es muy importante. Siempre debes saber que estás probando, la versión, el último cambio en el repositorio o un fix de última hora. Si no es claro sobre qué versión realizas las pruebas, puedes encontrar falsos positivos, generar confusión y finalmente pérdida de tiempo.
• Configuraciones, recursos y performance, comunica siempre a DevOps cualquier incidente relacionado con esto. Es muy común consumir tiempo innecesario lidiando con este tipo de incidentes de última hora, involúcrate en estas situaciones tanto como te sea posible para conocer cómo funcionan estos ambientes ya que tú eres uno de los principales actores del proceso.
• Avanza mientras duermes, aprovecha al máximo los ambientes que tienes para ejecución de pruebas automatizadas, elige horarios en donde la demanda sea baja o nula, por ejemplo mientras todos duermen; esto puede no ser tan sencillo con equipos distribuidos en diferentes zonas horarias. Programa ejecuciones que avancen el trabajo y retoma los resultados al día siguiente.

Bonus: Pruebas en Producción

No soy un gran fan de esto, sin embargo hay valor en llevarlo acabo para brindar confianza de que todo funciona como se esperaba. En el ideal, si todo el proceso de desarrollo fue llevado a cabo correctamente, no debería ser necesario.

Entonces que probar? Cómo plantear estas pruebas?:

• Identificar las áreas más sensibles o de mayor riesgo desde la perspectiva de negocio y haz un checklist basado en eso.
• Plantear validaciones simples que no modifiquen datos productivos, si esto no es posible, debes evaluar la creación de cuentas y datos de prueba en producción. Esto puede ser especialmente complicado en aplicaciones que realizan transacciones bancarias, pagos, etcétera.
• Es mejor monitorear que probar; monitorear proactivamente producción en todo momento mediante pruebas cortas y muy específicas es llamado synthetic monitoring o synthetic tests. Evalúa si esta estrategia puede implementarse para tu aplicación y promueve sustituir validaciones ad hoc manuales por monitoreo constante que puede identificar problemas casi de manera inmediata, además el monitoreo no solo te podría decir si la aplicación continua funcionando, si no como lo hace en términos de performance y tiempo de respuesta.

Y finalmente, la Comunicación

Si… es un cliché; pero es cierto. A medida que una organización crece, los proceso de comunicación entre todos los involucrados se puede complicar. Como QA quizá no estemos para resolverlos, pero sí podemos colaborar brindando a todos los interesados una comunicación clara de nuestros avances y resultados. Aquí algunas recomendaciones que podrían ayudarte a conseguir esto:

• Si utilizas Slack podrías colocar notificaciones automáticas que ayuden a comunicar cuando alguna prueba falle en los canales pertinentes. Si no, considera el email como una opción.
• Si utilizas Slack, puedes proponer un canal para coordinar el proceso de liberación, donde los principales involucrados participen. Si no podrías utilizar reuniones rápidas o correos electrónicos.
• Si utilizas Confluence, podrías crear una página y mantener actualizado el estatus de los resultados de pruebas en cada ambiente, así todo el equipo podrá estar al tanto. Si no, podrías crear un documento en la nube.