Business Central ofrece un framework de testing automatizado que nos permite probar el buen funcionamiento de nuestros desarrollos una y otra vez, asegurando que no solo funcionarán correctamente hoy, si no que también lo harán mañana, pasado, y el año que viene.
Bien implementado, el testing hará que podamos desarrollar en menos tiempo y con menos bugs. Un win-win de campeonato. Pero no solo eso, hará también que el mantenimiento a futuro sea menos costoso, garantizando que podamos mantener el ritmo de desarrollo a medida que el software crece. Así que win-win-WIN.
🔵 Los costes del testing
Muchas de las reticencias que he encontrado en los desarrolladores de Business Central a la hora de empezar a implementar testing en su trabajo se basan en el coste. Se tiene la impresión de que el testing es costoso y de que no hay ningún cliente que quiera pagarlo, así que ni siquiera se empieza a hacer testing, lo que hace que nunca acabamos de ver sus beneficios.
Dejadme responder a la pregunta: ¿cuánto cuesta el testing? Para mi, la respuesta es clara: a nivel monetario, cero, no cuesta absolutamente nada. Ni el cliente ni nadie tiene que pagar un Euro extra por implementar testing. Es más, incluso me atrevería a decir que, basándome en mi experiencia, aplicar testing resulta incluso más económico que no aplicarlo.
Ahora bien, para que el testing resulte en ahorro hay que hacerlo bien, ya que mal implementado puede llegar a duplicar los costes de desarrollo.
🔵 ¿Cómo NO ❌ tengo que hacer testing?
Para que resulte un ahorro realizar testing, hay que cambiar la metodología de desarrollo. Típicamente, la forma en cómo desarrollamos sigue estos pasos:
- Se toman los requerimientos.
- Se toma una decisión sobre la forma en que se implementarán los requerimientos.
- Se empieza a desarrollar.
- A medida que se desarrolla, el programador publica sus cambios de forma incremental y realiza pruebas manuales para asegurar que el código que acaba de escribir funciona correctamente
- Nos damos cuenta que tenemos que cambiar ligeramente el rumbo del desarrollo.
- Cambiamos el desarrollo.
- Publicamos y probamos que el cambio ha sido satisfactorio a grandes rasgos, pero no volvemos a probar los mil y un detalles que ya teníamos programados, probados y funcionando. Algunos de ellos pueden haber cambiado su comportamiento con los cambios recientes (lo típico de “tocas aquí y estropeas allí”), pero no nos damos cuenta.
- Acabamos el desarrollo.
- Un consultor realiza algunas pruebas básicas para asegurar que lo que se ha desarrollado es efectivamente lo que el cliente había pedido. Pero típicamente solo prueba el “happy path”, la casuística fácil, así que los bugs en las casuísticas más complejas no se detectan.
- Se entrega el desarrollo al cliente para que sea él quien realice las pruebas de verdad. Al fin y al cabo los usuarios son los que conocen sus casuísticas, sus datos y su flujo de trabajo. Les pedimos que hagan pruebas exhaustivas con datos de verdad.
- Los usuarios no saben nada sobre el ciclo de vida del software, así que no son conscientes de la importancia de este paso que hemos delegado en ellos. Si llegan a hacer alguna prueba, será prácticamente la misma que hizo el consultor: pruebas básicas del “happy path” con la casuística más fácil posible.
- El desarrollo se pone en producción.
- Con el día a día y los datos de verdad, afloran las casuísticas más complejas y con ellas los bugs de los que nadie se había percatado hasta el momento.
- El cliente se queja.
- Un desarrollador tiene ahora la presión de corregir el desarrollo a la máxima velocidad posible, porque los errores están parando el trabajo de los usuarios.
- Además, hay que desarrollar un nuevo proceso de corrección de datos por todos aquellos registros en producción que han quedado mal.
¿Te suena todo esto? Muy a mi pesar, apuesto a que sí.
🔵 Pasos que SÍ ✅ debemos seguir con Test Driven Development (TDD)
La metodología de desarrollo que realmente nos ayuda a reducir los tiempos de desarrollo, tanto en la implementación inicial como en el soporte futuro, es TDD (Test Driven Development), en donde los pasos a seguir serían más o menos estos:
- Se toman los requerimientos.
- Se toma una decisión sobre la forma en que se implementarán los requerimientos.
- Se empieza a desarrollar.
- A medida que se desarrolla, el programador publica sus cambios de forma incremental y sustituye el tiempo que utilizaba en hacer pruebas manuales por escribir y ejecutar el código que realiza exactamente las mismas pruebas pero de forma automatizada.
- Nos damos cuenta que tenemos que cambiar ligeramente el rumbo del desarrollo.
- Cambiamos el desarrollo de forma más rápida y eficaz. No tenemos que andar con pies de plomo porque sabemos que si nos equivocamos, los tests nos lo dirán.
- Publicamos y probamos que el cambio ha sido satisfactorio. Podemos volver a probar los mil y un detalles que ya teníamos programados, probados y funcionando. No nos toma ningún tiempo adicional, es sólo cuestión de re-ejecutar los tests que ya teníamos escritos. Si tocamos aquí y estropeamos allí nos damos cuenta enseguida y lo podemos corregir.
- Acabamos el desarrollo.
- Un consultor realiza algunas pruebas básicas para asegurar que lo que se ha desarrollado es efectivamente lo que el cliente había pedido.
- Se entrega el desarrollo al cliente para que confirme que lo entregado es efectivamente lo que se esperaba.
- El desarrollo se pone en producción.
- Con el día a día y los datos de verdad, el desarrollo sigue funcionando tal y como se esperaba 🙌.
Con esta forma de desarrollar, en el punto 4 no iremos más rápido ni más lento, si no que iremos a la misma velocidad a la que estamos acostumbrados porque sustituimos el tiempo que tardamos en realizar una tarea por el tiempo que tardamos en realizar la misma tarea pero de forma distinta.
➡ Es en los puntos 6 y 7 donde encontraremos el ahorro de tiempo, ya en la implementación inicial de las funcionalidades, además de que los puntos del 14 al 16 habrán desaparecido, implicando no solo un ahorro de tiempo, sino también logrando que el cliente esté más satisfecho.
🔵 ¿Quieres aprender sobre TDD? Tenemos la solución
En ClipPlatform encontrarás nuestro curso Testing con TDD, en el que explicamos tanto la metodología de desarrollo como la herramienta con la que realizar los test: el framework de test de Business Central.
No dudes en contactar con nosotras si tienes cualquier pregunta sobre Testing. Además, te animamos a que dejes un comentario 👇 con tu experiencia con TDD.
¡Hasta pronto!
