menu_superior

Cuanto se tarda en hacer un plan de pruebas (I)

cinta metricaHace tiempo escuché una frase que supuestamente pronunció Dwight Eisenhower sobre la planificación “El plan no es nada, la planificación lo es todo”. Independientemente de que la autoría sea correcta,  la recuerdo a menudo porque me parece especialmente acertada en su aplicación a la ingeniería ya que el éxito de los proyectos, del tipo que sean, descansa en los planes y en la planificación.

Lo que entiendo que quería decir Eisenhower con esta paradoja es que el plan es algo estático, que se hace a priori, con unas condiciones más o menos conocidas y la planificación es el proceso de hacer el plan, es algo dinámico y que analiza unas circunstancias conocidas (aunque no inmutables). Por lo tanto para llevar a cabo proyectos complejos serán necesarios varios procesos de planificación (planificación, replanificación y seguimiento) y, con toda seguridad, varias versiones del plan.

El plan de pruebas no es nada, la planificación lo es todo

Extrapolando este análisis al testing podemos considerar que “el plan” es el plan de pruebas o el plan de proyecto. En este post voy a aplicarla exclusivamente sobre el plan de pruebas.

En mi experiencia, un plan de pruebas es un documento que tendemos a considerar equivocadamente como algo inmutable, blindado frente a las circunstancias. El enfoque no debería ser algo tipo “No importa lo que ocurra, tenemos un plan y hay que cumplirlo sea cual sea el contexto”, sino algo más parecido a “el plan es un documento de intenciones, que deberíamos seguir mientras sea posible y cambiarlo para adaptarlo a las circunstancias cuando sea necesario”.

La idea que quiero transmitir es que si lo realmente importante es el proceso de hacer un plan cada vez que cambian las circunstancias,  el plan es algo que habremos de revisar con cierta frecuencia.

La actitud de considerar el plan como algo intocable es demasiado rígida y no beneficia en nada a las pruebas, que deben ser algo dinámico. Yo siempre he sido muy finalista y pienso que tanto el plan como otros documentos, no son más que herramientas en las que apoyarnos para conseguir nuestro fin, que no es otro que hacer software de calidad. Insisto: Herramientas, un medio para conseguir un fin. Es un poco frustrante que a veces haya que recordar que el proyecto no consiste en hacer el plan, que no producimos planes, que somos parte de una organización que produce software de calidad. Eso es para mí lo inmutable, lo realmente importante y para lo que estamos trabajando.

Me he extendido mucho más de lo que pensaba inicialmente. Todo lo anterior, que pretendía ser un preámbulo me ha quedado un poco largo, así que desdoblaré este post y dejaré para la segunda parte algunas cuestiones ¿Cuánto tiempo invertir en un documento que vamos a tener que cambiar con frecuencia?  ¿Realmente merece la pena hacer un plan de pruebas? ¿Hasta que nivel de detalle llegamos?

, , , ,