Contacto +34 93 737 62 70
           
Contacto +34 93 737 62 70
P6_QA

En este artículo se discutirá cómo DevOps puede revolucionar el modelo de Quality Assurance (QA) dentro de organizaciones que externalizan el desarrollo de software. Se introduce el modelo habitual de grupo interno de QA, el impacto en éste de la agilidad y del movimiento DevOps y finalmente se propondrán dos modelos alternativos para redefinir dicho modelo según el enfoque DevOps.

 

1. Metodología y QA tradicionales

En las organizaciones tradicionales, las funciones de la oficina de proyectos (PMO) y del grupo de QA incluyen la definición con detalle de la metodología y estándares técnicos a nivel de procesos, productos y herramientas,  para “garantizar” la consistencia y calidad de los proyectos, y controlar la adherencia a dicha metodología y estándares durante su ejecución. En el caso proveedores de desarrollos externos, el énfasis suele ponerse en establecer el “mapa de productos” que deben entregar los proveedores y los controles de verificación que realizarán sobre éstos el grupo  interno de QA. La efectividad conseguida suele depender enormemente de la calidad en la definición de la metodología, y de los recursos y apoyo con los que cuente el grupo de QA.

Este enfoque tradicional del “control de proveedores” contraviene todos los valores que propone el manifiesto ágil:

  1. Personas e interacciones sobre procesos y herramientas.
  2. Software que funciona sobre documentación extensiva.
  3. Colaboración con el cliente sobre negociación de contratos.
  4. Respuesta a los cambios sobre seguir un plan.

 

2. DevOps

El movimiento DevOps defiende el trabajo integrado y ágil de todos los grupos que participan en el desarrollo y explotación del software (p.e. Desarrollo, QA y Operaciones IT), desde tomar los requisitos a controlar que funciona correctamente en producción.  Para ello se deben alinear la cultura, la organización y las herramientas de dichos grupos. Quizás la mejor manera de entenderlo es explicar qué puede conseguir un buen entorno DevOps: ser capaz sistemáticamente de recibir una petición de cambio o de evolutivo y tenerla disponible en producción, sin errores, y tardando unos pocos días o incluso unas pocas horas.

Ciclo de vida DevOps

Fuente: www.collab.net

 

3. ¿Cómo impacta DevOps a la función de QA tradicional?

Una vez introducido el modelo tradicional de relación entre el grupo de QA y los proveedores, así como la filosofía y objetivos de DevOps, se pasará a explicar por qué la agilidad recomienda repensar dicho modelo y como implica hacerlo según en enfoque de DevOps. Para ello se utilizarán los cuatro valores del manifiesto ágil:

 

Personas e interacciones sobre procesos y herramientas

En un sistema con procesos definidos, la comunicación entre actividades y grupos de trabajo se realiza mediante la documentación sistemática de los productos que un grupo “entrega” al siguiente en el proceso. La colaboración es típicamente “transaccional”, puntual en el tiempo y basada en la entrega del producto “pactado” y de su documentación de soporte. En un extremo, grupo de QA y el equipo de desarrolladores no tienen por qué conocerse personalmente ni haber interactuado antes o después de este intercambio.

Un entorno DevOps no se construye sobre el concepto de “entrega”. Aunque no se eliminan los procesos, estándares o automatización de actividades, los roles como el cliente, el equipo de desarrollo y los grupos de QA y operaciones colaboran de manera fluida desde la misma planificación del proyecto. El grupo de QA debería interactuar con los desarrolladores durante la fase de desarrollo combinando la formación, el asesoramiento, la escucha y el control. Para que dicha interacción sea efectiva debe estar contemplada en los contratos y también debe maximizarse la facilidad de comunicación de todos los equipos, ubicados conjuntamente si es posible.

Eli Lopian explica como muchos grupos de QA se están integrando en los equipos de desarrollo y el impacto que tiene la extensión del test unitario en la necesidad de un grupo externo de QA en su artículo The Day the QA Department Died.

En un modelo de externalización de muchos proveedores, Xavier Escudero explica que es vital que se incluya una figura de responsable de calidad en cada proveedor, que verifique las tareas de calidad de su equipo (procesos y calidad del producto/servicio), y se coordine con el equipo de QA del cliente, participando intensivamente con los diferentes implicados durante el ciclo de vida, especialmente en proyectos de alto riesgo.

 

Software que funciona sobre documentación extensiva

Uno de los objetivos principales de los grupos de QA tradicionales es definir con detalle la documentación que los proveedores deben entregar (p.e. funcional, de diseño, de datos, de pruebas o de operación) y verificar en las entregas su adherencia a los estándares establecidos. Es frecuente que el grupo de QA no tenga tiempo disponible para ir más allá de una verificación básica de la documentación entregada y de las pruebas realizadas, sin poder analizar suficientemente la cobertura y calidad de las pruebas técnicas o de aceptación, o validar que el software está listo para ir a producción y satisfará al usuario.

En un entorno DevOps, el grupo de QA ágil no puede limitarse a esperar que los proveedores pongan sus paquetes de entrega en un repositorio y se ejecuten automáticamente un análisis de código y unas pruebas de aceptación. Esta definición y automatización pueden hacer las tareas “rutinarias” de entrega más eficaces y eficientes, pero el grupo de QA y los equipos de desarrollo deben colaborar antes, durante y después de las entregas para que los proveedores entiendan profundamente el objetivo de estas comprobaciones (p.e. utilizándolas sistemáticamente durante el desarrollo mediante la Integración Continua) y el grupo de QA pueda evolucionarlas a partir de la experiencia empírica que le proporcionan los proveedores y el grupo de operaciones. Dicha colaboración requiere una dedicación explícita (y pagada) de ambas partes, y una cultura de colaboración, comunicación y confianza que no se vea perjudicada por una presión excesiva de las cláusulas contractuales.

Xavier Escudero expone como su departamento de QA está colaborando de manera intensiva con los proveedores en proyectos de alto riesgo, a lo largo de su planificación y ejecución, para dar soporte a la implantación de las medidas de calidad establecidas en el modelo, ayudar a revisar los diferentes entregables y mitigar los riesgos de una mala calidad del producto. Todo ello se realiza de forma constructiva, participando activamente con el equipo de desarrollo y operaciones, incluso haciendo diagnósticos conjuntos en caso de incidencias de calidad (disponibilidad, rendimiento, etc.).

 

Colaboración con el cliente sobre negociación de contratos

Un proyecto tradicional suele basarse en el ciclo de vida de cascada, en una especificación (o “congelación”) de requisitos del sistema a construir y en un calendario de trabajo comprometido sobre el que una desviación suele ser considerada como un fracaso. La separación de los roles de cliente, desarrollo, QA y producción, materializada a través de las “entregas formales” entre éstos, suele conducir a una comunicación pobre entre las partes y en los peores casos a forzar la colaboración en base a las obligaciones suscritas en los contratos. Este modelo de la colaboración deja poco margen de maniobra al grupo de QA para realizar actividades de verificación y validación mientras esperan a que los equipos externos de desarrollo realicen las entregas.

Sin embargo, modelos de buenas prácticas de “compradores de proyectos” como CMMI-ACQ defienden la interacción temprana con los desarrolladores a nivel funcional y técnico con áreas de proceso como Acquisition Technical Management y Acquisition Validation.

En un entorno DevOps, el grupo de QA puede jugar un papel determinante en el fomento de la interacción con el cliente mediante la introducción de prácticas ágiles como la elaboración progresiva de los requisitos, el uso de maquetas, las demostraciones con software real tras periodos cortos y la formalización de pruebas de aceptación. Aunque estas prácticas pueden causar rechazo en los clientes por la aparente pérdida de seguridad al no disponer de un contrato con la línea base de requisitos y un calendario detallado de actividades, su efectos reales suelen ser la reducción de los riesgos de insatisfacción de los clientes, la mejora de la calidad de los productos entregados y la detección de las desviaciones antes de las últimas fases del calendario.

 

Respuesta a los cambios sobre seguir un plan

En la gestión de proyectos tradicional, el modelo del Triángulo de acero representa las limitaciones que debe tener en cuenta la dirección del proyecto a la hora de realizar su  planificación y seguimiento. Los vértices del triángulo representan las dimensiones de alcance, coste y calendario, mientras que su interior representa la calidad. El plan de proyecto fija tanto estas dimensiones como los objetivos a cumplir y es el gestor del proyecto quien da seguimiento al trabajo del equipo externo para intentar alcanzar dichos objetivos. Es muy frecuente que cuando el esfuerzo real del proyecto es mayor del que se pactó entre el cliente y el proveedor, el primero ponga presión al segundo para mantener las restricciones pactadas en la planificación. Las consecuencias suelen ser que las desviaciones no se admiten hasta una fase avanzada del proyecto y que la dimensión que sufre una merma mayor es la calidad, por una combinación de factores como que:

  1. QA no puede validar la calidad real del producto hasta que no recibe las entregas.
  2. No se deja tiempo a los desarrolladores para realizar correctamente el trabajo.
  3. El equipo de proyecto reacciona al retraso observado incorporando nuevos miembros, pero la falta de soporte a los nuevos miembros facilita los errores.
  4. La introducción de deuda técnica alimenta el círculo vicioso de la mala calidad. Wolf y Müller explican muy bien este último problema en su artículo No More Technical Debt – Invest in Quality.

En un entorno DevOps, se sigue una filosofía ágil que rompe las restricciones del Triángulo de acero. Siguiendo algunos principios del Manifiesto ágil vemos sus efectos en dichas restricciones:

  1. Se mantiene una comunicación frecuente y se buscan los cambios necesarios de manera proactiva durante el desarrollo, no después de la entrega.
  2. Se realizan entregas o demostraciones parciales cada pocas semanas, validadas por el cliente (y por QA).
  3. La cantidad de software entregado es la principal métrica de avance, no los cronogramas de seguimiento que actualiza el equipo del proveedor.
  4. El equipo de desarrollo (conjuntamente con QA) reflexiona a intervalos regulares sobre cómo ser más efectivo y ajusta consecuentemente su manera de trabajar.

 

4. Dos posibles implementaciones de DevOps y QA

Como se decía en la primera sección de este artículo, las funciones habituales de un grupo interno de QA es definir los procesos y estándares técnicos que deben seguir los proveedores, y verificar su cumplimiento en los proyectos. En un entorno DevOps la función de QA se centra en el testing, siguiendo el enfoque ágil de primar la validación funcional y técnica de los productos respecto  la verificación de la adherencia a los procesos. El libro Agile Testing: a practical guide for testers de Crispin y Gregory contiene buenos consejos sobre cómo implementar los objetivos de QA mediante el testing ágil.

El rol de QA según DevOps se expande para cubrir también los requisitos de operación del sistema, por lo que no debe incluir sólo testers sino también personas de sistemas. Así pues se establecen dos modelos básicos de QA en un entorno DevOps, que deben estar plenamente contemplados en la organización del departamento IT, en la cultura del cliente y en los contratos con los proveedores:

 

El grupo de QA/DevOps “envía” miembros a los equipos.

Los testers y los ingenieros de sistemas participan en las tareas diarias de los equipos como el resto de sus miembros, tanto en la planificación de los Sprints como en la ejecución de las tareas. Siguiendo el concepto de “generalista–especialista”, realizan principalmente las actividades para asegurar que las pruebas se realizan de manera correcta y continua, y que el diseño y la implementación tienen en cuenta las necesidades de operación, pero también pueden realizar también otras tareas del Sprint si es necesario.

El grado de participación de los miembros de QA/DevOps puede ser constante o decrecer paulatinamente una vez que se tiene confianza en que los equipos externos realizan por sí mismos las funciones de DevOps de manera consistente.

 

El grupo de QA/DevOps monitoriza a los equipos “desde fuera”.

Los testers y los ingenieros de sistemas constituyen un “equipo DevOps” que se encarga de verificar frecuentemente que los equipos externos están realizando el testing con la cobertura y calidad necesarias, así como que los incrementos del sistema que van liberando cumplen con los requisitos de producción. Las herramientas de integración continua, de análisis del código y del testing, así como de monitorización de entornos, facilitan enormemente a los equipos DevOps la inspección diaria o cada pocas semanas del trabajo de los equipos externos, y el soporte ad-hoc para corregir posibles deficiencias.

Esta es la opción implantada recientemente por el QA del CTTI. Gracias a una verificación continua desde el inicio las diferentes partes conocen en todo momento cual es la calidad del sistema y qué mejoras pueden aplicarse para que sea lo más libre de errores posible.

 

5. Conclusión

En este artículo se han introducido la función tradicional de QA y la filosofía del movimiento DevOps, se ha revisado como los valores de la agilidad requieren una revisión integral de los objetivos del grupo de QA así como de su interacción con los grupos de desarrollo, y finalmente se han propuesto dos modelos para implementar de manera efectiva la combinación de la función QA y el enfoque DevOps.

Es fácil observar que la función de QA no puede repensarse en clave ágil sin incluir en el cambio de modelo aspectos clave en la compra de proyectos como la política de contratación, el rol de la oficina de proyectos y la participación de los usuarios. El desafío es importante, pero también lo son sus beneficios potenciales.

 

¿Podemos ofrecerte más información?

Newsletter mensual

Cada mes enviamos una newsletter a más de 1.000 personas con contenido interesante que hemos encontrado en Internet, artículos nuestros y nuestras novedades. Queremos ofrecer contenido de calidad y no saturarte con muchos correos.

Formulario de contacto

Si crees que podemos ayudarte con alguna duda o necesidad de soporte, no dudes en contactar con nosotros. Estaremos encantados de ayudar.

Ir arriba

Newsletter mensual

Un boletín mensual. Respetamos tu privacidad.