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.

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