Modificar el "paradigma de pruebas" por el "paradigma de evidencias".

Posted on 3 abril 2008. Filed under: Calidad del Software, Procesos Ágile, Trabajo en Equipo |

En nuestra organización me he visto obligado a modificar el "paradigma de pruebas" por mi "paradigma de evidencias".
Movilizado por la creciente demanda de agilidad que nos impone el ritmo de obtención de proyectos, ya sean para modificaciones de productos existentes o para construcción de nuevos, SQA trabaja fuertemente al principio de los proyectos, desde las minutas de requerimientos, pasando por la ERS, ERP, documentos de análisis, diseño y arquitectura (si es que los hubiere) para localizar los puntos débiles y fortalecerlos en base a observaciones de No Conformidad que obliguen a un enriquecimiento del proyecto antes de pasar a otras fases del mismo. Eso como primera medida.
A partir de esos documentos, SQA comienza un análisis profundo con una alta tasa en la solicitud de consultas técnicas, investigaciones paralelas (documentación técnica, de negocios, de sistemas, modelos de datos, arquitecturas, patrones de diseño, etc.) entre otras actividades y empieza a formar el documento de calidad "Especificaciones SQA" si le quieres dar algún nombre. Este documento lo vamos formando y generando su trazabilidad en base a la descomposición de trabajo (WBS) que hicieron los analistas y líderes de proyectos en una fase de iniciación.
Nuestros criterios de calidad son tanto para el proyecto, para el producto o sistema, como también para los servicios aledaños y son puestos "a mano" del área de desarrollo, como documento matriz para la guía de la calidad esperada.
No generamos casos de pruebas, puestos que solicitamos EVIDENCIAS y este concepto introducido por mi, obliga al equipo de desarrollo a la generación de todos los elementos tangibles que garantizan la completitud y correctitud del componente entregable o no entregable que se construyó. Ya sea que se trate de un componente de interfase, una clase, objetos, esquemas de bases de datos, parámetros de conectividad o cualquier tipo de instanciación, debe quedar una evidencia que puede ser sujeta a una auditoría de calidad.
De este modo, SQA no forma un equipo de testing que espera un producto final desplegado en un ambiente controlado para pruebas, ni forma juegos de pruebas de funcionalidad que puedan ser ejecutados en una fase determinada, pero si ejecuta el uso del sistema bajo un fuerte y concienzudo conocimiento del mismo, debido a que pudo generar los factores de evidencias mínimas requeridas y durante toda la fase de construcción, interactúa con el área de desarrollo haciendo un seguimiento de la formación de las evidencias a satisfacerse.
Es posible que este proceder no reduzca el tamaño ni el esfuerzo de las pruebas, sino todo lo contrario, pero lo que si provoca, es una mejor distribución del esfuerzo para la obtención de calidad.
Quizás no es fácil entender mi modelo, pero es una idea que puse en práctica y esta dando buenos resultados en nuestro ambiente de trabajo. Tenemos mejor adaptación a cambios hasta el punto tal de que SQA puede inclusive no enterarse de las modificaciones introducidas a ciertos requerimientos de algún proyecto en particular, pero minutos antes de recibir el entregable consolida el conocimiento con las EVIDENCIAS y reorganiza los criterios de calidad para aceptar o rechazar el componente. Puede parecer extremista, pero lo es también la exigencia de nuestras necesidades de facturación y los mercados y el volumen de pruebas sería imposible de manejar para un equipo como el nuestro, al menos.
Así que tiro la punta del ovillo para que comencemos a debatir este modelo, si es que les parece debatible.

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

A %d blogueros les gusta esto: