Tuve el gran place de entrevistar a Natalia Lehmann, una desarrolladora de software Argentina que desde hace más de una década viene trabajando para Grupo Esfera. Natalia es una apasionada por el lado técnico de la Agilidad, especialmente por las pruebas automatizadas que conducen a desarrollar software de mayor calidad. Precisamente ella escogió compartir sus experiencias prácticas acerca de cómo viene haciendo desarrollo guiado por pruebas de aceptación.
Natalia comenzó hablando acerca de la tension que existe entre la automatización de pruebas de aceptación y las dificultades técnicas para poder implementarlas sobre la interfaz gráfica y hacerlas correr en un tiempo razonable. Natalia comentó también que ella y son compañeros de trabajo son defensores del valor de automatizar pruebas de aceptación, pues han visto su beneficio ya que estas son fundamentales para garantizar que se pueda avanzar sin romper funcionalidad anterior y mejorar la calidad de un sistema.
Natalia mencionó que probar manualmente es un proceso repetitivo que invita a cometer en algún momento un error. Las pruebas automáticas ayudan a plasmar acuerdos con los usuarios pues estas son definidas en un lenguaje de texto legible que tanto los desarrolladores como los interesados entienden. Las pruebas de aceptación bajo este formato son ejecutables y constituyen parte de la documentación viva de un sistema.
Para Natalia hacer ATDD (Acceptance Test Driven Development) ayuda a enfocarse en lo que realmente es importante, ademas de ayudar a identificar cuál es el flujo principal. En contraposición, dejar de lado la escritura de pruebas automatizadas va provocando que el sistema vaya quedando con puntos que no se pueden regresionar automáticamente y por tanto se introduce la necesidad de pruebas manuales.
Natalia mostró la Pirámide de Pruebas que fue introducida por autores como Martin Fowler y Mike Cohn. En resumen la pirámide plantea que deberíamos tener muchísimas pruebas unitarias, muchas pruebas de servicio o integración, y algunas pruebas de interfaz gráfica de usuario. Esta pirámide va probando de abajo hacia arriba que la integración realmente ocurre. Un otro detalle es que las pruebas unitarias corren muy rápido en comparación de las de interfaz gráfica. Las pruebas unitarias corren sobre componentes aliados, identifican mejor los fallos, y son repetidles; por tanto son muy valiosas mas no detectan problemas de integración.
Las pruebas sobre la interfaz gráfica son muy lentas y pocos confiables ya que a veces dan falsos positivos; el otro problema que traen consigo es el esfuerzo que hay que dedicarle a su mantenibilidad. Un factor importante es que estas pruebas son mucho más rápidas que un usuario real interactuando con el sistema. Su nivel de precision también es cuestionables pues cubren flujos de trabajo completos y muchas veces es difícil localizar el error, dijo Natalia.
Natalia comentó acerca de alternativas que utilizaron (mock objets) para poder acelerar la corrida de pruebas de interfaz gráfica. Tener resultados repetibles fue el otro desafío que enfrentaron, probar contra APIs (Application Programming Interfaces) o modelos subyacentes fueron alternativas que Natalia también trató.
Natalia contó que la composición de los equipos con los que trabajado son de desarrolladores, sin profesionales que hagan pruebas manual; por tanto el perfil de los integrantes de su equipo ha contribuido grandemente a que automaticen la gran mayoría de las pruebas de los sistemas que construyen.
Para cerrar Natalia aconsejó, empezar a mirar herramientas como Cucumber que ayudan con las pruebas de aceptación. Una reflexión final que pasó Natalia fue que pese a de los problemas técnicos que causan, el desarrollo guiado por las pruebas es un camino que vale la pena andar.
Sobre el Autor: Juan Banda
Juan se especializa en entrenar, mentorear y hacer coaching de equipos Agiles para que en corto tiempo puedan alcanzar resultados asombrosos. Juan es también un agente de cambio que ayuda a que empresas completas vuelquen sus prácticas hacia formas más humanas de trabajo. Juan es un Certified Scrum Trainer (CST) y LeSS Friendly Scrum Trainer. Su formación universitaria incluye un grado de Magister en Administración de Sistemas de Información conferido por The University of Illinois at Chicago.
