Elimina al equipo de Testing
Esta es la historia de un conflicto ríspido entre Testers y Devs, y de cómo lo podemos eliminar
Trabajé con un equipo de desarrollo, en el que estaba una tester (la llamaré M.)
M. nos volvía locos porque era difícil obtener su aprobación.
M. era una tester minuciosa. Se tomaba su tiempo en hacer sus pruebas y en validar los fixes. Regularmente, nos reportaba tres categorías de fallos:
Cosas que hicimos mal y rompían producción.
Casos en los que la app podía fallar, pero no habíamos previsto.
Features que faltaban por implementar.
Aceptábamos todo lo de la primera categoría, porque reconocíamos que fue causa nuestra. Pero las otras dos solían ir acompañadas de largas discusiones, en las que M. no accedía a retirar su reporte de bug. Además, tenía poder de veto. Sin su visto bueno, el release no se aprobaba.
Las discusiones de la categoría 2 giraban en torno a lo siguiente:
M. encontró un path que haría fallar el software.
El equipo de devs consideraba que era un path improbable y que era seguro liberar, porque los usuarios no harían eso jamás.
M. lo hacía fallar, con un proceso complicado e intrincado. Se quedaba como defecto a arreglar.
Las discusiones de la categoría 3 eran más desconcertantes. M. pedía features que, en su opinión, eran necesarias para prevenir fallos y dar más valor, pero no estaban en los requerimientos. Las rechazábamos por eso, pero reabría el ticket una y otra vez. Discutíamos por días en esos casos.
Solía decirnos “la aplicación no puede salir sin esos features porque son necesarios para los usuarios; ustedes deberían saberlo”. Los devs sostenían que, aunque el valor era real, no se habían acordado en los requerimientos.
Al final, teníamos que hacer las cosas como especificaba M. para poder hacer el release. La relación entre M. y devs era ríspida y ambos tenían una mala opinión uno del otro.
Quizás te ha pasado algo similar
¿Quién tenía la razón?
¿Por qué te estoy contando esto?
Ambos tenían razón, pero lo que no se daban cuenta es que estaban discutiendo el problema en el momento equivocado.
Los devs tenían razón en que el release no debería detenerse porque faltaran funciones que no estaban en los requerimientos.
M. tenía razón en que los paths que podían hacer fallar la app eran inaceptables, y era capaz de pensar en muchos de ellos.
Pero eso no es todo:
M. creía que a los devs no les importaba la calidad
Los devs creían que la única responsable de calidad era M., pero solo de encontrar los fallos
En esto, ambos estaban equivocados.
Cambia el proceso y la organización del equipo
El diseño de aquel equipo, y el de muchos que conozco, era de silos funcionales:
Grupos especializados en un tipo de trabajo.
Pasar el trabajo entre estaciones.
Hacerse responsable solo de su parte, mas no de todo el proceso.
Eso generaba las fricciones y discusiones.
La cuestión no era ver quién tenía razón (M. o los devs), sino cambiar el proceso y la organización del equipo. M. tenía una gran habilidad de empatía con el usuario y detectar escenarios de uso, pero no la estaban aprovechando. El cambio necesario era que ella participara en las actividades de requerimientos, diseño arquitectónico y de componentes, junto con todo el equipo.
El cambio más importante: crear una cultura de calidad total, no solo de una estación. Todos debían involucrarse en lograr una alta calidad.
Ese es el mensaje que quiero dejarte: no debe haber fricción entre los equipos de testing y devs. Es más, no debe haber equipos de testing y devs. Debe haber un equipo compacto, comprometido con la calidad en todo momento y aprovechando sus habilidades para ello.
Hace mucho que no sé de M., pero si hoy la encuentro le diré: Tenías razón y no supe colaborar contigo, pero hoy lo haré diferente.
Conclusiones
Algunos, que leyeron el título del artículo, podrían pensar que quiero deshacerme de Testing. No es así, el Testing es muy importante y necesario; mi propuesta es que debe eliminarse la idea de que debe haber un equipo de Testing que solo participa cuando hay que hacer Testing.
El conocimiento de todos los miembros del equipo es variado. Cada uno tiene una perspectiva diferente, la cual aporta valor al proyecto. Lo importante es aprovechar esos puntos de vista, que enriquecen la solución, en todo el desarrollo. Si seguimos dividiendo el trabajo para que ocurra solamente en ciertos momentos, entonces tendremos conflictos y fricciones. Lo ideal es que hagamos el software todos juntos todo el tiempo.
¿Quieres llevar esto a tu organización? ¡Contáctame!
¡Coméntame con un emoji en este artículo y te regalo mi Guía para Escribir User Stories!
¿Quieres implementar estas mejoras, pero no sabes cómo? Te presento dos alternativas:
Una consulta profesional de 1 hora, para discutir problemas individuales y encontrar respuestas.
¡Únete al grupo de facebook para compartir ideas con otros profesionales de Élite!