Diferencias entre QA y QC – Parte II

Puntos para seguir discutiendo:

• Todo depende del enfoque que se defina
• Hay que definir un procedimiento de trabajo, ajustarlo y conducir su cumplimiento
• Evitar actitudes defensivas que usan al proceso como escudo en el caso de que los proyectos no salgan bien.
• Hay que luchar para que el procedimiento, proceso o metodología sean herramientas
• Hay que luchar para que el modelo impuesto sea proactivo y nó, reactivo
• Tener presente en todo momento que así como “No Hay Cero Bugs”, “El Proceso No Asegura Nada”

En síntesis, la forma más común en la que nos vamos a encontrar el QA será orientado al procedimiento y a las metodologías, considerando a los proyectos como algo genérico o en el mejor de los casos, definiendo distintos itinerarios en función de una categorización que se haga de los mismos.

No obstante muchos se niegan a pensar en que ésto es el alcance de QA (Aseguramiento de la Calidad)

Fuente de Inspiración: jummp

Lo realmente importante es que exista una comunicación fluida entre todos los implicados con el objeto de buscar soluciones a los problemas y de esta forma conseguir de manera efectiva una mejora continua.

No se trata, por tanto, de eliminar los procesos, sino de que sean racionales y ajustados a lo que la organización necesita y puede soportar y nunca de espalda a la realidad de los proyectos de desarrollo de software que se realizan y el presupuesto con el que se puede contar en los mismos.

Fuente: http://wp.me/ppBOQ-3Lw

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

¿Por qué es más frecuente encontrarnos con QC que con QA (pese a que a ese QC se le llame de manera equivocada QA)? Por motivos económicos, ya que el QA requiere una mayor implicación en el proyecto por parte de los técnicos que realizan este tipo de tareas (salvo que se haya elegido el camino de validar procesos en cuyo caso ese trabajo se simplifica), por lo que la definición de un equipo QA+QC requiere una mayor inversión.

Sin embargo, lo que nos vamos a encontrar con más frecuencia es la combinación de QA y QC pero con una orientación reactiva: entrega y validación.

Se llega a esa circunstancia principalmente por dos motivos: es lo más cómodo, ya que permite definir un modelo con un interfaz definido, desapegado de la realidad de los proyectos que se están ejecutando (al no formar parte de ellos) y por otro lado, por la errónea convicción de que son los procesos, procedimientos y metodologías los que mandan y los que hacen buenos o no el resultado final del proyecto.

¿Pero no es lo ideal que los equipos de calidad y desarrollo sean distintos? Mi propuesta no es incompatible con eso, ya que lo que estoy indicando es que un grupo de personas dentro o no del equipo de calidad colaboren con el equipo de desarrollo (incluso siendo parte de él si las circunstancias lo permiten) para que tanto los trabajos que se realicen en el mismo como los propios artefactos que se vayan a entregar al QC sean lo más efectivos posibles.

URL: jummp

En el caso de un equipo QC, su funcionamiento se puede orientar perfectamente a un procedimiento: recibo una entrega en un formato determinado, hago las tareas de verificación y devuelvo unos resultados. Se puede ser ajeno al conocimiento del producto y del proyecto (se trabaja sobre la documentación escrita por el equipo de desarrollo). Por eso muchas organizaciones que se dedican a prestar este servicios, tienden a crear factorías de testing, ya que el modelo encaja perfectamente, y de esta forma pueden ofrecer precios todavía más competitivos porque “da igual” que la persona que vaya a trabajar sobre la entrega conozca el producto.

Después la pericia de los técnicos QC les puede hacer llegar más lejos, ya que pueden hacer testing exploratorio y aplicar otro tipo de técnicas que les permitan que la detección de defectos sea más efectiva.

Para valorar la efectividad de la implantación de un QC es necesario evaluar sus resultados frente a los costes directos (los del propio equipo del QC) como los indirectos (los que ocasiona en los proyectos).

URL: http://wp.me/ppBOQ-3LA

Hay algo que el autor expresa y que estoy totalmente de acuerdo con él:

“…por lo que no puedo entender el aseguramiento de la calidad si no se colabora en la selección y aplicación de los casos de prueba que permitan verificar el cumplimiento de las expectativas, si no se tratan de establecer medidas que permitan mantener la deuda técnica bajo control y no se mejoran las técnicas de testing que se están utilizando con el objeto de automatizarlas en lo posible y detectar defectos cuanto antes.”

En otra parte, lanza el siguiente comentario:

“…Si el QA solo mira el proceso, se está perdiendo lo más importante.”

Y al final de su artículo, cierra con el siguiente:

“…Tanto el respeto al proceso como la aplicación de determinadas prácticas son elementos instrumentales o de apoyo, no lo olvidemos. El desarrollo de software es mucho más complicado que todo eso porque no debemos olvidar el propósito del proyecto que no es otro que satisfacer un conjunto de expectativas y necesidades y si eso no se consigue, habremos fracasado, en mayor o menor medida, pero fracasado.”

Me pongo a pensar que no todas las empresas tienen dos áreas como las que se han discutido aquí, es decir, QA y QC; y sí me cabe pensar que hay sólo una enmarcada dentro del término “Testing” y que refiere a las anteriores, y que hasta incluso para el área comercial (porque sabemos que es más ‘vendible’) la llaman ‘QA’.

De ahí a reflexionar acerca de la competencia de sus miembros y de las políticas que se adoptan, ya que muy probablemente no tienen los objetivos que el autor de estos artículos ha enunciado.

Fuente: Jummp

http://testingbaires.com/diferencias-entre-qa-y-qc-parte-ii 
http://testingbaires.com/diferencias-entre-qa-y-qc-parte-iii
http://testingbaires.com/diferencias-entre-qa-y-qc-parte-iv
http://testingbaires.com/diferencias-entre-qa-y-qc-parte-v
http://testingbaires.com/diferencias-entre-qa-y-qc-parte-vi
http://testingbaires.com/diferencias-entre-qa-y-qc-parte-vii