Aseguramiento de la calidad

Es una disciplina ligada a la Ingeniería del Software.  Actualmente y más allá de las carreras universitarias relacionadas (Ingeniería Informática principalmente) existen cursos y certificaciones especializadas, como el certificado de Ingeniero de Calidad otorgado por el ISTQB (International Software Testing Qualifications Board).

Es importante porque se trata de un conjunto de acciones, métodos, herramientas y técnicas que permiten el control de calidad del desarrollo de productos y servicios digitales o aplicativos software. La existencia de un programa permitirá que se cumplan los requisitos y niveles de calidad esperados para todos los activos relacionados.

A través de la evolución o asunción de buenas prácticas y niveles de madurez mayores en los métodos y técnicas existentes para este control de calidad.

La aplicación en una empresa de cualquier metodología que permita el control de calidad de sus aplicativos, debe llevarse a cabo mediante la introducción especializada de procesos, técnicas, herramientas y actividades relacionadas, siempre bajo un experto certificado.

Las herramientas son múltiples y darán cobertura y soporte a las actividades que se lleven a cabo dentro de las tareas de control de calidad, como por ejemplo gestión de pruebas, gestión de incidencias, automatización de pruebas, pruebas de rendimiento o análisis de código. Ejemplos:

• Testlink
• Jira
• Selenium
• Jmeter
• Sonar, etc.

La Calidad es el primer objetivo de la norma ISO 9001 en el que se describen los requisitos que debe cumplir el Sistema de Calidad de una organización, incluyéndola como las prácticas planificadas y sistemáticas que se llevan a cabo.

Los beneficios son múltiples, entre ellos se destacan el aseguramiento del cumplimiento de los requisitos del producto o activo software, su calidad mediante la detección de defectos y el ahorro de costes y plazos del proceso de desarrollo y puesta en producción. Por supuesto, también, la satisfacción del cliente final.

Las metodologías de control de calidad establecen el proceso detallado para la ejecución de las actividades de pruebas estáticas y dinámicas, por ejemplo OMNIATEST. Las herramientas asociadas son múltiples y dependen de la actividad concreta, como por ejemplo gestión de pruebas, gestión de incidencias, gestión de calidad, automatización de pruebas, pruebas de rendimiento o análisis de código (ej: Testlink, Jira, Selenium, jmeter, sonar etc.).

El Aseguramiento de la Calidad es el conjunto de actividades planificadas y sistemáticas aplicadas en un sistema de gestión de calidad para que los requisitos del producto o servicio sean satisfechos

Las conversaciones que hablan de un modelo de aseguramiento de la calidad del software son una fuente inagotable de términos ambiguos: el desarrollo debe ser correcto, el rendimiento adecuado, la seguridad alta, debe ser usable, mantenible y, en general, la calidad debe ser buena. Es complicado evaluar en base a estos términos si un software tiene o no una gestión de calidad adecuada. Esta ambigüedad ha generado históricamente discusiones sobre la calidad del software que frecuentemente han acabado generando acuerdos a posteriori pero nos estamos moviendo hacia situaciones en las que queremos que la decisión de puesta en producción sea tomada por una máquina. Eso pasa, entre otras cosas, por aportar criterios objetivos que puedan ser programados de forma precisa. Para un apropiado control de calidad necesitamos establecer, pues:

• Un conjunto de criterios a medir
• Un indicador o conjunto de indicadores que permita medir cada criterio con un algoritmo que permita calcular su valor
• Y un dato de referencia que permita decidir si el valor obtenido para el indicador es admisible

Vamos a ver cada punto: Criterios Lo que queremos medir suele tener que ver con la búsqueda del cumplimiento de objetivos: queremos ver si estamos siguiendo adecuadamente los procedimientos de trabajo, si un proyecto va bien, si hay riesgo en el cumplimiento de fechas o en que el software esté plagado de errores, si el software que nos han entregado es de buena calidad… No tiene sentido medir si no sabemos para qué queremos medir, así que lo primero que tenemos que tener claro es el “para qué” queremos medir y a partir de ahí nos vamos al qué. Si hablamos de calidad del software (calidad de producto), una buena fuente para identificar criterios es la ISO 25000 (la evolución de la ISO 9126). En esta norma se presenta un modelo de control de calidad del software para el que se identifica un conjunto de “características” de calidad: funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad, portabilidad, seguridad y compatibilidad. Para cada característica se definen subcaracterísticas (disponibilidad, interoperabilidad, reusabilidad, corrección funcional…). Esta puede ser una buena fuente de “qués”. En cualquier caso, es necesario considerar, como indicábamos previamente, los objetivos del Negocio y, en ese sentido, la participación de las áreas de Negocio es particularmente importante. Indicadores ¿Cómo medimos el criterio? Tenemos dos posibilidades: hacerlo de forma subjetiva o de forma objetiva. La opción subjetiva suele estar asociada a la opinión del usuario, del responsable técnico… suele basarse en encuestas y, siendo importante, es difícil integrarla en un escenario proactivo en tiempo real: necesitamos frecuentemente información antes de la puesta en producción y, si nos limitamos a la opción subjetiva, tendremos la limitación del momento. Así, por ejemplo, el usuario va a poder dar su calificación una vez haya usado la aplicación en producción real. Lo mismo pasa con los departamentos responsables de la explotación. Así pues, ya sea en exclusiva o compartida con la opción subjetiva, es necesario utilizar mediciones objetivas. La fuente más frecuente de información para la medición de la calidad del producto son los resultados de las pruebas (estáticas o dinámicas) y, concretamente, los defectos localizados durante dichas pruebas. No basta, sin embargo, con contabilizar los errores detectados. Debemos considerar factores de ponderación: ¿cuántas pruebas hemos hecho? ¿qué tan grande es el código? ¿qué tan complejo?… La combinación de defectos y factor de ponderación junto con un filtro que nos permita centrarnos en la característica o subcaracterística cuya calidad queremos controlar es lo que nos va a dar la fórmula que nos permitirá calcular el indicador. Otra posible fuente a la hora de medir la calidad del software es ver hasta qué punto el trabajo realizado es suficiente: ¿Cuántos comentarios hemos generado en nuestro código? Parece sencillo, pero no lo es…. A medida que vamos haciendo “zoom” van apareciendo más y más indicadores ¿Cuántos defectos ha generado una entrega? ¿Cuántos de esos eran funcionales? ¿Cuáles se esos estaban asociados a operativa crítica? ¿Cuántos de esos asociados a cada módulo… Una herramienta de análisis de código puede llegar a generar varios cientos de indicadores asociados a la mantenibilidad. ¿Los obtenemos y consideramos todos? Debemos evitar que los árboles nos impidan ver el bosque. Necesitamos un conjunto de información manejable que nos permita tomar decisiones a la hora de medir la calidad del software. En el caso de que la decisión la tome una máquina, el número de indicadores puede no ser tan problemático pero agrava un segundo factor de riesgo: la disponibilidad de los datos asociados a los parámetros (primitivas) que componen la fórmula del indicador:

• En primer lugar, los datos pueden o no estar registrados. Hay organizaciones en las que los errores detectados se informan por correo o de palabra (no siendo, por ello, directamente procesables). Sin llegar a tanto, es frecuente que no llegue a registrarse la causa raíz de un error… La ausencia de detalle en la información registrada puede impedirnos obtener indicadores que nos digan el módulo que más errores genera, el tipo de errores que genera, si estos están asociados a determinadas interfaces, si la seguridad suele tener agujeros… Conseguir que los datos se registren en tiempo y forma es, frecuentemente, lo más difícil de conseguir, al necesitarse cambios en los procedimientos de trabajo (o en su grado de aplicación).
• En segundo lugar, la fuente de los datos puede ser muy variada y estar distribuida. Las fuentes de datos (bases de datos, tablas…) pueden ser tecnológicamente distintas y requerir métodos de acceso desarrollados específicamente para cada fuente (ETLs).

Umbrales de control de calidad del software ¿Hasta qué punto una entrega es suficientemente buena? Es el “suficientemente” el factor que más frecuentemente genera ambigüedad: podemos, sin demasiado esfuerzo, identificar factores críticos en una organización (funcionalidad de la interfaz de usuario, de un módulo de backend, la seguridad, el rendimiento, la usabilidad…), pero es más complicado establecer donde está el límite de lo admisible. ¿Quién decide dónde debería estar el límite? Frecuentemente será el usuario, en ocasiones el responsable de definir y asegurar el cumplimiento de buenas prácticas (ej: Arquitectura)… Este responsable debe definir el criterio a seguir a la hora de establecer los umbrales de calidad (los “quality gates”). El objetivo “cero errores” es una petición (y, a veces, una oferta) relativamente frecuente pero es ligeramente menos realista que plantear un tiempo de respuesta cero o infinitos usuarios concurrentes… Hay que identificar objetivos viables y suele haber dos fuentes en las que basarse:

• Las referencias de mercado: estudios que proporcionan promedios de errores por punto función asociados a conceptos como la tecnología, el lenguaje de programación usado, la fase de pruebas o el nivel de madurez del equipo de desarrollo.
• El histórico en la organización: no hay ninguna referencia tan precisa como la que utiliza información derivada de tus sistemas, tu entorno, tus equipos de trabajo… el histórico de tu organización es la fuente ideal pero requiere una sistematización del registro de la información y un tiempo para ir acumulando datos y tendencias.

Y ahora, la valoración Hemos empezado hablando de decisiones que toma una máquina (un programa, más bien). Los pasos que hemos dado nos van a permitir proporcionar instrucciones para que la decisión se ajuste a nuestras necesidades; sin embargo, todos los pasos descritos también son aplicables a una toma de decisiones “tradicional” llevada a cabo por una persona o conjunto de personas. Aun en aquellos casos en los que la opción IA está disponible para la toma de decisiones, suele haber situaciones en las que la última palabra la toma una persona. En esos casos nos encontramos con que tenemos que aplicar distintos criterios o, al menos, matizarlos:

• No pueden definirse demasiados indicadores. Lo de los árboles y el bosque es particularmente aplicable a las decisiones tomadas por las personas.
• La forma de presentar la información debe ser lo más gráfica posible. Mejor un diagrama que una tabla.

La idea es tener clara la situación “de un vistazo” y para ello es particularmente importante el uso de cuadros de mando específicamente diseñados para la toma de decisiones.

Un sistema de aseguramiento de la calidad es bueno para el desarrollo del negocio y para el prestigio de la empresa

Las compañías que solicitan formación específica o certificada en Calidad del Software para sus equipos de trabajo buscan, fundamentalmente, impulsar el desarrollo y actualizar las habilidades de sus profesionales, pero también alcanzar el reconocimiento del mercado a través de la certificación obtenida. En estos momentos, en la formación de sus equipos, las empresas se centran en tres grandes tendencias: automatización, pruebas en entornos ágiles y proyectos formativos.

Formación en Herramientas específicas

En la actualidad, las herramientas de desarrollo han aumentado la productividad de los programadores, pero también la presión sobre los equipos y roles de testing. De ahí la preocupación por conocer los conceptos de automatización de pruebas y la implantación de una metodología concreta de automatización, llevándola a la práctica a través de las herramientas para cada caso, como son, por ejemplo, Selenium o QTP/UFT de HP.

Certificaciones Oficiales de Calidad Software

En segundo lugar, las certificaciones oficiales de Agile Tester resultan interesantes para aquellos profesionales que tienen implicación en proyectos ágiles y que desean familiarizarse con el entorno ágil. En este caso, el ISTQB, dentro de su programa de certificaciones, ha incluido la de Agile Tester Extension Foundation Level, que se une a certificaciones anteriores como iSQI CAT. Por último, destaca el interés por los cursos en los que se aborda la formación como un proyecto en el que se lleva a cabo un diseño en base a los requisitos y necesidades de cada cliente o persona. En esta realidad, las empresas valoran mucho que sus empleados obtengan certificaciones oficiales, ya que son otorgadas por organismos internacionales que cuentan con el reconocimiento de todo el sector de la Calidad del Software. En este sentido, debo recordar que MTP es una empresa homologada y certificada como formadora del iSQI (International Software Quality Institute) y del ISTQB (International Software Qualifications Board). En el caso del iSQI podemos encontrar las certificaciones relacionadas con el ámbito agile y de desarrollo en cursos como Agile Essentials, que ofrece un conocimiento básico del entorno ágil; Certified Agile Tester, un paso superior al curso anterior, en el que se comprende el papel de las pruebas dentro de un proyecto ágil y se obtiene la capacidad de aplicar de forma efectiva las habilidades prácticas asociadas al mismo y, por último, la certificación Test Driven Development (TDD), con la que los desarrolladores aplican las mejores prácticas de desarrollo de software ágil. En lo que respecta al ISTQB, es posible desarrollar un proyecto de formación completo, desde la certificación de Tester en el Foundation Level hasta el Advanced Level, con las especializaciones en Test Manager, Test Analyst y Technical Test Analyst. Por último, señalar que hemos incluido en nuestra formación la reciente certificación ISTQB Agile Tester Extension – Foundation Level, desarrollada por este organismo para cubrir el área agile.