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:
- El software no hace algo que la especificación del producto dice que debe hacer.
- El software hace algo que el la especificación del producto dice que no debe hacer.
- El software hace algo que el la especificación del producto no menciona.
- El software no hace algo que que la especificación del producto no menciona, pero debería.
- 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.
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.
No hay comentarios.:
Publicar un comentario