Pruebas externas e independientes

Comencé a trabajar en Q-go en el año 2000. Q-go ofrece a las empresas páginas de autoservicio en Internet. Los clientes formulan una pregunta en su propio idioma y con sus palabras e inmediatamente obtienen una respuesta muy apropiada. La eficacia de la solución Q-go es su tecnología del lenguaje natural, la cual permite comprender las preguntas. Esta solución se ofrece como host (ASP), que evidentemente tiene que funcionar las 24 horas del día, los 7 días de la semana, un nuevo campo para mí en aquel entonces.

En mi anterior empleo en universidades e institutos de investigación, esto era diferente. Trabajábamos de ocho a seis. Si la demo de una aplicación no funcionaba, los usuarios simplemente llamaban y nosotros solucionábamos el problema. Y a las seis, parábamos y nos íbamos a casa. Todos los clientes y demás relaciones también se iban a casa. Si el servidor no funcionaba bien una noche, no era inconveniente, ya que no había clientes que notasen el problema.

En Q-go, es completamente distinto. Un servicio debe estar disponible todo el tiempo: día y noche. Al principio, no había herramientas para probar si nuestro servicio estaba disponible o no. La única forma de realizar una prueba era utilizando la aplicación en cuestión. Eso era lo que hacíamos. Durante el día, aunque también de noche, comprobaba si la aplicación se encontraba activa. Nuestros clientes utilizan la aplicación Q-go constantemente y notan inmediatamente cualquier error. Los clientes me llamaban en algunos casos; no es muy agradable escuchar a los propios clientes comentar un problema con el servicio.

Por tanto, desarrollamos algunas soluciones para saber antes que nuestros clientes si se producía algún problema y para poder reaccionar ante éstos rápidamente. ¡Pero los clientes seguían llamando!

¿Cómo era posible? En estudios más concienzudos, quedó patente que el sistema que realizaba las pruebas utilizaba los mismos recursos (ordenadores, redes, servidores de nombre) que el sistema que se probaba... La prueba no se realizaba correctamente en caso de problemas. Las alertas por mensajes SMS no nos llegaban tampoco. La causa era idéntica: utilizábamos el mismo hardware, la misma red y la misma energía (!) que los sistemas que probábamos.

Aprendí algunas lecciones:

• Hay que mantener los sistemas que realizan las pruebas completamente separados de los sistemas que están bajo prueba.
• Es necesario probar los servicios (servidores web, de correo, etc.) desde el punto de vista de los usuarios: el cliente en Internet.
• No se debe olvidar realizar un mantenimiento regular de los sistemas que realizan las pruebas (software y hardware) después de la instalación.