En la película de 1971 "Harry el sucio", Clint Eastwood interpreta a un policía duro e inteligente de la calle. En la escena inicial, detiene fríamente un robo de banco disparando a los ladrones con su enorme y larga pistola Smith and Wesson .44 Magnum. Los disparos suenan y sólo queda un ladrón, herido. Harry se acerca a él y pronuncia la frase que se ha convertido en la firma de la película. "Sé lo que estás pensando. ¿Disparó seis tiros o sólo cinco? Bueno, a decir verdad, en toda esta excitación, yo mismo perdí un poco la pista. Pero como esta es una Magnum .44, la pistola más poderosa del mundo, y te volaría la cabeza, tienes que hacerte una pregunta: ¿Me siento afortunado? Bueno, ¿te sientes punk?" El gamberro se rinde y le pregunta a Harry cuántos disparos le quedan. Harry le apunta con el arma y aprieta el gatillo. El arma está vacía. El ladrón del banco tuvo suerte.
¿Confía en la suerte para asegurar que sus aplicaciones de misión crítica sirvan continuamente a su empresa, día tras día tras día? ¿O tiene un conjunto de procedimientos de prueba previos al lanzamiento que aseguran que se comportan exactamente como se pretende? Hago esta pregunta porque últimamente me preguntan si es necesario o aconsejable reconstruir una aplicación cuando se actualiza el lanzamiento del sistema operativo. Puede que no sea necesario reconstruir su aplicación pero le aconsejo que lo haga, ya sea que use Windows, Linux, VOS u OpenVOS. Mientras que los proveedores de estos sistemas se esfuerzan por asegurar que sus nuevas versiones sean compatibles con el código existente, sigo pensando que el curso de acción más seguro es reconstruir y volver a probar su software en la nueva versión, y no confiar en la suerte.
Cuando se ejecuta una aplicación de misión crítica, creo que es obligatorio hacer este nivel de inversión. De lo contrario, como en la escena de la película, te arriesgas a exponer tu negocio a algunas consecuencias realmente desagradables. La pregunta que tienes que hacerte es la misma - ¿Me siento afortunado? Con todos los cambios que están ocurriendo - nuevo código de sistema, quizás una actualización de la CPU a un procesador más rápido, quizás algunos cambios en la aplicación - ¿cómo puedo estar seguro de que nada saldrá mal?
La respuesta es crear un cuidadoso conjunto de pruebas de calificación. Al reconstruir su código fuente en la nueva versión, recogerá el compilador y las correcciones de errores en tiempo de ejecución que estén disponibles. Puede que descubras que el compilador tiene algunos nuevos mensajes de error que revelan defectos latentes en el código fuente. Al volver a ejecutar las pruebas a nivel de unidad, puede estar seguro de que los aspectos funcionales de su aplicación siguen funcionando según lo previsto. Al volver a ejecutar las pruebas a nivel de sistema, puede estar seguro de que todo funciona conjuntamente. Por último, al ejecutar una serie de pruebas de capacidad o de estrés, sabrá que todo el conjunto de hardware y software puede soportar las cargas más severas que pueda lanzarle. Además, dispondrá de una medida del rendimiento máximo de su aplicación, y podrá utilizar esta cifra en los próximos meses como indicador de cuánta capacidad libre queda disponible.
Hagas lo que hagas, no caigas en la trampa de creer que porque no te hayas topado con ningún problema en la versión anterior, o en el hardware más antiguo y lento, no encontrarás problemas al actualizar. Nuestras propias estadísticas internas muestran que los defectos del software se correlacionan con el aumento de la velocidad del procesador. Los problemas que eran inauditos, o simplemente raros, pueden llegar a ser comunes en un procesador más rápido. El software que funciona durante años puede romperse fácilmente cuando el crecimiento normal de los volúmenes de transacciones lleva a desbordamientos de la cola. La única manera de saber que sus aplicaciones funcionarán correctamente en el entorno cambiado es realizar conjuntos de pruebas tan realistas y completos como sea posible.
No te encuentres mirando un arma preguntándote cuántos disparos quedan. No te arriesgues con una aplicación de misión crítica. No confíes en la suerte. Mantén el control de tu situación. Encuentra los problemas en tu laboratorio, no en tu entorno de producción.
Si sigues estos pasos, puedes relajarte después de las horas de trabajo, sabiendo que has hecho todo lo posible para que tus sistemas funcionen sin problemas. Quizás incluso tengas tiempo para ir a ver una película.
Eso es todo por ahora.
Empresa