En los últimos tiempos nos hemos acostumbrado a hablar de pruebas y métricas en el terreno más personal posible, el de la salud.

Quiero aprovechar este momento de concienciación en el aspecto sanitario para incorporar al mundo de las pruebas del software a quienes todavía no hacen tests automáticos.

Y espero reforzar o ayudar a difundir las buenas prácticas a aquellos que ya practican el testing.

Los fallos ocurren

Hemos comprobado que es inevitable la aparición o mutación de virus y bacterias peligrosas. Igualmente es inevitable la aparición de defectos en el software. ¿Por qué? Pues porque...

  • El software está escrito por humanos (al menos por ahora casi todo), que nos equivocamos constantemente (al menos yo y todos los que me he cruzado).
  • Las equivocaciones no detectadas se distribuyen a máquinas, operadores y usuarios de manera... viral.
  • El impacto es mayor cuanto más tiempo tarden en manifestarse los síntomas.

¿A qué te recuerda?

La detección temprana es el mejor antídoto

De lo anterior se deduce, igual que hemos comprobado en la realidad sanitaria, que una detección temprana de un problema es la mejor solución. La libre circulación de un virus por un territorio agrava sus consecuencias cuanto más se prolongue. Llevado al software:

  • Negar el error porque no lo hemos detectado.
  • Retrasar la decisión de parar para arreglar el fallo, porque ¿a quién le gusta dar malas noticias?

¿Te suena de algo?

Y ya sabemos que esta actitud no funciona; luego habrá que emplear otra estrategia. Evidentemente la alternativa es detectar, comunicar y actuar cuanto antes.

En programación tenemos las herramientas y los métodos para llevarlo a cabo: las pruebas automáticas de software.

Entonces, ¿por qué no se hacen?

Hacer pruebas tienen coste

No voy a negar que hacer pruebas tiene coste en tiempo y dinero. E incluso cierta frustración.

  • Para empezar: si no sabes hacerlas tienes que aprender.
  • Para continuar: mientras no tengas soltura, el testing te resultará engorroso.
  • Para terminar: las prueba las hacemos humanos. Luego también pueden fallar; tanto por negligencia como incluso deliberadamente (barrer bajo la alfombra).

La gratificación inmediata versus recompensa aplazada

En la política, en la empresa y en la vida personal nos enfrentamos continuamente a decisiones que contraponen el deseo de satisfacción inmediata versus el aplazamiento de la gratificación. Es duro escoger la segunda.

Pero aún resulta más difícil si el esfuerzo inmediato no espera recompensa sino ausencia de penalización.

Evitar un mal que no ha llegado a ocurrir sólo satisface al que lo impide; los demás no somos conscientes. Para lo demás es lo esperado, es lo normal, no aporta nada... Hasta que te privan de ello, como tenemos ahora muy claro.

¿Algún paralelismo?

Conclusión.

Las pruebas requieren un esfuerzo cuya gratificación aplazada es la ausencia de problemas.

Y lamentablemente esto conduce a muchos a no hacerlas.

Pero; no hacer pruebas, no hacerlas a tiempo, hacerlas mal o simplemente retrasar las malas noticias, genera aún más gasto y pérdida de salud cuando los problemas aparecen.

Porque con la aparición de ese problema no detectado a tiempo, o directamente inesperado, se produce un aumento del temor y la ansiedad ante la posibilidad de que vuelva a ocurrir.

Y esto conlleva una pérdida de confianza en el sistema difícil de recuperar.

En definitiva:

  • Las pruebas son una inversión que aumenta la fiabilidad de tu software a largo plazo.
  • Pero que inmediatamente mejora tu autoestima y tu satisfacción profesional.
  • Porque reducen tu incertidumbre sobre el futuro y eso reduce tu ansiedad.

Las pruebas mejoran tu estado de ánimo, tu satisfacción y tu salud.