El costo de los bugs

El software no es un producto que aparece por arte de magia. Generalmente es planeado y pasa por varias etapas antes de ser lanzado. Por lo tanto, pasando por su planificación, desarrollo, testeo y lanzamiento, existe la posibilidad de encontrar bugs en cualquiera de estas etapas. En la siguiente figura se grafica qué tan caro es arreglar un bug dependiendo de la etapa de desarrollo en donde es encontrado.

El costo de arreglar un bug tiende a aumentar de manera exponencial como se puede apreciar en la figura. Dicho esto, si encontramos un bug en la etapa de diseño el costo de arreglarlo será bajo. ¿Pero que pasa si ese problema aparece en la etapa de testeo? dependiendo del proceso de desarrollo que se está utilizando esto puede variar. Trabajando con scrum, la tarea con problemas puede ser devuelta fácilmente a desarrollo, pero ésta de todas formas consume tiempo, pero no es lo mismo en el caso de un proceso de desarrollo más lento en donde los cambios se pasan a un servidor de prueba una vez al día.

Otro caso para analizar es cuando el cliente se encuentra cara a cara con un bug, como muestra la figura, el costo es 100 veces mayor a que si este hubiese sido encontrado en diseño. ¿Por qué será tan caro? La respuesta es simple, un bug encontrado por el cliente debe ser arreglado de manera inmediata en la mayoría de los casos, por lo tanto, la característica recién lanzada será retornada al proceso de desarrollo, en consecuencia a esto, la carga de trabajo aumentará considerablemente para el equipo. Además en algunos casos será necesario enviar el arreglo a producción antes de la fecha en que regularmente se hace, lo cual agrava más este escenario, ya que se debe aplicar todo el esfuerzo de un lanzamiento en una fecha no prevista.

Como pudimos apreciar, encontrar errores en etapas avanzadas del proyecto pueden ser perjudiciales para el equipo en términos de tiempo, esfuerzo e incluso dinero. Para evitar estos problemas es necesario utilizar estrategias preventivas como tests de regresión o unit testing en el lado de los desarrolladores. En síntesis, es esencial esforzarse desde el comienzo del proyecto en la búsqueda o prevención de bugs, para así poder capturar la mayor cantidad de errores en las etapas de diseño y desarrollo. 

Definición de un bug.

Llamar bugs a todos los problemas encontrados en un software puede ser la manera más simple de hacerlo, pero en definitiva no es una definición completa. Para entregar la definición correcta es necesario comprender qué es un problema y cómo estos se presentan dentro del software.

El primer término que nos ayudará con esto es especificación de producto: Una especificación de producto, comúnmente mencionado como especificación o spec, es un acuerdo entre todo equipo de desarrollo de software. Esto define el producto que se está creando, detalla qué debe ser, cómo debe actuar, qué debe y que no debe hacer. Este acuerdo puede ir desde un entendimiento verbal hasta un documento formal.

Ahora que hemos definido que es un spec, detallaremos las cinco principales reglas que ocurren cuando un bug aparece:

1. El software no hace algo que la especificación del producto dice que debe hacer.
2. El software hace algo que el la especificación del producto dice que no debe hacer.
3. El software hace algo que el la especificación del producto no menciona.
4. El software no hace algo que que la especificación del producto no menciona, pero debería.
5. El software es difícil de entender o usar, lento o simplemente incorrecto.

Para comprender mejor estas reglas, las pondremos en práctica testeando las funcionalidades de una supuesta calculadora que se está desarrollando.

El spec principal de nuestra calculadora es que en ella se pueda sumar, restar, dividir y multiplicar sin ningún problema. Si al momento de testear la calculadora descubrimos que estos cálculos no se están haciendo correctamente, por ejemplo: restas con resultados negativos congelan la aplicación. En este caso estaremos enfrente de un bug causado por la primera regla.

Otro spec del producto dice que la calculadora nunca se debe congelar, crashear o bloquear. Si al momento de apretar teclas de manera aleatoria, creando cálculos aritméticos sin sentido, la calculadora se bloquea. Estamos ante un bug causado por la segunda regla.

Como indicamos en el primer problema, la calculadora debe poder sumar, restar dividir y multiplicar. Supongamos que el desarrollador agregó la funcionalidad para obtener la raíz cuadrada de un número  porque pensó que sería una característica genial. El problema es que esto nunca fue especificado, por lo tanto, esta nueva característica se convierte en un bug siguiendo la tercera regla.

El caso de la cuarta regla es un poco especial, debido a que estamos ante un enunciado que posee doble negativo. Supongamos que nuestra calculadora funciona correctamente cuando se hacen divisiones que tienen resultados con pocos decimales. pero al momento de testear exhaustivamente las divisiones nos damos que cuando el resultado tiene más de 10 dígitos en su decimal la fuente de la calculadora se torna pequeña e ilegible. En este caso estamos ante un problema de usabilidad que obviamente nunca se mencionó en la especificación del producto. Dicho bug es causado por la cuarta regla.

En el caso de que nuestra calculadora sea difícil de utilizar, posea teclas muy pequeñas, su texto sea ilegible, su configuración sea muy compleja, etc. En síntesis, cualquier problema que no luzca correcto, afecte su usabilidad o arruine la experiencia del usuario final será bug causado por la quinta regla.

Como pudimos ver con los ejemplos mencionados, los bugs pueden aparecer de diferentes formas en un software, por lo tanto un bug es una falla, algo no especificado, inconsistencias o problemas que afectan la experiencia del usuario al utilizar el software.