Les voy a contar la historia de Amy y su hija Morgan. Amy trabaja como secretaria en la oficina de un médico. Sus tareas consisten en registrar facturas y órdenes para las aseguradores médicas. Ah, y presten atención porque esta historia está íntimamente relacionada con la calidad del código y el impacto en la vida personal de los usuarios.
En ese día en particular, las cosas no estaban yendo muy bien para Amy. Ella estaba usando el sistema de carga de facturas, y seguían apareciendo mensajes de error crípticos. No lograba avanzar. Y el estrés aumentaba. Para empeorar las cosas, Amy tenía que pasar a buscar a su hija al colegio, y la hora se acercaba. Morgan recién empezaba la escuela, y estaba inquieta por ser sus primeros días. Amy sentía la necesidad de estar presente para Morgan ni bien saliera de la escuela. Y sin embargo, no podía avanzar con el sistema de facturación. El trabajo se acumulaba, la hora de irse se acercaba.
¿Y qué tiene que ver esta historia de Amy y Morgan con las pruebas y la calidad del software? Quien presenció esta situación era Ben, un desarrollador del producto que usaba Amy. Amy era un usuario del producto de Ben. Ben estaba en el lugar de trabajo del usuario para ver cómo funcionaba el software, y cómo ayudaba a los usuarios en sus tareas. Y entonces, Ben vio personalmente como el estrés de Amy aumentaba al usar el software que SU equipo había entregado y que el jefe de ELLA había pagado. Y cuando Amy empezó a llorar, Ben se dió cuenta que el impacto del software en la vida de los usuarios puede ser inesperado. Algo tenía que hacerse.
¿Qué nos enseña la historia de Amy y su hija?
- Los usuarios se merecen algo mejor que esto.
- En un equipo Ágil, la calidad es trabajo de todos.
A menudo pensamos en el testing como una tarea que sólo los testers tienen que hacer. Pero esta forma de pensar genera muchas consecuencias negativas:
- Cuando no arreglamos los defectos, declaramos que una historia está "terminada" agregando estos defectos a un backlog.
- Los defectos ocultos se acumulan como deuda técnica oculta.
- La deuda técnica hace que seamos más lentos en las entregas siguientes.
- Un backlog siempre creciente de defectos puede ser desmotivante para el equipo entero.
- Los desarrolladores se enojan con el negocio cuando se sienten forzados a entregar características que saben contienen errores.
- El negocio se enoja con los desarrolladores por no construir software mejor y más rápido.
- Los testers se enojan con el "testing al final" porque deja en una posición comprometida al negocio, al desarrollo y al testing.
Una conclusión: la calidad no es un problema de desarrollo, es un problema sistémico. Es decir, la calidad debe ser impulsada desde todos los niveles de la organización, y no sólo desde un área en particular. Una buena política de negocio sobre la calidad impacta directamente en los usuario y en la calidad de su vida. El estrés que de Amy por ir a buscar a Morgan puede verse como consecuencia de una mala política de calidad que guió al negocio: entregar características.
A medida que se adopta Ágil, se debe trabajar vigorosamente en ser rigurosos con el testing y la calidad. ¿Por qué? Porque la política de calidad puede impactar en formas que actualmente no vemos. Debemos prestar atención más cosas además del costo interno de la deuda técnica. Debemos prestar atención a la calidad de vida de nuestros usuarios.
La próxima vez que registren en un error en vez de arreglarlo, piensen en la historia de Amy y Morgan.