Todo proyecto de software tiene una etapa de pruebas y éstas por lo general son ejecutadas por el equipo que desarrolla dicho producto. La mayoría de las pruebas son llevadas a cabo bajo condiciones normales o en ocasiones se realizán las llamadas pruebas de stress. Estas pruebas son elaboradas en un ambiente poco favorable para el software; por ejemplo si es una aplicación web y el módulo a probar es un listado de empleados, se realizan pruebas cargando 100 veces más de lo que se piensa subir al sistema y si es necesario se aumenta esta cifra exponencialmente hasta comenzar a notar anomalías.
Fig. 1 . - Una conexión de red bajo condiciones adecuadas
Después de esta etapa en el "laboratorio" siguen las "pruebas del cliente", las cuales no se apegan a un proceso de "testing" que un equipo de desarrolladores podría imaginar y las condiciones muchas veces escapan de lo imaginable.
Todo lo anterior sale a colación por que hace unos días recibí una solicitud para la mejora de un módulo que es parte de un CMS desarrollado para una empresa que publica clasificados. Dicho módulo poblaba una lista de colonias dependiendo del estado que se seleccionara previamente y las colonias las recuperaba por medio de una llamada asincrona al servidor. El cliente necesitaba que las colonias se cargarán "más rápido" y al revisar la velocidad de dicha carga todo marchaba perfectamente, el problema entonces era averiguar que pasaba del lado del cliente o del lado del servidor donde se encontraba el sistema en productivo. Para encontrar el problema decidí emular localmente el sistema bajo condiciones normales en mi equipo de casa y las cosas marchaban bien. Después de un rato lo subí al servidor de productivo y fue hasta entonces que pude sentir la experiencia que el cliente narraba y al ir analizando el rendimiento de mi conexión a Internet note que tenía un cliente P2P encendido que estaba consumiendo un considerable ancho de banda tanto de subida como de bajada y eso perjudicaba mi comunicación con el sistema en línea. La solución entonces fue contactar con el cliente y preguntarle si había revisado el sistema usando algún cliente P2P o alguna otra aplicación que consumiera un gran ancho de banda, y al hacer esto el cliente revisó nuevamente el sistema dándose cuenta que el problema no era más que el ambiente donde realizó sus pruebas anteriormente.
Fig. 2 . - Una conexión de red usando un cliente P2P.
Por eso es una practica obligada descartar lo más obvio y a veces absurdo antes de llegar al extremo de analizar el código en busca de un "bug" o proponer un nuevo requerimiento que suponemos solucione la necesidad del cliente.
No hay comentarios.:
Publicar un comentario