Hay cosas que nunca cambiarán.

Si alguien verificase constantemente tu trabajo, devolviéndote lo que «no has hecho correctamente» para que lo corrijas, seguro que estarías «a la gresca» con él. Constantemente mantendríamos una actitud defensiva, cuando no algo más. ¿Por qué entre los equipos de Desarrollo y los de Pruebas va a ser diferente?.

A estas alturas, sobra decir que las Pruebas de Software deben ser una fase obligatoria dentro de todos los modelos de Ciclo de Vida del software, y que el Plan de Pruebas debe ser un elemento esencial en la entrega del Desarrollo. Pero normalmente esta actividad se deja para el final, es decir, cuando ya hemos producido un software de mala calidad que hay que corregir. Los problemas son de sobra conocidos: en esta fase, o no hay dinero, o no hay tiempo, o el coste de corregir estos errores se multiplica exponencialmente. Y empiezan los clásicos problemas de entendimiento entre los distintos equipos: ¡pues en nuestro entorno funcionaba perfectamente!, ¡no habéis entendido cómo tiene que funcionar!, ¡esto no es una incidencia!...

Hoy en día, queda demostrado que el 80% de los errores del software provienen de las primeras fases del ciclo de vida (definición, diseño, modelado de entornos, criterios de aceptación…). Y por esta razón (una de muchas) surge el concepto de QA, Aseguramiento de la Calidad del Software. Mientras que las pruebas se realizan en una de las fases del ciclo de vida del software, normalmente al final, las actividades de Aseguramiento de la Calidad del software se ejecutan en todas las fases (que incluye la verificación y validación de la fase de Pruebas). Es decir, ambas actividades (Desarrollo y Pruebas) permiten verificar y afirmar la calidad del producto final.

Para conseguir esta acción coordinada, es necesario definir estándares y establecer procedimientos que permitan medir primero, y comparar después, lo alcanzado durante cada una de las fases, cumpliendo así con este aseguramiento.  Nos obligamos a que los procesos de calidad del software no sean algo aislado del proyecto, sino parte del mismo, gracias a un proceso metodológico aplicado desde las fases iniciales.

En resumen, un proyecto de desarrollo software sin actividades de QA en cada una de sus fases, desde el inicio hasta el final, disparará considerablemente su coste, exigirá un esfuerzo mayor en la fase de Pruebas. El 76% de los proyectos que fracasan es debido a una baja calidad de los requisitos iniciales del software y a una falta de procedimientos de QA.

Esto no elimina la necesidad de que exista un área de Pruebas (o testing). Simplemente la integra con el área de Desarrollo en un proceso cuya única finalidad es la  S A T I S F A C C I Ó N   D E L   C L I E N T E.

En Panel somos defensores de la necesidad de independencia del equipo de Pruebas, ajeno al equipo de Desarrollo, pero está claro que ambos tienen que relacionarse de una forma «amigable» desde el principio. La actividad de QA no puede formar parte exclusiva de la Unidad de Desarrollo, y tampoco puede formar parte de la Unidad de Producción. Debe ser una unidad independiente con la habilidad de no generar conflictos, para que sean vistos como facilitadores del trabajo de Desarrollo desde el comienzo del proyecto, como aliados, de tal forma que se garanticen equilibrios de fuerzas como este:

Y por supuesto, esta concepción de la Calidad del software es imprescindible para la adopción de nuevas metodologías de producción como SCRUM o Lean Management.