Mi intención al escribir artículos es poder compartir con los lectores mis experiencias y visión sobre el control de calidad del software en la Argentina, su problemática, y lo que he observado sobre su evolución a lo largo de la última década.
Una Mirada Retrospectiva
Durante los últimos años de mi trabajo en sistemas, me he dedicado con exclusividad al control de calidad de software. Una de mis principales actividades ha sido el reclutamiento y entrenamiento de ingenieros de pruebas. Esta tarea no me ha resultado sencilla, dado que es un mercado donde dicha actividad era considerada, hasta hace unos años, como una profesión de segunda categoría, a la cual se podía acceder:
• Como castigo por haber cometido algún error o tener un bajo rendimiento en otro área de sistemas de la organización.
• Como la vía de ingreso de principiantes para trabajar en sistemas y prepararse para mejorar su desarrollo profesional incipiente, el cual desembocaría en el área de desarrollo.
• Como pasajeros en tránsito, que colaboraban en el área de pruebas mientras el área de recursos humanos buscaba para ellos un nuevo proyecto de desarrollo, porque su asignación anterior había terminado.
Sólo unos pocos accedimos por elección a esta singular profesión, recientemente considerada como tal.
A partir del año 2000, y como resultado de haber mostrado a clientes internos y externos, el valor de la actividad, la percepción sobre la misma está cambiando considerablemente. La industria comienza a reconocerla, a valorarla, y a darle un lugar preponderante dentro del ciclo de vida de desarrollo del software. Sin embargo, aunque ya hemos recorrido un largo camino, no es poco ni simple lo que queda por delante.
La Problemática de la Actividad
A pesar de que la actividad ya está en gran medida incorporada al “quehacer cotidiano” de muchas de las organizaciones, esto no significa que como disciplina esté madura, aún queda mucho por mejorar, refinar, expandir y aprender. Permítanme entonces, señalar algunos de los puntos sobre los que debemos trabajar.
El factor humano en la calidad.- La calidad debe ser liderada desde la cúpula de la organización. Necesita ser patrocinada y respaldada a lo largo del tiempo. Además, es responsabilidad de todos y de cada uno de los integrantes de la organización y no sólo del área de calidad.
El entrenamiento.- Pocas organizaciones tienen previsto un plan de capacitación para el área de pruebas. Es habitual capacitar a los desarrolladores, pero de alguna manera es como si realizar pruebas fuera un don con el que se nace, en lugar de tratarse de una disciplina que se aprende con capacitación y trabajo metodológico. Realizar pruebas es una disciplina de la ingeniería y no un arte. Sigue persistiendo el prejuicio de que probar es algo que cualquiera puede realizar profesionalmente, sin entrenamiento. Pretender cambiar certeramente esta idea es difícil; aplica una cita de Einstein: “Es más fácil desintegrar un átomo que un prejuicio”.
Definitivamente cuanto mayor y mejor sea el entrenamiento que recibe un ingeniero de pruebas, mejor será su desempeño y el valor que podrá agregar al producto a probar.
Los vínculos participativos.- No es frecuente que se genere una relación participativa entre ingenieros de pruebas y desarrolladores. Es usual, encontrar dos equipos enfrentados “pasando el juego (el software) del lado del campo del adversario”, lo que desde luego no es beneficioso para el proyecto.
¿Cuándo probar?.- La prueba, por lo general, es incluida sólo al final del desarrollo, cuando hay un “ejecutable” a evaluar. Entonces, por ser la última actividad (antes de la prueba de aceptación y de la entrega del producto), las etapas previas de desarrollo suelen tomar para sí, parte del tiempo destinado a la etapa de pruebas. Esto significa que es la actividad cuyo tiempo es más factible que se recorte, poniendo en peligro la cobertura de las pruebas y, por ende, la calidad del producto.
Sin lugar a dudas, el momento más apropiado para el comienzo de las actividades de pruebas es al inicio del proyecto, lo antes posible, y desde la etapa de requerimientos. Se trata de no llegar al final del desarrollo con un producto que por ejemplo, funciona correctamente “en el escritorio”, pero que no responde a los requerimientos especificados y no le permitirá al usuario llevar adelante la operatoria de su negocio en el “mundo real”.
El final del proyecto es, definitivamente, el momento menos adecuado para enterarnos de esto. Por unanimidad, los libros de la especialidad dicen claramente: “Test often and test soon”, “realice pruebas con frecuencia y tempranamente”.
Acerca de los Procesos
Es prioritario definir la prueba como un proceso, a efectos que, toda la organización tenga en claro cuál es su propósito, las actividades que se realizan, los roles y responsabilidades, dejando en claro que no es la solución “para enderezar” un proceso de desarrollo desordenado y caótico. Como contracara, un proceso de desarrollo ordenado y disciplinado permitirá realizar una mejor evaluación del estado de los productos, permitiendo a los ingenieros de pruebas poner el foco de atención sobre sus debilidades.
Algunas Conclusiones
Ya no buscamos la famosa bala de plata, pero sólo porque ninguno de nosotros ha conocido a alguien que alguna vez la haya visto, y sin ánimo de ser aguafiestas, tampoco deberíamos reemplazar la ilusión de la bala de plata por fórmulas mágicas, porque tampoco nadie las ha visto.
Es tiempo de crecer y cambiar, de diseñar planes de acción realistas, que nos permitan mejorar nuestros procesos de control de calidad. Es tiempo de capacitarnos para enfrentar un mercado que día a día, pide lo mejor.
Y por último y a modo de cierre, quisiera rescatar las palabras de John Ruskin: “La calidad nunca es un accidente; siempre es el resultado del esfuerzo de la inteligencia”.
Acerca del autor
Alfonsina Morgavi es socia fundadora de QASoft en Argentina, donde se desempeña como consultora en Aseguramiento de Calidad de Software. Dedicada desde el año 1989 exclusivamente a esta actividad. Uno de sus principales intereses es el entrenamiento de ingenieros de pruebas y el coaching en proyectos de la especialidad. Alfonsina está certificada por el Quality Assurance Institute como Ingeniera en Control de Calidad de Software, así también como Consultora en Implementación ISO 9001:2000 por la Fundación Cane. Es miembro activo del subcomité de normas de calidad de software del Instituto Argentino de Racionalización de Materiales (Miembro ISO, COPANT y AMN).
- Log in to post comments