¿Cual es la diferencia entre un defecto y un fallo en un sistema informático? Para la mayor parte de nosotros (como usuarios), no hay ninguna diferencia: «Apunta este fallo, esto no hace lo que yo quería».

Sin embargo, si estamos utilizando un software garantizado no debemos colocar todas nuestras decepciones en la bandeja de «un fallo: me lo deben». No hay garantía que lo resista. Por ello, es necesario diseccionar la situación para poder catalogar correctamente sus causas y consecuencias.

Ya empezamos. Bien, ¿Qué es un <fallo> en un sistema software?

Puesto que tenemos todo un instituto internacional especializado en la certificación de profesionales de Pruebas Software, el «ISTQB», veamos cómo lo definen: fallo es la «desviación del componente o del sistema respecto de prestación, servicio o resultado esperado.»

Es decir, nos señalan que un fallo es la incapacidad de un sistema software o de un componente para realizar las funciones solicitadas dentro de unos márgenes de rendimiento requeridos. Vamos, que el sistema software tiene un comportamiento decepcionante.

Como el sistema software ha fallado, ¡Que lo arreglen!. En primera instancia, cualquier decepción en el comportamiento del sistema la catalogamos como anomalía. Debemos tomarlo como el punto de entrada para cualquier forma de gestión de la Calidad del Software que utilicemos.

Entonces, ¿Qué es una <anomalía>?

Formalmente, anomalía es «cualquier condición que se desvíe de las expectativas basadas en las especificaciones de requisitos, documentos de diseño, documentos de usuario, estándares, etc., o de la percepción o experiencia de alguien. Las anomalías pueden ser encontradas durante, aunque no se limitan sólo a, revisiones, proceso de pruebas, análisis, compilación, o uso de productos de software o documentación aplicable. [IEEE 1044]»
[Según el instituto internacional dedicado a la certificación de profesionales de Pruebas Software (ISTQB)].

Anomalía:
Cualquier condición del sistema software que se desvíe de nuestras expectativas.
Nada más y nada menos.

Tranquilidad. Es cierto que estamos decepcionados y la calidad del producto se resiente, pero todavía no sabemos en qué momento la construcción del producto software y nuestras expectativas se desconectaron. Aunque es claro que la detección temprana de anomalías ahorra dinero y decepciones, la caza de brujas tiene que esperar.

Habitualmente las anomalías son tratadas como incidentes. Su tratamiento nos llevará hacia catalogar la causa de nuestra decepción como defecto, nueva funcionalidad o como un sueño imposible.

El sueño de E.T.

Entonces, ¿Qué es un <defecto>?

Volviendo a tirar de formalismo ISTQB, un defecto es una «imperfección en un componente o sistema que puede causar que el componente o sistema falle en desempeñar las funciones requeridas, por ejemplo una sentencia o una definición de datos incorrectas. Si se localiza un defecto durante una ejecución puede causar un fallo en el componente o sistema.»
[Según el instituto internacional dedicado a la certificación de profesionales de Pruebas Software (ISTQB)].

Atentos, hablan de que se «falle en desempeñar las funciones requeridas». En los defectos, nos quedamos sin espacio para nuestros sueños y empieza a funcionar la garantía de la garantía.

Un defecto es lo mismo que una falta («fault»), problema o «bug». Catalogando los tipos de defectos podremos elaborar la Taxonomia de «bugs» sobre la que apoyar nuestro sistema de gestión de incidentes («defect management tool»). Cada defecto que se introduce en el software es como resultado de un error.

¡Ajá, mi garantía! Entonces, ¿Qué es un <error> en el software?

Igual no te lo imaginas, el ISTQB establece que un error es una «acción humana que produce un resultado incorrecto. [Según IEEE 610]». Centrándolo en la construcción de software, un error es un fallo, mala concepción («misconception») o mala compresión («misunderstanding») por parte del desarrollador de software.

Nota: Léase desarrollador software en sentido de involucrado en el proceso de construcción software, es decir, incluye ingenieros software, programadores, analistas, ingenieros de pruebas, etc.

Ya tenemos la secuencia de los hechos:

el error humano cometido
inyecta un defecto en el software que, ocasionalmente,
se observa como una anomalía
a causa de un comportamiento incorrecto,
no acorde a lo especificado,
que finalmente
provoca el fallo software.

En esta secuencia hemos dejado al margen el conjunto de anomalías motivadas porque el sistema no satisface las expectativas -no expresadas- del cliente. Su gestión requiere de una absoluta vocación por el descubrimiento y la detección temprana, de forma que la adaptación a las expectativas del cliente se haga con el menor desperdicio posible.

Si queréis profundizar en cómo coordinar estas actividades en vuestro ciclo de construcción de software, te invitamos a ponerte en contacto con nosotros para conversar sobre cómo desde el Aseguramiento de la Calidad Software (SQA) se puede impulsar la «entrega satisfactoria del valor esperado», como máxima expresión de la Calidad adecuada al propósito.