El camino de baldosas amarillas, Dorothy

En un artículo del pasado mes de diciembre hacía referencia a la Calidad en proyectos informáticos.

A raíz del mismo, mantuve una interesante conversación con un compañero de trabajo en la cual estuvimos hablando de la importancia de la pruebas y del poco rigor que en ellas se aplicaba, con la consecuente falta de calidad.

Él sostenía que, en general, era problema de dejadez de los integrantes del equipo, especialmente los programadores, y de la falta de tiempo.

Sin embargo, aunque para mí son factores que sí son importantes, no creo que sean los fundamentales.

A menudo, en un proyecto y de manera repetitiva se oye la frase “tenéis que probar”. Pero, realmente, ¿el equipo sabe qué significa?

La respuesta habitual, cuando le preguntas a un programador, es “claro que he probado”. ¿Y qué ha probado? Pues el camino de baldosas amarillas. Es decir, el camino ideal 1-2-3 pero no ha considerado otras opciones alternativas y más rebuscadas.

Esto se produce, en mi opinión, por tres razones principalmente: por falta de tiempo, por dejadez, y, sobre todo, por ignorancia.

Como véis, coincido en las dos primeras con los argumentos que mi compañero esgrimía, pero pueden llegar a ser secundarios al lado del tercero.

La falta de tiempo suele ser inherente a un proyecto. Debemos asumirlo y cubrir ese riesgo de la mejor manera posible. La manera de hacerlo dependerá de las características particulares del propio proyecto y servirá como argumento para otro artículo futuro.

Que un integrante del equipo no asuma la responsabilidad de las pruebas suele advertirse pronto, ya que con la primera acción (pulsar el botón Aceptar, rellenar un campo obvio, etc) saltan errores. Tiene sólo dos soluciones: se reconduce o se aparta. En cualquier caso, debe ser un riesgo a eliminar.

Sin embargo, la tercera razón, la ignorancia, requiere un esfuerzo adicional para corregirla aunque si se logra, los resultados son excelentes. Resulta la mejor inversión de cara al futuro.

En nuestra formación técnica nos enseñan a crear procedimientos, a comentar el código, a utilizar correctamente la sintaxis del lenguaje de programación, a realizar diagramas de gantt, etc pero ¿nos enseñan a probar? Yo creo que no. Es más, se repite una y otra vez la frase de “hay que probar más”. Bien, pero ¿cómo? Un programador prueba, claro que prueba, pero ¿lo hace correctamente? ¿Sabe él que lo está haciendo mal? ¿Conoce la manera de hacerlo?

La respuesta es, en general, única: NO.

Nadie nos enseña a probar. Aquellos que lo hacen bien es porque han seguido un proceso de autoaprendizaje, basado en un espíritu crítico y en la creencia de que una hora invertida en solucionar problemas en desarrollo son muchas más que nos ahorramos una vez puesto en producción.

Personalmente, cuando programaba, me ponía muy nervioso tener incidencias, ya que, por un lado, cuando llegaban solían interrumpir el proyecto que estuviera haciendo en ese momento, y eso solía causar, o bien retrasos, o un esfuerzo extra por mi parte. Por otro lado, tener una incidencia es como una marca señalando que has hecho algo mal y que te has equivocado. Detesto equivocarme.

Sin embargo, no se puede esperar esta reacción de todo el mundo. A veces hay que provocar la chispa.

¿Cómo hacerlo?

Hay muchas maneras, pero las meras palabras no son suficientes. Hay que recurrir a los hechos.

Personalmente, una práctica que creo que resulta extremadamente útil es reunirme a revisar con el programador lo que ha implementado y probarlo juntos. Prefiero que sea él quien maneje el ratón y el teclado, de manera que, cuando le pido hacer algo que no ha probado o que ni siquiera ha contemplado, se nota vacilación y cara de “uy, espero que no falle…”. Además, cuando la ventana o el proceso fallan, son conscientes de que por mucho que crean que han probado, se han dejado cosas por el camino.

De esta manera, creo que ambas partes ganamos:

- yo reviso las funcionalidades de los módulos y puedo conocer detalles incluso de implementación que, en ocasiones, sólo el programador tiene frescos.

- el programador aprende a probar. Ve que hay muchas alternativas aparte de las que él había considerado y, seguramente, en la próxima revisión, los trucos que ahora ha visto que uso para probar, los casos raros, etc los tendrá en cuenta, aunque sólo sea para no quedar en evidencia. Poco a poco la frase “sí, he probado” tendrá más veracidad e incluso él se fiará más de su propio trabajo.

Probar una aplicación es complejo, y de hecho hay toda una rama de la informática dedicada al estudio de métodos y herramientas de test. El objetivo de este artículo no es entrar a profundizar en estos aspectos, sino sólo concienciar a todos los que participamos en proyectos que, si nadie nos dice lo contrario, lo normal es que seamos como Dorothy y vayamos por el camino de baldosas amarillas, todo ideal y maravilloso.

Desgraciadamente, los usuarios son más como el conejo blanco, que va saltando de un lado para otro, sin ningún sentido. Por lo tanto, hay que pensar como ellos y estar preparados para el caos.

Esta entrada fue publicada en General, calidad, formación, recursos humanos, riesgos y etiquetada , , , . Guarda el enlace permanente.

3 respuestas a El camino de baldosas amarillas, Dorothy

  1. Joaquín Vilches dice:

    Hola Sergio,

    jeje, qué recuerdos cuando he leído tu post: se nota vacilación y cara de “uy, espero que no falle…”. Eso me suena :D
    Ahora que estoy al otro lado insisto, hasta ser pesado, en la importancia de hacer pruebas y de hacerlas bien.
    Si se tiene un documento de pruebas completo no es dificil. De hecho, el tester no necesita ponerse en el lugar del usuario. Únicamente tiene que seguir los pasos que indica el documento.
    Ya que en el desarrollo de un proyecto se incluye la estimación de las pruebas, hay que aprovechar ese tiempo para hacerlas bien y evitar sustos posteriores.

    Un abrazo.

  2. Hola Joaquín!
    qué buena noticia ver tu comentario, me he alegrado mucho.
    Tú me has sufrido, ya sabes que continuamente os insistía en las pruebas, aunque no siempre el caso que se me hacía era el que esperaba :)
    Lo cierto es que la elaboración de un plan de pruebas facilita la tarea y, además, aumenta la motivación para realizar los test.
    ¿Qué tipo de información incluyes tú en el plan? ¿Qué datos consideras como mínimos?
    Un abrazo

  3. federal student loans dice:

    My cousin recommended this blog and she was totally right keep up the fantastic work!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

*

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>