Defectos: persistencia, mutación y estrategia para mitigarlos

Sucede que los defectos reportados por Testing en los diferentes ciclos de pruebas, suelen escalar a otros niveles como por ejemplo, a las prueba de pre-producción o como ya sabemos, hasta el cliente mismo.
Cuando los son defectos detectados en estas instancia tardías, usualmente suelen ser verificados por testing o por el departamento de soporte. Allí se pueden observar comportamientos diferentes sobre funcionalidades que habían sido ya “aprobada” en ciclos de pruebas formales anteriores y que estos comportamientos no concuerda con defectos o fallos reportados en etapas regulares del testing.
Vsito así lo primero que se asume es que la cobertura de pruebas no fue buena o suficiente, pero la realidad puede estar conformada por otros componentes.

Cuando se descubren nuevos síntomas, e inclusive los comportamientos no son los esperados en instancias avanzadas del testing (del proceso de desarrollo en definitiva), por lo general se comete el error de reportar estos eventos como nuevos defectos, desasociándolos del reporte original.
En lugar de esto, podría ser conveniente utilizar un “campo de persistencia” que se pueda incrementar, mientras que también se le agrega al mismo defecto otro ítemes de software que evidenciarían algún grado de mutación.
Pero para que esto suceda debemos re acomodar varias prácticas y simplificarlas eficientemente.
Esto es posible si evitamos algunas malas praxis durante el reporting como:

* Poco o ningún análisis del defecto
* No inclusión del dataset aplicado
* Omisión de detalles de las condiciones medioambientales del testing
* Falta de una lingüística unificada
* Omisión de pasos para replica
* Desasociación con los requisitos

Es importante notar que la mutación del defecto, por lo general se va dando a medida que se hacen correcciones en desarrollo y es aquí mismo donde uno se detiene a pensar en el por que de la persistencia.
Me interesa analizar el contexto para reconocer esos motivos:

Motivo 1

Falta de entendimiento de los requerimientos relacionado con una funcionalidad.
Este motivo podría tener muchos frentes para atacar, sin embargo yo me centro en que se debería aumentar el análisis desde el lado de QA/Testing para conocer la mecánica de uso involucrada y cual es el valor funcional agregado. Con este tipo de análisis comprenderemos el tipo de testing a aplicar para que también sea una actividad de valor. Con esto, estamos imprimiendo en forma directa la posibilidad de realizar buenos análisis cuando detectamos defectos o fallos.
Esto puede implicar pactar una interacción fluida con otros roles involucrados, y por que no con el cliente, Product Owner o “usuario referente” de modo tal que se involucren en el proyecto y validen la evolución de los requerimientos y el impacto de defectos.
Este mismo usuario en un esquema de validaciones y verificaciones, puede ayudarnos en gran medida a la detección temprana de cambios y principalmente al planteamiento de las estrategias para afrontarlos y establecer un “criterio de fin” en base a la completitud necesaria del requisito.

Motivo 2

Falta de gestión de riesgos para cada uno de los requisitos. Esto impacta directamente en la aparición (formación diría yo) de los defectos, puesto a que es posible iniciar las fases de desarrollo sin tener conciencia de los problemas que debemos evitar para generar un componente completo. Este aspecto también favorece a la mutación de los defectos una vez que los fallos fueron detectado, reportados y “solucionados” (entre comillas), debido que las resoluciones son encaradas del mismo modo en que se construyeron los componentes, es decir sin análisis de riesgos.
Teniendo en cuenta que se debe evitar un impacto desfavorable, se pone en conocimiento de los riesgos detectados a los responsables de cada fase y luego al equipo involucrado en la fase.
Para esto hay que tener una clara definición del riesgo, una indentificación de que lo produce y como se manifiesta (síntomas), los antecedentes de ocurrencia en caso de que los tuviera, y la frecuencia con la que se podría presentar según los antecedentes.
Es importante que cada uno pueda realizar una lectura inteligente, simple y se tienda a la estrategia que mejor se ajuste a la mitigación, eliminación o aceptación del riesgo.

Motivo 3

Una vez que los fallos y/o defectos escalaron a un ambiente de producción, los mismos son reportados por los usuarios finales bajo algún esquema de “Mesa de Entrada” al “Soporte del Sistema”. Allí mismo se incurre en un grave error al dar de alta los fallos sin un lenguaje específico para el dominio y se da cabida a la entrada de problemas que podrían ser mal interpretados por su debersidad linguistica.
Es necesario que cada problema se exprese en forma simplificada, con lenguajes uniformes o similares a los que el equipo de desarrollo conoce y estos reportes cuenten, como dije antes, con datos suficientes que faciliten diagramar próximos pasos y coordinar acciones teniendo en cuenta un Calendario.

Motivo 4

Falta de análisis del fallo y los defectos que lo provocan. El análisis de los fallos y defectos, tiene que tener al menos un responsable. Típicamente se imputa la responsabilidad a SQA, pero he observado que las revisiones y análisis de éstos ítemes llevados a cabo por varios involucrados, ayudan a reconocer más cabalmente los impactos y riesgos, detectar la naturaleza de los fallos categorizarizarlos por su severidad y prioridad de resolución.
Una estrategia de este tipo no implica relentizar el proceso, sino que por el contrario aceleran la respuesta del equipo y aumentan la calidad de las resoluciones, disminuyendo la persistencia de los defectos y su mutación, como también garantiza en mayor grado que se resuelven en un orden que agrega valor al proceso en general.

Es necesario crear en todos los involucrados, una conciencia general a cerca de la “Gestión de Problemas” en los proyectos,  para propender a la generación de soluciones técnicas definidas correctamente según el propósito de cada resolución y para esto tenemos inicialmente, un importante volumen de datos de entrada en los reportes de fallos y defectos, tanto por parte de nuestros clientes como por parte de QA/Testing.
Esta formación impactará directamente en la mejora del trabajo proactivo evitando el trabajo sin valor y aumentando las capacidades de anticipación.
Aunque parezca contradictorio, su vez genera un buen grado de independencia de trabajo para todos, pues este enfoque suele formar la base conocimientos que todos pueden reutilizar. También estimula la limpieza del proceso de la organización y facilita el conocimiento individual para fortalecer el conocimiento grupal.

Advertisements

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.