Sobre pruebas y errores

Veo en las noticias las imagenes de una prueba de carga en un nuevo puente de una autovía en Galicia (España). Durante un momento me quedo absorto mirando la larga flota de camiones sobre el majestuoso puente. Impresiona. No puedo evitar pensar: Vaya! eso sí que es una prueba manual. Y luego yo quejándome sobre las pruebas manuales que hacemos en el desarrollo de proyectos software...

Bastan un par de segundos para darme cuenta de la tontería de mi reflexión. Si eso fuera una primera ejecución de una prueba exigente sobre un proyecto software recien construido, el puente se habría caido arrastrando a la flota de camiones tras él.

En el caso del puente, lo que no estamos viendo es todo el proceso de pruebas y control de calidad, que se ha realizado previamente en cada una de las fases del proyecto para evitar errores.

Pero comparar nuestro mundo de desarrollo software -¿ingeniería software?- con el de la construcción o cualquier otra ingeniería es una equivocación. Una equivocación torpe, injusta y desafortunada, porque, entre otras cosas, hace imaginarse a un programador como a un obrero. Así nos va.

Aunque centrémonos en los errores. Errar es humano. Obvio. A veces estamos distraidos, cansados, estresados, desmotivados o simplemente no somos perfectos y se nos escapan cosas.

Otro hecho es que los proyectos software salen a producción con demasiados errores. También obvio si estudiamos el ineficaz proceso de pruebas que se sigue en la mayoría de proyectos, basado en unas pruebas mínimas, manuales y sin documentar. Por lo que las pruebas dificilmente se repiten en el tiempo, aunque se modifique código afectado, haciendo aparecer nuevos errores o, peor aun, haciendo reaparecer viejos errores. ¿Vosotros compraríais algo cuyo proceso de pruebas fuera así?

Lo primero no tiene solución. Pero sí se puede minimizar el efecto. Contratando talento y con motivación.
Lo segundo sí tiene solución. Aplicar un proceso profesional de pruebas, basado en pruebas automatizadas, completas, independiente y repetibles. Los errores seguirán produciéndose, pero la mayoría serán detectados antes de llegar a producción.

Por supuesto, siempre hará falta alguna prueba manual pero, al igual que en el puente, será más un mero trámite de aceptación que el actual infierno de prueba y error sin fin.

5 comentarios :: Sobre pruebas y errores

  1. También hay que pensar la cantidad de años que tiene la "ciencia" de construir puentes, y los añitos escasos que llevamos construyendo software.
    Si es que le pedimos peras al olmo...

  2. Hola Daniel.

    Es ciero que nuestra profesión es joven/inmadura respecto a otras. Aunque también tienes que tener en cuenta que (1) los años en nuestra profesión dan para mucho más que en otras y (2) en el resto de profesiones técnicas aún hay mucho por investigar aunque no lo parezca. Te sorprenderían las investigaciones, nuevas teorías y normas internacionales que se mueven en cimentación (pej). De todas formas ya digo que no quiero entrar en torpes comparaciones.

    A pesar de ello, en mi opinión, tecnicamente es sencillo implantar un proceso de pruebas profesional. Nosotros lo tenemos. Y si lo tenemos no es por iniciativa o apoyo de "arriba" ni porque supieramos hacerlo, es porque lo hemos investigado, comprobado sus ventajas e implantado desde abajo. Al principio habia varios incrédulos, pero hoy todos reconocen su inmenso valor y ventajas respecto al proceso de prueba manual tradicional.

    Yo creo que el tema no es pedir peras al olmo. Sino más bien que si quieres peras, ve al peral y no al olmo. En realidad no está tan lejos un árbol del otro...

  3. No estoy muy de acuerdo en que nuestra profesión sea tan especial y que en los años que hacemos nosotros compense los siglos que se llevan construyendo puentes. Y no esoy diciendo que no haya ninguna novedad en ese tema, simplemente que se les han caido suficientes puentes como para tener cantidad de literatura y "know-how" anterior en lo que basarse.

    Nosotros en cambio no llevamos ni 3 decadas haciendo aplicaciones web y ni llegamos al siglo con la informática y todavía no nos hemos puesto de acuerdo en como hacer muchas cosas, por eso me parece que las comparaciones son difíciles.

    De todas formas, estoy de acuerdo contigo en que se podría hacer mejor, pero precisamente por ser una "ciencia" tan inmadura el problema que hay es más bien, IMHO, social/cultural. Por que, vamos a ver, ¿Quien le pide hoy a una empresa constructora que le haga un puente en dos semanas y por 6000€? Nadie. ¿Un edificio en un mes a un coste de risa? Nadie tampoco. Por que está asumido que hay un coste, lleva un tiempo etc. etc. En cambio nuestra sociedad no ha asumido "el coste de la informática" y pocas veces, excepto en algunos casos críticos como software de donde dependan vidas humanas, se da tiempo a hacer lo que toca y como toca, asumiendo lo que cuesta. Esta demostrado que podemos hacerlo, el problema es que no queremos pagar lo que cuesta.

    Mientras no asumamos eso, estaremos pidiendo peras al olmo, a eso es a lo que me refería.

  4. No especial no. Sólo diferente. ¿Cúantos proyectos han fracasado en los últimos 40 años? Ni idea, pero seguro que muchos miles. Pero vamos, estamos de acuerdo: comparaciones no.

    Y estoy más de acuerdo aun en que sobretodo hay un problema socio/cultural. No sólo en las empresas IT, también en los clientes. Y este problema debe atacarse con educación de abajo a arriba y sabiendo decir NO.

    Pero no sé si estás insinuando que tener pruebas automáticas aumenta los costes. En mi experiencia no es así. Todo lo contrario. Puede ser más costoso si es la 1a vez. Pero eso es como todo. Te aseguro que pierdes mucho más tiempo aprendiendo un framework como Hibernate que programando pruebas automáticas.

  5. "Errar es humano" es un buen pretexto para justificar nuestros errores como programadores, y creo que el "departamento de testeo" no deberia de existir, es algo asi como un mal necesario.

    Lo que me consta es que muchos "programadores", ademas de orgullosos, no saben hacer su trabajo bien, una verdadera tristeza.

Publicar un comentario