El libro "Agile Adoption Patterns", de Amr Elssamadisy, incluye las prácticas de Equipos Auto-Gestionados y Equipos Multi-Disciplinarios. En ambas prácticas, Amr menciona el poder de estos equipos para superar obstáculos. También menciona de forma específica que todos los miembros del equipo están dispuestos a ayudar con el testing a medida que es necesario, para que el equipo logre alcanzar su meta.
Una vez que los equipos encuentran su ritmo en un proceso reproducible, casi todas las organizaciones empiezan a darse cuenta que el "testing" es su cuello de botella. Y en realidad no estoy muy de acuerdo en usar esa oración; creo que sería mejor decir que el cuello de botella es la "calidad del producto", y el testing es una de las manifestaciones más visibles del control de calidad.
Mi punto de vista sobre la calidad está fuertemente influenciado por haber estudiado procesos de aseguramiento de calidad y control estadístico de procesos en el ámbito de la industria. Aunque hay algunas áreas importantes en donde la analogía no puede usarse, hay muchas otras donde los conceptos son totalmente aplicables. Empecemos con el concepto de Crosby en "La calidad es gratis": el costo y el esfuerzo que se gastan mejorando las capacidades del proceso reducen la producción de errores generando ingresos superiores a esa inversión. Crosby y otros están en contra de las inspecciones, porque las inspecciones son la forma menos efectiva de asegurar la calidad de un producto.
Cuando una organización de software decide invertir en "testing", usualmente terminan creando alguna forma de Equipo de Control de Calidad (a veces bajo nombres como QA, Testing, Certificación, etc.). Las organizaciones comienzan por acá porque buscan algún tipo de verificación que les confirme que el producto que producen es bueno. Estos equipos pueden aplicar alguna forma de automatización, pero usualmente debido a su experiencia terminan usando pruebas manuales. Su responsabilidad principal es ejecutar las pruebas de regresión, y allí es donde se ubica la mayoría de su tiempo y esfuerzo.
Cuando encuentro este tipo de estructura, lo primero que hago es cambiar la definición de qué es el testing. Este involucramiento pasivo y tardío en el proceso de desarrollo (como si fuera una "última aprobación" antes de entregar el producto) es ineficiente y resulta frustrante para todos los involucrados. Nos obliga a juntar gente para los momentos de "carga pico" durante las regresiones. Los testers que ofrecen su opinión sobre cómo podría mejorarse el producto pronto descubren que la entrega ya se hizo - el equipo ya está sobre la fecha de entrega, y sólo pueden atenderse los problemas más graves. Entonces, la opinión de los testers queda sin reconocimiento, y eventualmente dejan de ofrecerla. O peor aún, surge una pelea de poder entre los equipos de testing y desarrollo, en un esfuerzo por influenciar la calidad.
Pensando diferente
Pensemos una alternativa, basada en los equipos auto-gestionados y multi-displinarios: sacamos a los testers de su departamento y los ubicamos dentro de estos equipos multi-displinarios. Rompemos el ciclo de "testing tardio" que hasta ahora les impedía involucrarse en el concepto, en la fase de diseño y en las próximas características del producto. Los testers ahora prueban las características a medida que aparecen (en vez de hacerlo tarde en el ciclo de entregas) y una característica no está terminada hasta que ellos dicen que está terminada.
En "The Goal", Goldratt nos cuenta una historia sobre un grupo de scouts en una expedición, que se les da el objetivo de que todos tienen que llegar al destino final en el menor tiempo - sólo se logra el éxito cuando la última persona cruza la meta. Al principio los más rápidos se adelantan, pero eventualmente se dan cuenta que a menos que ayuden a los más lentos, su potencial extra será desperdiciado. Deciden atarse todos con una soga, y con el tiempo van quitando peso al que es más lento (el cuello de botella), de manera que todos se empiezan a mover a la velocidad más rápida posible.
Todos estos cambios funcionan de maravillas y siempre revitalización la organización del testing. Pero incluso cuando pasamos de buscar gente para la carga pico a buscar gente para la demanda promedio, no vamos a encontrar el balance que queremos a menos que cambiemos las regresiones que hacemos, y cómo probamos. Para romper este círculo vicioso también se requiere de energía y de recursos extra. Es posible que los testers no tengan la visión o conocimientos técnicos necesarios para arreglar los problemas. Necesitarán ayuda. Y si contratamos más testers es probable que profundicemos más la situación que queremos evitar.
¿Cómo arreglamos el problema? Como equipo, y por equipo me refiero a los equipos auto-organizados y multi-displinarios, debemos reconcer que si no superamos este desafio, los productos no tendrán la calidad que deseamos, ni estarán a tiempo. A menos que la calidad se convierta en una responsabilidad de los miembros del equipo, no podremos romper con el ciclo de "codificación / testing" que es la raíz del problema. La regresión manual es el equivalente del software a una inspección 100% manual en una línea de ensamblaje. En ese mundo, comprenden que es clave invertir en inspecciones automatizadas y en mediciones tempranas del proceso. Sin embargo, es posible que necesitemos modificar a un producto para que sea testeable a través de medios automatizados - esto podría ocasionar un cambio importante en la arquitectura o en las herramientas de desarrollo. La inversión en las pruebas de desarrollo puede disminuir la necesidad de inspecciones manuales, y esto significa un cambio en los hábitos de trabajo de los desarrolladores. Y por último, los desarrolladores pueden necesitar ayuda para crear y usar una suite de pruebas automatizadas.
La calidad es responsabilidad de todos los miembros del equipo, especialmente de los desarrolladores. Si un equipo tiene problemas de calidad y no hay capacidad suficiente de test, entonces los desarrolladores deben ayudar. Y hay algo que es cierto - dale a un desarrollador una tarea que considere mundana, y no sólo la va a hacer, sino que también va a aplicar su creatividad para crear alguna forma de no necesitar hacerla otra vez. Los desarrolladores son clave para transformar la forma en la que los equipos aseguran la calidad. Junto a una inversión suficiente en pruebas de desarrollo (para reducir la necesidad de pruebas de regresión) y a la automatización (para incrementar la eficiencia de las pruebas de regresión), podremos lograr la meta de un 100% pruebas de regresión automáticas.
Entonces, si sos un desarrollador en un equipo y ves que los testers necesitan de tu ayuda, arremangate y fijate cómo hacer que las pruebas sean más eficientes, o mejor todavía disminuir la necesidad del testing en primer lugar. Si no estás seguro por dónde empezar porque en realidad no entendés cómo se hace el testing, entonces ahí tenés una buena razón para ser voluntario y ayudar. Podemos cambiar la tecnología y los métodos que se usan, podemos utilizar nuestro conocimiento del producto y de los cambios para influenciar lo qué se prueba y cuándo se prueba. Por otro lado, debemos asumir más responsabilidad por las pruebas de desarrollo para crear un proceso más capaz.