Ah! El dolor de cabeza de todo el mundo. ¿Cómo nos movemos rápido, pero manteniendo alta la calidad de nuestro software?.

Este tema tiene mucho hilo por cortar, pero quiero poner aquí mis mayores recomendaciones y prácticas que seguimos en Muni.

1. Señor (Señora) desarrollador, la calidad del software es TU responsabilidad

Inicio con un paralelo. Contratas a un plomero para que encuentre y solucione la causa de una humedad en tu casa, él viene, hace “cosas”, te dice que ya esta listo, a ti te pareció bien, le pagas y el se va.

Sin embargo, a los 2 días, el problema vuelve a aparecer, ¿quien esperas que asuma la responsabilidad?, ¿Tú, que aceptaste el arreglo?, ¿o el plomero que lo dejó mal hecho?. Lo más probable, es que llames al plomero, con cierta ira, y le exijas que haga bien las cosas.

Es muy triste ver lo frecuente, que un desarrollador o un equipo de desarrollo, hace “cosas”, las publica y se sienta a esperar a que alguien más, normalmente un equipo de QA, le diga si lo que hizo esta bien, y resulta que, con tan solo abrir la “app” y oprimir un botón, todo explota.

No seas el mal plomero, escribe tu código a conciencia, busca seguir buenas prácticas, escribe buenas pruebas unitarias o de integración (nada de tener todo “mockeado”), haz code review, como mínimo haz pruebas funcionales del “happy path”, y asegurate de estar cumpliendo con los criterios aceptación para lo que estas haciendo.

2. ¿Es un equipo de QA funcional necesario?

Recientemente varias empresas consideran que no, Mercado Libre es una de esas, y su razonamiento para no tenerlo, es precisamente lo que expongo como primera pauta para la calidad en el software: Son los equipo de desarrollo y sus miembros, los responsables de la calidad.

En Muni contábamos con un equipo dedicado de QA funcional, y personalmente creo que es útil, siempre y cuando:

• No sea un cuello de botella en todo el proceso, tampoco que su principal función sea determinar si liberamos o no. Este video me paree que expone muy bien el punto: https://www.youtube.com/watch?v=XhFVtuNDAoM
• Lo que prueba, no es lo mismo que como mínimo se espera del equipo de desarrollo. Si el equipo de QA esta enfocado en probar APIs aislados, ¿que carajos esta haciendo el equipo de desarrollo?
• El equipo debe ser un experto funcional de los productos en la organización. Debe entender cómo funcionan desde la perspectiva del usuario, y cómo se relacionan entre sí.
• Buena parte de sus pruebas son exploratorias y buscan tener “malicia indigena”. Con esto me refiero a ir más allá del “happy path”, hacer cosas que normalmente no contemplamos, ¿que pasa si ponemos una “ñ” en el numero de cedula?, ¿que pasa si entra una llamada al celular mientras estamos finalizando el pago?, etc…, no sirve de nada decir “pero probamos el API y estaba funcionando”, cuando un usuario no pudo finalizar su compra.
• Sean los representantes del usuario final durante todo el proceso de desarrollo, desde la planeación hasta el despliegue.

Aquellos equipos de QA funcional que no ofrezcan valor más allá de oprimir botones o llamar APIs según dice un ticket, serán reemplazados por automatizaciones.

3. No le temas a producción

Entre más frecuentes sean tus despliegues a producción, mayor será el rendimiento de tu equipo, y mejor será la calidad de tu software.

Quizás esto pueda sonar contra intuitivo, pero no lo digo solo yo, alguna personalidades de la industria, como Dave Farley y Randy Shoup, lo han mencionado en múltiples ocasiones, y las investigaciones hechas por el DORA desde 2013, han encontrado que aquellos equipos que siguen esta práctica, son aquellos de mayor rendimiento y calidad en la industria, con rendimiento medido en términos de revenue, velocidad de innovacion, calidad de vida, número de incidentes productivos, y tiempo de resolución de problemas.

Vuelvo a mencionar, el libro Accelerate, y los invito a leer los “State of Devops Report”, que tienen una cadencia anual: