Qué es QA

0

Antes de tener en mi equipo a gente especializada en QA (Quality Assurance, o garantía de calidad), tenía una visión equivocada de lo que hacía esta gente. El último año, entre verlos en acción y documentarme en el tema con todo lo que caía en mi mano, comienzo a tenerlo más claro. O eso creo. ¿Opinarás lo mismo tú que yo? Vamos a verlo…

Mi visión antigua de QA

Cuando pensaba antes en QA pensaba en testeo. Y de forma particular en testeo automatizado. Pensaba que con un buen plan de pruebas y que éste esté automatizado, ya tenías QA completo. Así, pensaba en QA como en el equipo que debía programar estos testeos. Mi visión, muy retro por cierto, era que una vez los programadores acababan el desarrollo, entraba el equipo de QA y automatizaba todo el testeo, para evitar que se volviese a romper.

Resumiendo: QA es un equipo que desarrolla tests automatizados para asegurar que el software no tiene fallos y que en futuros cambios no se romperá lo que ya se ha hecho.

¡Qué equivocado estaba!

QA es un objetivo

Cuando pude ver de cerca el trabajo de un auténtico experto en QA empecé a darme cuenta de lo que realmente significaba. Ese tío se metía en todo. Lo mismo revisaba código de otros, que programaba un test automatizado, que coordinaba pruebas unitarias, que montaba lo que fuese con tal de mejorar la calidad. Estaba interesado en los procesos de subida a producción, en el estilo de programación, en los entornos que tenía la gente al desarrollar, en el proceso que seguían, … le interesaba todo. Y entonces es cuando me di cuenta. QA en sí no es nada. QA es un objetivo: conseguir asegurar la calidad del código entregado. Y de alguna manera es uno de los objetivos que debería tener cualquier proyecto de desarrollo. Y la manera de conseguirlo puede ser cualquiera. Hay muchas cosas que se pueden hacer para conseguir asegurar esa calidad.

Por ejemplo, en la ISO 12.207 (ya casi me había olvidado de ella tras mi época de auditor de la 15.504) sobre procesos del ciclo de vida del software, y que viene del IEEE, se define QA como un proceso:

The Quality Assurance Process is a process for providing adequate assurance that the software products and processes in the project life cycle conform to their specified requirements and adhere to their established plans. To be unbiased, quality assurance needs to have organizational freedom and authority from persons directly responsible for developing the software product or executing the process in the project. Quality assurance may be internal or external depending on whether evidence of product or process quality is demonstrated to the management of the supplier or the acquirer. Quality assurance may make use of the results of other supporting processes, such as Verification, Validation, Joint Reviews, Audits, and Problem Resolution.

Resumiendo: QA es el proceso que tiene como objetivo asegurar la calidad.

Quién es el responsable de QA

El responsable de QA es la persona que debe velar por conseguir el objetivo de QA. Debe coordinar a todas las personas relacionadas con desarrollo en lo que concierne a la calidad. Es decir, si QA es una línea de la matriz RACI, el responsable es la A (accountable), mientras que el equipo es la R.

El responsable de QA debe ser una persona con mente abierta, que se involucre en todas las partes del proceso de desarrollo y mantenimiento, vigilando desde un principio las posibles opciones que tiene para asegurar esa calidad. Tiene que tener un conocimiento técnico de las herramientas que puede utilizar, pero sus habilidades deben ser principalmente de gestor. Por lo tanto puede que no nos sirva simplemente poner de responsable de QA a un programador de tests, ya que podría aplicarse el principio de Peter. Puede tener equipo dedicado a QA o no. Yo personalmente creo que sí, pero es posible que si todos colaboran, no necesite un equipo dedicado.

Qué hace o coordina este responsable de QA. Por supuesto una primera tarea es hacer testing, o coordinar que el equipo haga el testing. Pero no sólo eso. Como he dicho hace muchas cosas más que un simple control de calidad. Aquí algunos ejemplos:

  • Define estándares. El código debe cumplir determinadas normas que ayuden a conseguir mayor calidad. Parte de la calidad es la facilidad de mantenimiento.
  • Asegura el cumplimiento de estos estándares. Debe poner mecanismos en marcha para asegurar el cumplimiento de los estándares. Aquí se puede ayudar de herramientas como SONAR o poner procedimientos en marcha de revisión por pares (por citar unos ejemplos)
  • Diseña medidas y métricas. ¿Cómo podemos saber si vamos bien sin medir? Esto es básico para cualquier gestor.
  • Revisa métricas, identifica mejoras y mantiene seguimiento. Fija objetivos y normas sobre métricas (Por ejemplo: % de cobertura en test unitario)
  • Se involucra en el diseño de todos los procesos del desarrollo de software. En todas las etapas tiene algo que decir este responsable. Desde el primer análisis hasta la aprobación final.
  • Coordina el testeo.
  • Vigila el resultado de las aplicaciones en producción, para mejorar sus procesos. Así suele querer estar informado de la gestión de incidencias o de problemas.
  • Se coordina con la PMO, para asegurar que sus necesidades están cubiertas en los procedimientos de gestión de proyectos.
  • Y lo que se le ocurra…

Resumiendo: Hace de todo y se mete en todo lo que haga falta para cumplir su objetivo.

QA somos todos

Esta es otra gran lección reciente para mí. Todo el equipo debe estar involucrado en QA. No sólo opinando, sino mentalizado y ejecutando tareas. La diferenciación entre programador y técnico de QA es mala. Todos los programadores con su trabajo están colaborando con el objetivo de QA. Así todos forman parte de QA. Pero también lo hacemos los gestores o los miembros de negocio. Todos remamos en la misma dirección.

Además, las tareas que parecerían más propias del equipo de QA, como el testeo, no tendrían que ser exclusivas de este equipo. Al final hablamos de programar, aunque sea un test automático: por lo que todos los programadores podrían (y deberían) colaborar en este objetivo.

Los gestores ayudaremos porque tenemos que ser el coach del equipo con respecto a este tema, insuflando está filosofía con nuestras acciones. Y negocio debe colaborar en esta tarea, y puede hacerlo. Puede revisar los planes de pruebas, asegurar el alineamiento de los análisis hecho con las necesidades de negocio. Un proyecto puede realizarse perfectamente y luego no estar alineado con lo que necesitan los usuarios. Esto también es parte de la calidad del producto realizado.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información.
Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector.
Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo.
Actualmente trabaja en Sunhotels, como responsable del equipo de operaciones TI.

Sin comentarios