LOGS de errores reflejan el funcionamiento del nucleo de nuestras aplicaciones

Algunas estrategias de detección de errores en nuestras aplicaciones pueden parecer demasiado sencillas o desactualizadas, sobre todo con el auge y advenimiento de herramientas potentes, con cientos de reportes, gráficas y métricas para analizar.

Sin embargo prácticamente ninguna herramienta permite a desarrolladores, analistas funcionales y testers de aplicaciones, reconocer la causa raíz de los problemas que aquejan a nuestros desarrollos.

Una técnica sencilla y pronta a aplicar, es la generación de logs de errores en formato TXT. A partir de allí mejorar el proceso de construcción en base a información obtenida del núcleo de funcionamiento de nuestras aplicaciones, es cuestión de solo dejar volar la imaginación.

Aunque un conjunto de nuevas herramientas podrían ser la solución para el ahorro de tiempo y dinero en la resolución de defectos, estas herramientas principalmente deben tener la capacidad de generar reportes que permitan aislar los problemas raíces, haciendo mucho más sencillo el diagnóstico y resolución, sin tener que invertir en costosos ambientes de aislamiento ni tiempos de reproducción.

Estas soluciones no están del todo presente en las actuales herramientas disponibles, ni diseñadas para el comportamiento dinámico de los defectos y solo se permite un análisis estático basado en la mayoría de los casos, en pruebas orientadas de “caja negra”.

Pero tal vez la productividad se vería acelerada exponencialmente si no solo pudiéramos introducir herramientas con estas características dinámicas, sino que a su vez tuviéramos la capacidad de darle a nuestras aplicaciones la capacidad de resguardo y notificación de errores.

Desde el análisis y diseño y bajo un planteo de pruebas que orienten la construcción de los componentes, es posible introducir ciertos niveles de detalles que serían plasmados en “logs de errores”, los cuales pudieran ser de gran utilidad para el diagnóstico de problemas raíces y resolución temprana, es decir en fases de pruebas tempranas.

Al finalizar cada ciclo de prueba, testers y desarrolladores pueden interactuar con mejor foco en las causas raíces de los bugs, errores de construcción e inclusive errores de interpretación de requisitos o detección de requisitos mal formados.

La verdadera potencia de tales “logs de errores” se manifestarán solo si esta solución es diseñada y aplicada en forma armonizadas para que no se entorpezca el trabajo y los resultados sean positivos y bien significativos.

Un beneficio central es que los “tiempo ventana” demasiados cortos para la resolución de defectos, sean mejor aprovechados y el proceso se optimice significativamente.

Hay quienes opinan que se deben modificar significativamente los requerimientos para incorporar estos elementos a los procesos de desarrollo, pero yo creo que el esfuerzo no es tan grande como para evitarlo y los beneficios son tremendos como para dejar de hacerlo.

No piensen en tecnificar demasiado ni en agregar complejidad, orienten esta solución a la simplicidad y facilidad de lectura y comprensión y bastará con utilizar un notepad o archivo tabulado para comenzar a obtener resultados que mejoren la visibilidad del comportamiento erróneo de nuestras aplicaciones.

Potenciar la solución  es cuestión de imaginación.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s