Tenemos un nuevo director de QA – Nuestra experiencia

Hace varios meses descubrimos que la calidad de una cierta línea de productos estaba por debajo de lo que nosotros esperamos. El retrabajo, aquel trabajo que vuelves a hacer sobre una actividad que declaraste terminada, nos estaba consumiendo todo el tiempo que teníamos para realizar mejoras y el tiempo para desarrollar las nuevas funcionalidades de los proyectos.

Como lo que estábamos viviendo era bastante similar a lo que estaban viviendo otras empresas, decidimos usar la misma solución de ellos, contratar un experto QA.

Como equipo le asignamos la responsabilidad al rol de asegurarse que antes de llegar a producción se cumpliera cada punto de nuestra lista de validación, esperábamos que al tener un responsable, los problemas se solucionaran.

Funcionamiento

Brian, nuestro nuevo director de QA, trabajaba con nosotros desde hace muchos años, conoce el funcionamiento de la empresa al revés y al derecho, era el trabajador idóneo para el puesto. En todos los años que lo conozco no he tenido la posibilidad de tener mayores conversaciones con él y no sabía cómo podía reaccionar.

Sin decir nada aceptó el cargo y comenzó inmediatamente a trabajar, ese mismo día hubo dos pasos a producción y estuvo presente en ambos. En ambos casos se percató de un par de problemas que podrían haber surgido en producción.

Entrevista a Brian

Brian
Brian – Director QA

Brian no quiso dirigirnos unas palabras, es fiel a su personalidad silenciosa orientada a sus objetivos.

¿Por qué funcionó?

Cuando trabajamos en algo que estamos creando, mientras más abstracto sea, más difícil es entender si tiene «la forma» que queremos darle. En el mundo del desarrollo de software se realizan demostraciones a los clientes y/o usuarios para disminuir la incertidumbre, en ambientes de diseño gráfico y usabilidad pasa lo mismo.

Una validación contra una lista de chequeo se convierte en algo cualitativo, que resulta fácil de creer que cumple con las expectativas cuando no es así. Al forzarnos a comparar lo que creemos que hace algo con lo que realmente hace podemos descubrir si existe o no brechas, esto lo logramos verbalizando el funcionamiento y justificando porque cumple con la condición de la validación.

Este funcionamiento se utiliza en el desarrollo de software desde hace muchos años, por ejemplo, en la práctica de debuggear con el patito de hule que se explica en el libro The Pragmatic Programmer. Mismo efecto que cuando necesitamos resolver algo y mientras contamos el problema descubrimos la respuesta.

¿Qué más ganamos?

Lo primero y más importante, nadie quiere responsabilizar a Brian por algún problema en producción. Esto produce que frente a un nuevo defecto vayamos robusteciendo el chequeo.

El segundo efecto, al narrar una y otra vez la lista de validación surgen ideas de tareas que podrían ser testeadas automáticamente, de este modo, sólo lo realmente necesario pasaría a ser validado por un humano.

¿Qué otras sorpresas nos tendrá Brian en el futuro?

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *