archivo

Archivo de la etiqueta: orientación al proceso

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.

Un aspecto a tener en cuenta en el QC es que parte de su ahorro de costes es provocado por un incremento de los costes de desarrollo del producto porque el nivel de detalle de la documentación entregada (sobre todo la relativa a las pruebas) tiene que ser superior al necesario para suplir el desconocimiento del negocio y del producto por parte de los técnicos QC.

Este aspecto no se tiene en cuenta generalmente a la hora de implantar este tipo de servicios y es muy importante porque 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).

¿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.

Como veremos en el artículo de mañana que está centrado en lo que sería el QC (pero que es perfectamente extensible a un QA+QC reactivo), 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.

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 calado, como por ejemplo, que alguno de los casos del plan de pruebas no funcione adecuadamente (se entiende que el plan de pruebas responde a la verificación de funcionalidades que implementadas adecuadamente y que, en conjunción con las demás, satisfarían las expectativas del usuario) o bien defectos de menor gravedad (alguna lista de valores no ordenada, algún enlace roto, algún mensaje de error demasiado críptico, etc…).

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.

Una cosa es que el desarrollador sepa qué es lo que tiene que hacer el sistema y otra que consiga plasmarlo en un documento, incluso con la mejor de las intenciones y dedicando el tiempo necesario.

Ante esta situación, lo más interesante resulta combinar ambos enfoques: QA y QC, porque cada uno, bien aplicado tienen repercusión en la calidad y valor del producto final.

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.

No debemos olvidar que el fin último para el que estamos trabajando no es otro que el de conseguir productos que satisfagan las expectativas de los usuarios y que sean mantenibles, 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.

Por tanto, sobre un proceso sostenible (adecuado a la realidad), la realización de una serie de actividades que permitan que el desarrollo sea más efectivo, que la respuesta a los defectos sea lo más rápida posible y como consecuencia de todo lo anterior conseguir un mejor aprovechamiento del esfuerzo (más productividad).

Si el QA tiene en cuenta esto sí que resulta realmente positivo para el proyecto y además es mucho más efectivo porque las tareas se realizan desde un conocimiento de la realidad del proyecto, de su contexto y del negocio.

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

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.

No digo que no haya que trabajar sobre algún aspecto del proceso, ya que estamos trabajando en una organización que requerirá unos ciertos mínimos para armonizar los desarrollos y estar informada sobre el estado de ejecución y presupuestario del proyecto.

La carga de trabajo y las contingencias de los proyectos en los que estamos trabajando provocan que los desarrolladores tengamos una visión muy acotada. Es lo que tiene estar en las trincheras, la preocupación es el presente y el corto plazo (a veces un poco más allá) de los proyectos en los que estamos trabajando.

Muchas veces se nos critica: “improvisáis, no tenéis un plan” (y muchas veces con razón), sin embargo, si hacemos las cosas bien, salvo excepciones (que ocurran hechos inesperados) no se improvisa, se trabaja con lo que hay y desde donde estamos, teniendo en cuenta la situación o contexto actual, siempre con intención.

Esta visión hace que en muchos casos no entendamos algunos procesos o los consideremos excesivos. A veces estaremos en lo cierto, otras veces equivocados.

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.

Estoy de acuerdo en que dependerá de cómo se enfoque, pero considero peligroso que el proceso esté en primer plano porque se puede terminar pervirtiendo el modelo de manera que lo principal sea definir un procedimiento de trabajo, hacer algunos ajustes adaptados al proyecto y hacer que se cumplan.

Esto puede dar lugar a la creación de un cultura de cumplidores que traten de utilizar el proceso no como herramienta sino como escudo en el caso de que los proyectos no salgan bien. Al ser considerado un salvoconducto para escurrir responsabilidades, los cumplidores se convierten, más allá incluso de los QA, en fanáticos del procedimiento establecido. Y no porque crean en él, insisto, sino como actitud defensiva.

En el momento en que el procedimiento, el proceso o la metodología pasa de ser una herramienta (que debería estar bien calibrada a la realidad de la organización, de sus proyectos y del proyecto en el que se está trabajando) a un fin se ha elegido el camino equivocado porque independientemente de que sea más o menos efectivo, el modelo en lugar de ser proactivo se termina convirtiendo en reactivo. Y no solo es cuestión de que en lugar de buscar soluciones se verifiquen listas de comprobación, sino de entender algo que es conocido por la mayoría de lo que nos dedicamos a esto: el proceso no asegura nada.

Pese a todo, la forma más común en la que nos vamos a encontrar el QA será orientado al procedimiento y 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. De hecho esa será la definición de QA que encontraréis en la mayor parte de sitios.

Personalmente (y solo es una valoración personal), me niego a llamar a eso aseguramiento de la calidad.

El término aseguramiento de la calidad se ha extendido a tareas de prevención en el momento en que se está desarrollando (detección de defectos, adecuado seguimiento de un proceso y/o una metodología) y a las tareas que se realizan una vez que se entrega una determinada versión de un producto o de un artefacto (que puede ser un determinado documento exigido por el proceso de desarrollo).

Y es que aseguramiento de la calidad (QA) vende más que control de la calidad (QC), porque asegurar resulta más rotundo que controlar.

El aseguramiento de la calidad está orientado a la prevención, pretende ser, por tanto, proactivo, lo que requiere que sea una parte más dentro del proyecto y suele centrarse en aspectos relacionados con el proceso de desarrollo y testing.

El hecho de que se considere que el QA está orientado al proceso, en mi opinión, ha restado efectividad a su aplicación porque el producto nunca debe quedar en segundo plano y en el momento en que se transmite el mensaje (aún con la mejor de las intenciones) de que la calidad está en el proceso empieza a interpretarse por los responsables del QA de que lo valioso es el procedimiento y que si se sigue probablemente el proyecto tenga éxito.

Curiosamente si se falla, será culpa de las personas por no haber seguido adecuadamente el proceso. Este doble rasero: las personas son secundarias porque quien asegura la calidad es el proceso, pero si todo falla los culpables son las personas, no lleva a nada bueno porque crea una espiral que irá separando a los equipos de desarrollos de los encargados del QA y que por regla general, si no se corta, agudizará el problema porque la respuesta del QA será hacer todavía más rígidos los procesos, hacer más severos los controles y si se siguen sin conseguir objetivos seguirá siendo culpa de las personas y así hasta el infinito.