En esta entrada voy a ponerme un poco en plan abuelo cebolleta, (storytelling si nos ponemos en plan geek) hablando de cuando programaba y de las pruebas de aplicaciones que no podemos fallar. Tiene relación sobre todo con la industrialización de desarrollo, por el impacto que tiene el no probar bien las cosas.
En mis épocas mozas, cuando me dedicaba básicamente a programar, cada vez que le entregaba algún mantenimiento a mi jefa, rezaba (bueno igual es un poco exagerado lo de rezar) para que tardase en encontrarme un fallo. No había cosa que más rabia me diese que tardase poco en encontrarlo, parecía que no le habías puesto interés.
En aquellas primeras épocas programar lo que se dice programar si que sabia, se me daba muy bien, sacaba muy buenas notas en la universidad en las asignaturas de programación. De lo que no tenia ni idea era de trabajar. Es decir de programar en serio, no para una práctica. Bueno el sueldo también iba en consonancia. Por eso me parece importante compartir las experiencias vividas. Es importante «aprovecharse» de los que han recorrido ya antes el camino.
Cuando mas tarde empecé a tener compañeros a mi cargo, he de reconocer que tuve mucha suerte, porque eran muy serias trabajando, les solía decir que había unos errores que no les debía encontrar nunca. Las pruebas básicas, las que alguien sin conocer la aplicación puede realizar.
– Obligatorios: coges cada campo que está marcado como obligatorio, lo borras y le das a buscar, guardar o lo que proceda. Uno a uno y todos juntos.
– Longitudes: coges cada campo y pones el valor máximo. Si es numero todo 9 hasta que no te deje meter más. Si es texto pones una letra, por ejemplo la a, hasta que no te deje poner más y luego dar a buscar, guardar o lo que proceda.
– Formatos: clásico, si es un campo numérico poner letras. Si es un email poner uno inválido, y luego dar a buscar, guardar o lo que proceda.
Estas pruebas como he comentado no las puedes fallar, da una sensación muy mala si el programa falla en cosas como estas. Y creerme, es muy habitual encontrar fallos de estos.
No se quien me comentó que había tenido un jefe que probaba los programas dando teclas sin sentido, casi como lo pudiera hacer un mono. Y conseguía hacer cascar los programas, y el programador de turno se defendía diciendo que no era un uso normal de la aplicación, pero el jefe le contestaba que le daba igual, la aplicación había fallado y no podía fallar.
Muchas veces, por lo menos, a mi me pasaba, que iba probando el programa y corrigiendo errores y cuando ya lo daba por terminado lo entregaba. Como en el anuncio de la tele: ERROR. Cuando creas que lo tienes todo terminado, haz una última prueba global, no sea que hayas arreglado algo y roto otra cosa. Cosa que sucede a menudo.
Hoy día hay técnicas y herramientas para automatizar ciertas pruebas, pero antaño no y cada vez que te encontraban un error y cambiabas el programa las jefas tenían que volver a probar todo y entiendo que se enfadasen porque era un autentico peñazo (Cuando me ha tocado a mi estar en la situación de probador en vez de siendo el probado me he dado cuenta).
Además hay que tener en cuenta una cosa que se nos suele olvidar muchas veces, la «tela». El coste de un analista es mayor que el de un programador. Así que es más barato dedicar un poco más de tiempo del programador para que esté todo mejor probado a entregar algo poco probado y que el analista tenga que dedicar tiempo una y otra vez a probar. Y lo que nos interesa a todos es hacer las cosas lo más económicamente posible, manteniendo los criterios de calidad que se exigen.
A los programadores que he tenido a mi cargo siempre les he dicho que si necesitan más tiempo que lo pidan, siempre que puedan justificar el desvío, pero que no entreguen algo sin probar bien por cumplir las fechas.
Te has esforzado mucho en realizar tu trabajo y luego corres el riesgo de por tonterías dar la sensación de que has hecho un trabajo a la ligera. No es interesante.
