Lo reconozco… soy muy pesado con esto de los test automatizados. Doy mucho la brasa sobre el tema a quien me quiera escuchar. Y doy mucho la brasa también a quien no me quiere escuchar.
En este artículo voy a seguir dando la plastada con el tema pero centrándome no en lo que supone usar un sistema de pruebas de este tipo sino lo que supone no tenerlo.
Comprobar las cosas manualmente también cuesta dinero
Esta es una cuestión que no se suele tener en cuenta. Todos hacemos siempre pruebas pero las hacemos de manera manual. Y esto tiene un coste muy alto en horas.
Si comparamos el coste de desarrollar un sistema autónomo capaz de probar nuestra aplicación rápidamente con coste el de dedicar gente para probarlo todo a mano vemos que la automatización gana por goleada.
¿Cuánto cuesta que un bug llegue a producción?
Si bien es cierto que tener estas pruebas implica esfuerzo (y dinero) también es cierto que un bug que llega al cliente es muy caro:
- Por el daño que hacen a nuestra imagen.
- Porque arreglar un fallo en producción es mucho más caro que arreglarlo en las primeras fases.
¿Y por qué digo que arreglar un fallo en producción es mucho más caro?
Cuando un desarrollador encuentra el problema lo soluciona y se acabó.
Pero cuando el problema lo localiza el cliente, éste llamará a nuestro departamento de atención al cliente. Desde atención al cliente llamarán al departamento de informática que intentará localizar el error. El desarrollador busca el problema. Una vez localizado el error se soluciona y notifica a atención al cliente que comprobará que está solucionado. Por último se notifica al cliente. Y este es el proceso resumido. Como se puede ver en todo el proceso un montón de gente ha perdido mucho tiempo. Todo este tiempo perdido por tanta gente es muy caro.
¿Dejas de sacar nuevas funcionalidades por miedo a romper algo?
Este es un coste que no se suele tener en cuenta. Seguramente tu equipo habrá experimentado varios errores que se han colado en producción y tendrá miedo de tocar nada.
Poco a poco esto irá contaminando a toda la empresa y se procurará no pensar en cambios ni en nuevas funcionalidades. Se llega a una cultura de «mejor no toquemos nada».
Los fallos que vuelven una y otra vez
Los fallos son muy puñeteros y son como la mala hierba… nunca mueren.
¿Nunca te ha pasado que solucionas un problema y acaba volviendo? Lo arreglas, al de un tiempo haces otra modificación y el fallo vuelve a aparecer. Este es un problema recurrente que se podría solucionar creando un test específico que compruebe que no vuelva a suceder.
El equipo de desarrollo pierde mucho tiempo sacando nuevas funcionalidades
Dado que cada vez que se hace un cambio hay que hacer un montón de pruebas para asegurarnos de no haber roto nada el tiempo de desarrollo para nuevas funcionalidades va creciendo sin parar.
Llega un momento en que la aplicación se convierte en un monstruo difícil de mantener. El coste de trabajar en ella se hace cada vez más elevado.
A consecuencia de esto mejorar la calidad del código es algo inasumible que nunca se hace.
¿Sigues sin convencerte?
No te preocupes, dejar el teléfono descolgado para no recibir las quejas causadas por los fallos o dejar de mirar los emails son también buenas alternativas.
Y poner velas a los santos es posible que también ayude, pero yo no me la jugaría.
¿Cómo empezar con los test automáticos?
Si he conseguido convencerte de las virtudes de automatizar esto el próximo paso es por dónde empezar. Así que en un próximo artículo, si me animo a escribirlo, contaré por dónde empezar.