El testing, la verificación de calidad, etc., no es algo que hayamos inventado los informáticos. Existe en muchos rubros, y bueno, es algo que traemos innato, quizá en algunas culturas más que en otras, pero a fin de cuentas todos estamos probando cosas, evaluando calidad, “criticando”… En las últimas semanas vengo tomando un curso de steel framing para un proyecto de auto-construcción que tengo con mi novia, y en la clase de hoy estuvimos hablando de la importancia del testing cruzado, o validación por pares.
En este tipo de construcción en seco, uno arma paneles (marcos de metal) utilizando distintos perfiles galvanizados. Como estos paneles constan de distintas piezas que se van uniendo con tornillos, y todo tiene que quedar muy bien armado y en escuadra, es fundamental ir haciendo verificaciones constantes de cómo están las diagonales, si se conservan los ángulos, si estamos armando bien la estructura. En particular, el profesor mencionó la técnica de validación cruzada como una muy buena práctica, y los argumentos que utilizó para justificarlo fueron los mismos que utilizo al hablar de testing de software, de probar de a pares, de probar de manera independiente.
Contaba, que cada vez que uno está armando algo termina viendo las cosas a su manera, y quizá otro con la mente fresca pueda venir con otra visión y encontrar errores en forma mucho más fácil y rápida. Cosas que nosotros mientras construimos no nos dábamos cuenta, suelen ser obvias para otro que estaba haciendo otra cosa. Es increíble como sus palabras eran exactamente las mismas que las que se utilizan al justificar el testing cruzado, ya que entre desarrolladores nos podemos probar las cosas que estamos desarrollando en forma cruzada, y aportar en poco tiempo encontrando errores que el que estaba construyendo no los estaba viendo…
Con esto no quiero decir que hacer software se compare a construir casas, pero hay prácticas que son muy aplicables. Ni que hablar que el test se hace revisando el plano (la especificación) 😀
