QA es una tarea, no una persona

Uno de los roles que más se han puesto de moda es el de QA o el Ingeniero de Calidad. Soy consciente de que hay muchas diferencias entre un tester, un QA y un QE, y es una parte del desarrollo software que juega un papel importante. Sin embargo, hay una cosa que es importante que entendamos: la calidad es un hábito no una persona

La calidad haciendo coches

Contaba Jeff Sutherland, en su libro Scrum:doing twice in the middle time, la historia de cómo los fabricantes de coches japoneses eran capaces de cometer muchos menos errores que los fabricantes alemanes y estaban capacitados para producir en la mitad de tiempo. 

Uno de los argumentos que utilizaba Jeff Sutherland para explicar esto era el proceso de calidad que seguían cada uno. En Alemania, los coches seguían un proceso riguroso al finalizar. Querían garantizar que los coches tenían la calidad esperada. Grandes ingenieros con sus batas comprobaban que el coche estaba perfecto al final del proceso y lo reparaban. Esta estrategia tenía un problema, cuando se había producido un error se detectaba muy tarde en la cadena de montaje y afectaba a muchos vehículos antes de que se buscara y encontra el problema de origen.  

En Japón, en fábricas como Toyota, se instaba a los empleados a parar la cadena de montaje si detectaban un error durante el proceso. Era mejor parar y arregarlo, que esperar al final, así garantizaban que el resto de coches que producían funcionaban bien.  Aunque pueda parecer más lento, en Japón acababan produciendo coches que no tenían que reparar, con lo que acababan reduciendo el tiempo de fabricación, y sin el riesgo de que un error no detectado acabara en un cliente insatisfecho.

Con esta historia, aprendemos que la calidad es un hábito, y que si se incorpora a la cadena de trabajo, permite entregar valor de manera constante. 

¿Cuánto se tarda en arreglar algo?

Otro de los experimentos que Jeff Sutherland contaba en su libro era referido a la relación entre el coste de arreglar un defecto, respecto al momento en el que se ha detectado. Siempre hablamos de que un error es más caro de arreglar cuanto más tiempo pasa. Veamos qué demostró la empresa PALM. 

En la empresa PALM, precursores de los actuales móviles, hicieron un experimento. Se dieron cuenta de que tenían equipos que diariamente comprobaban que lo que terminaban funcionaba bien y, en caso contrario, lo arreglaban el mismo día, mientras que otros equipos realizaban una fase de pruebas cada tres semanas donde probaban todo el producto. El resultado fue arrollador, los equipos que esperaban tres semanas para arreglar los defectos, tardaban 24 veces más en arreglar cada fallo que los que lo hacían de manera diaria y constante. Y tiene sentido, cuando desarrollamos software, solemos crear estructuras mentales para programar la solución que estamos programando. En el momento en el que pasamos a realizar otra tarea, esa estructura se desvanece y, si detectamos un fallo, tenemos que volver  a construir la estructura. Por eso, cuando estamos inmersos en una  programación, nos acordamos del nombre de los archivos, métodos y clases, y sabemos dónde está todo. Pero unas semanas después, se nos olvida y tenemos que volver a recordarlo. 

Y apareció el QA y bajó la calidad… 

En una empresa en la que trabajé,  no existía el departamento de calidad y los equipos eran responsables de la misma. Algunos equipos lo hacían muy bien y otros, quizás peor. La organización decidió crear el Departamento de Calidad, y empezó a introducir QAs en los equipos. 

Lo curioso es que, a corto plazo, fue perjudicial para muchos equipos, acabaron por tener niveles de calidad más bajos. Debido a que la calidad recayó sobre una única persona, el resto dejó de asumir esa responsabilidad. Una sola persona se veía desbordada, y acababa, al final del Sprint, tratando de probar todo lo que sus compañeros habían terminado. Además, cuando se introduce un QA, se asume que, si aparecen errores, estos serán fallos suyos por no haberlos detectado. 

En Scrum, la solución es sencilla, la calidad es una tarea y no, una persona. 

Scrum y las etiquetas

Una de las reglas más difíciles de cumplir en Scrum es la eliminación de etiquetas dentro del Development Team. Un Development Team es un conjunto de personas con habilidades diferentes que sacan adelante el producto. Estos equipos son multifuncionales, es decir, capaces de sacar el producto por sí solos. De esta manera, reducimos la complejidad cuando interactúan diferentes equipos y mejoramos el time to market para llegar a mercado.

Las etiquetas nos encantan porque nos permiten pertenecer a tribus o áreas de conocimiento. El gran reto de un Scrum Master es hacer entender que las etiquetas son nocivas para la autoorganización. Todos somos responsables del resultado del trabajo del equipo, esto incluye: desarrollo, calidad, diseño, análisis y cualquier otra tarea que sea necesario abordar. 

La calidad es una tarea no una persona

Cuando hablamos de calidad, hablamos de garantizar que lo que hemos producido no falla,  presta un buen servicio y genera valor para la compañía. Todo esto son tareas que pertenecen al propio desarrollo software y las personas con más experiencia lo incorporan como parte de su trabajo . Los equipos más maduros que he tenido la suerte de acompañar son aquellos que velaban porque la calidad fuera alta y trataban de garantizarla.

En Scrum disponemos del Definición of Done como un elemento que garantiza que todo aquello que terminamos cumple con la calidad que hemos definido. Un Software con calidad permite un ritmo sostenido en el tiempo de entrega y nos permite garantizar un buen servicio a los usuarios. Además, la calidad a largo plazo permite reducir el coste a la hora de implantar cambios. Por tanto, QA es una tarea, al igual que el desarrollo software y no es una persona que prueba.

El equipo que pasaba de probar

Una vez acompañé a un equipo que no disponían de personas QA. Ellos tenían la regla de que, cuando un compañero terminaba algo, lo dejaba en una columna de Jira para que un compañero lo probara. Como a los desarrolladores nos suele gustar más desarrollar nuevas funcionalidades que probar las de otros, la columna de calidad se llenó de posits sin que nadie los abordara. Esto supuso un riesgo ya que se les acababa el Sprint sin tener nada completado.

Rápidamente, la Scrum Master les envió un email con un semáforo rojo a todo el equipo haciéndoles ver que no se podía trabajar así. Tomaron la decisión de desatascar la columna QA cuanto antes, de hecho, el Product Owner se sumó a la causa. En la siguiente Retrospectiva,  analizaron lo ocurrido y crearon una regla: nadie podía coger una tarea nueva si había tareas por comprobar. Para ellos era más importante acabar funcionalidades que tener muchas sin probar.  

Una vez más, los equipos responsables y comprometidos buscan terminar las cosas por encima de todo. Es más importante 10 cosas terminadas que 30 “hechas” sin probar. Y el Scrum Master tendrá que tener cuidado, muchas veces tendrá que lidiar entre hacer más cosas (Product Owner) y hacer más calidad (Development Team), y se tiene que buscar un equilibrio. La calidad total tampoco suele ser rentable en la mayoría de productos. 

Y para ti, ¿QA es una tarea o una persona?