Uno de los pasos mas importantes para los que desarrollamos software es la fase de pruebas o testing. Hay a quien cree que se puede reducir y así sacar antes el proyecto terminado, pero eso solo suele llevar a una mala calidad de acabado.
El ejemplo ilustrativo más clásico y risible para los aficionados a los videojuegos es Big Rigs, la peor implementación de un juego comercial jamás existida. ¿Alguien se puede imaginar un juego de carreras donde los rivales no abandonen la línea de salida, no funcionen las colisiones, no exista el límite de velocidad cuando pones la marcha atrás o que aunque te estrelles hayas ganado la carrera? Pues existe, y tras buscar intensamente en el manual el certificado del supuesto testing se te queda la misma cara que al capitán Picard (y después te planteas que el tal Sergei Titov merece que le emitan una orden de alejamiento de desarrollos informáticos).
Un bochorno así igual no resulta tan divertido cuando hablamos de un programa que influya en nuestra vida diaria. Nuestros programas de uso diario (especialmente los críticos) no deberían fallar, porque nos podemos estar jugando mucho. Desde que existe el IoT (Internet of Things o Internet de las cosas), tenemos programas en casi todas partes y conectados a Internet, por lo que su fiabilidad y securización no deberían ponerse en juego. Plantearos lo que pasa cuando falla por ejemplo un sistema de control de semáforos o un sistema de ventilación y veréis que sus consecuencias no son especialmente graciosas.
El tester no es el malo, ni viene a echar abajo un trabajo de desarrollo, ni a generar retrasos en producción: es una persona que realiza la valiosísima labor de prevenir futuros riesgos. Cómo tal es alguien que se merece respeto y no una figura prescindible ni un gasto superfluo.
Comments
No comments yet. Be the first to react!