Como QA (tester, ingeniero de calidad, etc. Para simplificarnos la vida, de momento permítanme llamarnos simplemente “QA”) tal vez alguna vez te has preparado para un refinamiento; te ha llegado la cita, has revisado previamente los detalles preliminares de las tareas en el backlog, participas activamente de la sesión dando el siempre valioso punto de vista de quien prueba y que en general tiende a ser la misma persona que debería velar por la calidad transversal del producto, hasta que… llega la hora de estimar, y bueno. Te das cuenta de que, según alguna ley suprema, QA “No debe estimar la tarea”.
Si bien este es un escenario simplista y anecdótico, es muy probable que hayas presenciado algo similar -o peor- ya sea como tester, dev, product owner, ux o como un simple espectador. La pregunta es ¿Por qué? ¿Por qué algunos equipos o gestores consideran que QA no debe estimar el esfuerzo de una tarea?
Veamos primero algunas posibles explicaciones del porqué el QA no debería estimar esfuerzo antes de ponernos el traje de crítico porque después de todo, “la vida de un crítico es sencilla en muchos aspectos”
1. La estimación como vara de medición para los desarrolladores: (créeme no apoyo esto) si un equipo quisiera medir el “velocity” de sus devs lo podría hacer – de forma bastante dudosa – midiendo los puntos de esfuerzo quemados por cada un de ellos durante un sprint, en este nocivo caso, incluir la estimación de QA podría “viciar” la métrica.
2. QA como Rol externo: En equipos que se están integrando a la agilidad o directamente vienen de modelos de silos, el QA puede verse como un trabajo externo y ajeno a la construcción del producto. Esto es mas bien un problema cultural de los equipos.
3. Desarrollo y pruebas: Se puede dar el caso en que cierto equipo que no tenía originalmente un encargado de QA y cuyas pruebas eran realizadas por los propios dev o otros miembros del equipo consideren que integrar la visión de QA podría “distorsionar” la estimación.
Ahora bien, aunque los motivos pueden ser variados y el mundo es un lugar grande y completo donde se pueden encontrar escenarios de todo tipo, excluir de la estimación de esfuerzo a QA es una práctica nociva para los equipos y para el producto, veamos algunas razones por las cuales excluir al QA de la estimación está mal.
1. ¿Estimación de qué?: Si buscamos que el proceso de estimación sea integral y representativo del esfuerzo que para un equipo significa una tarea deberían estar todos los involucrados que permiten alcanzar el DOD (Definition of Done) de dicha tarea. Esto incluye por supuesto al QA.
¿Qué ocurre si la tarea es simple en su desarrollo, pero completa de testear por motivos de ambientes o dependencia? Una tarea de 3 puntos (talla s, etc.) podría implicar mucho más esfuerzo del presupuestado, y alli comienzan esos fantásticos mensajes “esa tarea de 3 puntos ¿por qué aún no está done?”
2. Eternamente atrasados: Te has encontrado con proyectos donde siempre hay riesgos de no salir a producción en la fecha comprometida. Directamente relacionado con el punto anterior; No considerar la mirada y el esfuerzo de pruebas en el cumplimiento de las tareas suele ser el motivo oculto -o uno de los principales- del retraso en los proyectos.
3. Testing cada vez más escaso: Una de las consecuencias más desastrosas de no estimar considerando las pruebas de software es la reducción del tiempo para las mismas. No es extraño encontrar casos donde al considerar -erróneamente- que el proceso de testing es casi algo anecdótico se intenta acelerar lo mas posible, y en muchos casos llevar a su mínima expresión, el periodo de pruebas. La consigna suele ser que lo importante es salir en fecha a producción, lamentablemente esta visión a llevado a empresas al desastre financiero.
4. Se empobrece la conversación: En Planning Poker o en cualquier técnica de estimación, lo más valioso no es el número, sino la discusión previa. El profesional de QA puede entregar una visión crítica, aportar valor y generar consideraciones que de otro modo solo serían identificadas en etapas posteriores, haciendo que las correcciones -si las hubiese- sean mas costosas que si se hubieran considerado inicialmente en la planificación.
Aunque estos puntos a considerar son importantes, no quisiera dejar de lado otro que no es tan técnico; trabajar en equipo no implica solamente que un grupo de personas se identifiquen con un nombre y participen de las mismas reuniones, el trabajo en equipo requiere una cultura que lo sustente, una participación transversal en el conocimiento y en las particularidades que componen nuestras tareas.
Un QA que participa de la estimación entrega valor desde un punto de vista amplio, ya que normalmente se relaciona tanto con las áreas de negocio, desarrollo, ux y clientes de forma transversal y en general siempre podrá dar información valiosa para la estimación en uno de los aspectos más críticos del desarrollo, las pruebas, que junto con una construcción y planificación exitosas se traduce en productos y calidad, satisfacción del cliente y confianza.