Cómo encaja un tester en un equipo XP

Las mayores contribuciones de XP han sido aquellas que han ofrecido soluciones a problemas que eran muy molestos en el desarrollo "Waterfall". Y es posible que el TFD/TDD sea la práctica más importante de XP. Todo el enfoque disciplinado pero deliberado que gira en torno a XP se basa en el aseguramiento de calidad a través de las pruebas unitarias.

Generalmente, los desarrolladores XP prefieren escribir las pruebas unitarias antes de escribir el código. Este flujo de trabajo basado en "test first" ayuda a refactorizar, ya que ésta no es posible sin asegurar que el 100% de las pruebas unitarias se ejecutan correctamente.

Como dije en otro artículo, la palabra "Extreme" de XP procede de la disciplina con que los desarrolladores que adoptan esta metodología llevan a cabo sus prácticas. En el caso del testing, esto implica que una tasa de aprobación del 100% en las pruebas unitarias no significa el 87% cuando el proyecto no está completo. Significa el 100%, todo el tiempo. Sin excepción. Así de extrema es la programación extrema.

Una de las consecuencias de esto es la adopción del TDD. Los programadores de los equipos XP escriben sus pruebas unitarias primero, antes de escribir el código. Ciertamente es posible que también tengan que ir añadiendo nuevas pruebas unitarias a medida que descubren que son necesarias, pero lo importante es que antes de escribir cualquier código, tratan de generar el test. Y eso garantiza ese 100% de tasa de aprobación todo el tiempo.

Esta diligencia por parte de los desarrolladores a la hora de aplicar las prácticas de XP, resuelve numerosos problemas. Por ejemplo, termina definitivamente con el costoso e ineficiente proceso de localización de errores por parte de los tradicionales "testers" de código. Es posible que no haya nada que retrasa más las entregas o la completitud de las pruebas de aceptación que esto. Y es que es extremadamente complejo conseguir evitarlo sin las principales prácticas de XP (ya no sólo TDD). Por ejemplo: el Pair Programming permite detectar y corregir errores de integración y unidad durante las sesiones de codificación. Así, cuando el código llega a las pruebas de aceptación, está haciendo lo que pretendían los programadores. Y en ese momento las pruebas de aceptación pueden centrarse en determinar cómo esa intención coincide con las expectativas del cliente.

Además, es imposible llevar a cabo este enfoque si no se abandonan antiguas prácticas que imposibilitan XP. Por ejemplo, los pesados documentos de requisitos, excesivamente inflexibles, provocan que se queden obsoletos tan rápidamente que se generen baterías de pruebas inexactas, incompletas o desactualizadas. Constituyen un gran desperdicio de la sobreproducción (gracias por la lección, Toyota). Si no utilizamos algo como las historias de usuario, se nos desmorona nuestro marco de trabajo ágil.

En definitiva, XP constituye un conjunto de prácticas cohesionado y coherente que se debe orquestar correctamente, complementando y enriquececiendo sus elementos entre sí, y de los cuales el más importante por constituir la columna vertebral de los demás es TDD.

Si, TDD. Sin él, será muy complicado aspirar a conseguir un equipo de desarrollo ágil. Es precisamente la falta de pruebas de integración y unidad adecuadas, los requisitos desactualizados y la brecha existente entre las expectativas del cliente y el producto final, lo que exige producir ciclos pequeños y frecuentes de entrega de valor que brindan exactamente aquellas características que el cliente ha priorizado más recientemente como las más importantes. Esto provoca que los profesionales de QA se involucren directamente en el equipo de desarrollo y dejen de ser considerados el enemigo cuando el control de la calidad del proyecto se convierte en algo inmanejable por causas ajenas a ellos.

Pero entonces, ¿los equipos de XP necesitan testers / QA?

A menudo he leído, como parte de esa cultura que demoniza a los QA o los testers como si fueran los culpables de ciertos problemas en las entregas de software, que su función no es necesaria puesto que las pruebas unitarias y de aceptación ya están automatizadas. Y es cierto que en ciertos equipos esto puede ser así, pero no siempre.

Para empezar, deberíamos tener claro lo que se debe esperar de un equipo de testers. Sin entrar en las sutilezas que diferencian un tester de un QA, pues en XP éstas se desdibujan bastante. Estos equipos no solo deberían dedicarse a desarrollar y ejecuta pruebas, sino que deberían tener habilidades de aseguramiento de la calidad y estar involucrados en el desarrollo del producto. Hablo de combinar funciones que garantizan tanto el aseguramiento de calidad (QA) como el control de la misma (QC). Uno está orientado al proceso, otro al producto. Pero ojo, esta distinción no es realmente útil para el producto final. Así que creo que el mejor enfoque posible es integrar todas sus actividades y tratar de no clasificar demasiado a las personas implicadas en el equipo de desarrollo.

A la hora de desarrollar software, es posible que a posterior se descubra que faltan requisitos. Lo normal en un desarrollo de software es que esto no se detecte hasta que se haya entregado una versión determinada del producto al cliente. Los desarrolladores tendemos a centrarnos en aquellos elementos que consideramos más importantes o interesantes en el ciclo actual. Pero desafortunadamente, no siempre acertamos lo que espera el cliente.

En este contexto, un "tester" puede ser valioso, ya que cuando desarrolla las pruebas de aceptación con el cliente tiende a pensar en el sistema desde el punto de vista de quienes tendrán que vivir con la solución, y al mismo tiempo entiende los detalles, las posibilidades y las limitaciones de quienes la construyen. Por tanto, creo que el tester en muchos proyectos es una figura que con el encaje adecuado puede aportar gran valor.