QA en modo ITV

Aún a día de hoy en muchas empresas el grupo o departamento de QA, en caso de existir, sigue siendo un componente externo a los proyectos. Personas a las que llegado el momento de la fase de pruebas se les pasa un entregable para que lo testeen y validen.

En casos así, se suele considerar habitual que el departamento de QA juegue un papel de “certificador de calidad” o “gatekeeper”. El resultado de la fase de pruebas debe ser un KO u OK para producción o posteriores fases del proyecto. El equivalente a un sello otorgado por una entidad externa certificando que se es APTO

Desde mi punto de vista, aunque este enfoque pueda ser necesario en ciertos tipos de proyectos donde el grado de exigencia de calidad sea muy alto ya sea por criticidad del sistema en sí o por cumplimiento de leyes, no representa los proyectos que desarrollan en el día a día la inmensa mayoría de empresas. En general, el papel del equipo de QA de ser meramente auditor únicamente involucrado en la fase final del proyecto no aporta demasiado valor al mismo.

Es por ello, que creo que existen similitudes entre esta forma de trabajar en los proyectos y en cómo los conductores afrontan la ITV.

Conductor modelo

Disfruta conduciendo, le gusta sentirse que todo esté en orden y sentirse seguro. Siempre tiene el coche a punto, cuida hasta el último detalle, revisa el aceite y la presión de las ruedas en cada viaje, lo limpia a mano todas semanas y lo guarda en garaje. Este conductor va a la ITV confiado de que todo está en orden y que simplemente tiene que pasar ese trámite legal para poder seguir circulando.

Conductor normal

El coche es un medio de transporte necesario en su día a día. Tiene más preocupaciones y cuida de su coche en la medida de los posible. Pasa las revisiones estipuladas por la marca y lo lava cuando considera que está muy sucio. Este conductor si le sobra tiempo y algo de dinero es posible que se pase por un taller antes de la ITV para comprobar que todo está orden.

Afronta la ITV con cierta incertidumbre. Cree que todo está en orden y está casi seguro de que la pasará pero si tiene alguna falta leve intentará solventarla lo antes posible.

Conductor dejado

Conduce porque no tiene otro remedio, tiene un coche viejo que apenas cuida y sólo quiere invertir lo imprescindible pueda seguir moviéndose y sea capaz de llevarle de un punto a otro. No se preocupa de los niveles de aceite ni las emisiones.

Va a la ITV sabiendo que tendrá defectos, resolverá en el taller que menos le cobre aquellas faltas graves que han impedido que le den de paso la revisión y repetirá este proceso hasta obtener el certificado que le permita seguir circulando.

Creo que en los proyectos software se dan situaciones muy similares. Siendo las dos primeras las más deseables, no es raro encontrarse en muchas ocasiones con la tercera. Obviamente no siempre es culpa de los desarrolladores (conductores) trabajar de ese modo. Distinguiría varias situaciones

• Me duele más a mi que a ti
• Fechas de entrega ajustadas, reducción de costes, cumplimiento de contratos, imprevistos, mala plantificación son algunas de las circunstancias que pueden hacer que se produzca una entrega forzada y prematura a QA sabiendo que la calidad será baja
• Necesito ayuda
• Parecido al punto anterior. El equipo de desarrollo no cuenta con medios o personal cualificado necesarios para la fase de pruebas y lo pasa al equipo de QA sabiendo que encontrará errores. Quedan a la espera de recibirlos para solventarlos mientras avanzan con nuevas funcionalidades.
• Es tu trabajo
• "Eres QA no?, tu trabajo es encontrar errores, las pruebas en tu responsabilidad."  Los equipos que tienen esta mentalidad (que los hay en abundancia) van a mínimos de calidad. Son conscientes de que su producto es mejorable y muy posiblemente tenga errores graves, pero si el equipo de QA no los detecta y da la versión de paso… trabajo finiquitado. Por desgracia, esta falta de profesionalidad en muchos casos genera sobrecostes y retarda enormemente las fechas de entrega de los proyectos.

Un departamento de QA no debe ser mero auditor de calidad ni debe tomar la decisión de que una versión está lista para producción o no.

¿Tú que opinas?