Fallos y defectos. Su persistencia y estrategia para mitigarlos.

Posted on 16 abril 2008. Filed under: Calidad del Software, Resolución de Problemas y Gestión de Incidentes |

Al respecto de los defectos reportados, su persistencia y/o mutación, sucede que los defectos reportados por Testing en algunos casos fueron persistentes hasta tres (3) ciclos y en algunas situaciones más. El defecto es tratado normalmente según el  proceso normal establecido. Lo cierto es que nunca tienen el mismo comportamiento ni los mismos síntomas y por lo general no se reportan como nuevos defectos sino que se le aumenta la persistencia y en el mismo defecto se reportan las No Conformidades. Así hasta que definitivamente se obtiene un resultado satisfactorio.

Inicialmente puede decirse que el fallo es reportado por Testing con un bajo análisis de los defectos que lo provocan, lo cual dentro de un ciclo de pruebas de sistemas es correcto, inclusive sin ningún análisis sino la mera detección y reporte.

El o los defectos puede/n escalar a otros niveles, como por ejemplo a las prueba de campo (producción), sin ser necesariamente un fallo y ser detectado/s allí con cierto grado de mutación.
Se asume que el fallo persiste y se lo reconoce como si se tratara del mismo que alguna vez se detectó en fases anteriores de las pruebas, pero en realidad puede tener otra naturaleza. Un ejemplo son las fechas con formato invertido en algunos campos, las cuales no representan necesariamente un fallo salvo una incomodidad visual, pero que en algunas situaciones especiales pueden llevar a la toma de una decisión incorrecta si no se percibe por parte del usuario. 

Es importante notar que esta mutación de defectos se va dando a medida que se hicieron correcciones sobre los fallos reportados 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

Otro motivo importante es la falta de definición de los requerimientos, la esencia del concepto que da vida a los mismos para lograr tangibilizarlo como 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 que nos permita conocer la mecánica de uso involucrada y como se puede agregar valor funcional.

Esto puede implicar pactar una interacción fluida con el Cliente o un Usuario Líder de modo tal que se involucre en el proyecto y valide la evolución de los requerimientos. 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

También la falta de Estimación de Riesgos posibles para cada uno de los requisitos impacta en la aparición (formación diría yo) de los fallos y defectos, puesto a que es posible iniciar las fases de construcción 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", debido que las resoluciones son encaradas del mismo modo en que se construyeron los componentes.

Se puede considerar como muy valioso reconocer en que fase impactarían los riesgos detectados y de ese modo establecer la estrategia que mejor se ajuste a la mitigación, eliminación o aceptación del riesgo.
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 es posible que se deba tener un nombre claro del riesgo, una descripción de que lo produce y como se manifiesta (síntomas), los antecedentes de ocurrencia en caso de que los tuviera, y la cantidad de veces que se podría presentar según los antecedentes. Es importante que cada uno pueda realizar una lectura inteligente, simple y tienda a la estrategia correcta.

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 una grave falencia al dar de alta los fallos y/o defectos, pues se lo hace sin un Subjet claro que exprese en forma simplificada del problema ("sujeto2+"situación no deseada"). Así mismo el cuerpo del reporte no es más que una descripción del incidentes sufrido por  usuario y por ende no involucra ningún análisis ni apunta a ninguna alternativa de solución.
En este sentido es prácticamente imposible diagramar próximos pasos y coordinar acciones efectivas y eficientes (teniendo en cuenta un Calendario)

Motivo 4

Un importante motivo a considerar es la falta de análisis del fallo y los defectos que lo provocan. Así mismo no reconocer su impacto en el requerimiento del cliente y en su entorno de trabajo a nivel del negocio y no solo del sistema.

El análisis de los fallos y defectos, tiene que tener al menos un responsable. Típicamente se imputa la responsabilidad a SQA, el cual debe reconocer los factores mencionados a nivel de impacto y riesgos, detectar la naturaleza de los fallos y posteriormente emitir el reporte de los mismos. Esto podría implicar también que el mismo equipo SQA es responsable de categorizar no solo el carácter de Severidad, sino también la Prioridad con la que se debe dar resolución a cada uno de los fallos.

Una estrategia de este tipo puede denotar ciertas demoras en el proceso relentizandolo por no hacerse el reporte de fallos y/o defectos en forma instantánea, una vez que son detectados en los ciclos de pruebas. Sin embargo, puede por otro lado acelerar 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 una conciencia general para todos los involucrados en la Gestión de Problemas para propender a la generación de Soluciones Técnicas definidas correctamente según el propósito de cada resolución y que tomen como entrada los Subjetcs y Descripciones correctamente formados.
Esta formación impactará directamente en la mejora del trabajo proactivo evitando el trabajo en solitario y aumentando las capacidades de seguimientos anticipados. Aunque parezca contradictorio, su vez genera un buen grado de independencia de trabajo para el resto del equipo de trabajo en base a la mejora sustancial que implica en nuestra base de conocimientos.
También estimula la limpieza del proceso de la organización y facilita el conocimiento individual para fortalecer el conocimiento grupal.

Liked it here?
Why not try sites on the blogroll...

A %d blogueros les gusta esto: