El control de la calidad (QC) es reactivo. Se ha llegado hasta el final y se realiza una entrega del producto y otros artefactos documentales asociados. En este punto, a lo más que se puede llegar es a la detección de defectos antes de su puesta en producción.
Estos defectos pueden ser de mayor o menor gravedad, bloqueantes, mayores o menores.
No es malo disponer de esta última línea de defensa, antes al contrario, puede ser muy interesante, pero su efectividad está muy condicionada por el trabajo del equipo de desarrollo, es decir, si se considera que una aplicación es válida porque cumple el plan de pruebas entregado por el desarrollador, estamos dejando toda la responsabilidad en ese plan de pruebas y todos sabemos que, salvo honrosas excepciones, los desarrolladores no somos expertos en eso.
Este último párrafo tiene que ver con que si no hay una línea intermedia representada por el Analista Funcional, puede caber la duda de que el desarrollador haya podido plasmar en un documento, lo que tiene que hacer verdaderamente el sistema.
Indudablemente, las buenas prácticas hacen que al combinar QA y QC tenga incidencia en la calidad y valor del producto final.
Por supuesto y como explica el autor: «Esto es así, siempre y cuando el QA, como he ido insistiendo en artículos anteriores, no se convierta en un simple verificador del cumplimiento de determinados procesos de desarrollo.»
Fuente: Jummp
