Prevención de Defectos en el aseguramiento de la calidad del software, más vale prevenir que curar

En nuestra vida cotidiana utilizamos multitud de aparatos -electrodomésticos, vehículos, equipos informáticos…- que, con mayor o menor frecuencia, fallan o presentan defectos.  Los fabricantes, a medida que los van evolucionando, se ocupan también analizar estos defectos con el fin de evitar que se repitan en futuras versiones. En la mayoría de los casos, las marcas  llevan un registro de incidencias recogidas a través de los talleres adheridos y servicios postventa, que les permite conocer los fallos más habituales, su gravedad, frecuencia, etc.

En el mundo del software esta tarea no es tan habitual o, al menos, no lo era hasta hace poco. Tradicionalmente, cuando se detecta un defecto en una aplicación que está en fase de pruebas o una incidencia cuando ya está en producción, la anomalía se reporta al equipo de desarrollo para que la subsane, pero raramente se analiza el motivo que la produjo con el objetivo de evitar que se repita en futuras versiones.

Los modelos de pruebas de alta madurez, como los niveles 4 y 5 de TMMi, incluyen dentro de sus prácticas el análisis de la causa raíz de los defectos de forma sistemática, con el objetivo final de prevenirlos. Un proceso de pruebas maduro pasa de focalizarse en la detección de defectos para orientarse en la prevención de los mismos. Esta prevención consiste, básicamente, en analizar defectos detectados durante el proceso de pruebas y en producción, identificar sus causas y tomar acciones correctivas para prevenir que vuelvan a ocurrir. Se trata de una prevención proactiva, en la que se analizan los defectos para mejorar el proceso ‘aguas arriba’ y evitar que ese tipo de defecto, así como otros similares, aparezcan de nuevo.

Esta práctica permite optimizar  el proceso de pruebas, reduciendo sus costes, mejorando el time to Market  e incrementando la calidad de los productos puestos en producción. También permite mejorar el proceso de desarrollo desde requisitos hasta construcción, ya que las acciones correctivas identificadas para evitar que los defectos analizados vuelvan a producirse ponen el foco en las fases iniciales del ciclo de vida del software.

Está demostrado que aplicando este tipo de técnicas, la cobertura de requisitos probados aumenta en un 15% y que el número de incidencias en producción se reduce en un 18%. Además, aumenta el rendimiento del proceso de desarrollo en su conjunto, reduciendo el tiempo de entrega en un 12 %.

El proceso de pruebas basado en la prevención de defectos para asegurar la calidad del software

Para implantar un proceso de pruebas basado en la prevención de defectos es necesario definir qué parámetros van a servir para decidir si un defecto debe ser analizado o no. Partiendo de la base de que los recursos son limitados, no es viable analizar la  causa raíz de todos los defectos, sino sólo de aquellos que por su tipología merecen ese esfuerzo. Los parámetros que habitualmente se utilizan son: el daño potencial del defecto (económico o de imagen), frecuencia de ocurrencia, el coste que supone solucionarlo y el impacto del defecto en el conjunto de la aplicación.

Por otra parte, es necesario disponer de técnicas, mecanismos, herramientas y formación para que el análisis de la causa raíz de los defectos pueda llevarse a cabo de forma sistemática y formalizada. Diagramas de Ishikawa, diagramas de causa-efecto, esquemas de clasificación de defectos o la técnica de los 5 porqués, son algunos ejemplos de técnicas que permiten analizar cuál es la causa raíz de un defecto.

Con los parámetros y mecanismos de prevención implantados se estará en disposición de incorporar esta práctica al proceso de pruebas. Lo habitual es que al final de cada uno de los niveles de pruebas definidos en la organización se seleccionen, en base a los parámetros establecidos, los defectos a analizar. Para su análisis se aplicarán las técnicas definidas hasta llegar a identificar la causa raíz que ha provocado el defecto. Una vez conocida dicha causa, el siguiente paso será definir una o varias acciones correctivas que puedan evitar que un defecto similar ocurra. Como es lógico, las acciones correctivas se focalizan en las etapas anteriores al punto del ciclo de vida en la que se detectó el defecto, ya sea fase de requisitos, análisis, diseño o construcción.

Ejemplos reales de defectos analizados en el sector Telco

La prevención de defectos es muy útil en cualquier servicio de pruebas, sobre todo en aquellos sectores donde la evolución del negocio o del software sea muy dinámica. Por ejemplo, en el sector Telco, caracterizado por el gran volumen de aplicaciones que intervienen en los flujos de provisión -CRM, integración, facturación, backend, plataforma de red, etc.- y por la continua aparición de nuevas campañas que implican cambios en el software, disponer de un proceso de pruebas de alta madurez basado en la prevención de defectos garantiza un aumento evidente de la calidad del software, a la vez que una reducción del time to market muy significativa.

Algunos ejemplos reales de defectos analizados y de acciones correctivas identificadas en una compañía del sector Telco serían los siguientes:

Defectos por problemas de entorno

Se trata de defectos que impiden completar altas de clientes o cuando no llegan las órdenes a los instaladores finales. Tras el análisis se determina que en un 80% de los casos la causa es que no todos los sistemas que participan en el flujo están disponibles. Como acción correctiva se incluye una checklist de comprobación para asegurar la disponibilidad de todos los sistemas.

Defectos por parametrización incorrecta

Consiste en acciones que el sistema no debería permitir, pero que se permiten. La causa raíz es que la parametrización original del sistema no es correcta.

Defectos por configuración de perfiles incorrecta

En los que existen botones o funciones no disponibles debido a que los perfiles no están correctamente configurados. Tras analizar el defecto, se determina que los requisitos de dicha configuración no son correctos y se realizan acciones para mejorar el proceso de especificación de requisitos.

Defectos por flujos complejos

En los que se visualizan errores genéricos al tramitar pedidos y que, en un alto porcentaje de casos, se deben a un error en un sistema concreto del flujo de provisión derivado de un defecto en el diseño técnico del sistema. En este caso, se actúa sobre el diseño técnico para corregir el defecto.

Probar el software antes de su paso a producción es una práctica indispensable, pero no suficiente. La importancia que tienen los sistemas sobre el negocio de las organizaciones obliga a disponer de un ciclo de vida de software de alta madurez basado en la prevención, y es que, al igual que en el resto de aspectos de la vida, más vale prevenir que curar.

Por Javier de la Plaza
Responsable del Área de UX de MTP y TMMi Assessor

Por María Martín
Responsable de Soporte y Calidad Oficina QA

Te puede interesar…

Conoce nuestros cursos quality assurance y accede a formación especializada de MTP.

Ver más historias