En Testing de Software es muy común escuchar palabras como error, defecto, falla, bug e incidencia. En conversaciones informales muchas veces se usan como si significaran lo mismo, pero en un contexto profesional conviene distinguirlas.
Usar los términos correctos ayuda a comunicar mejor qué ocurrió, dónde está el problema y qué información necesita el equipo para resolverlo. Un tester que describe bien una situación facilita el análisis, evita confusiones y mejora la velocidad de corrección.
En este tema estudiaremos cada concepto con ejemplos simples y luego veremos cómo se relacionan entre sí.
Una forma sencilla de entender la relación entre estos conceptos es pensar en una cadena:
No siempre se ve la cadena completa con tanta claridad, pero este esquema sirve para comenzar. Una persona puede cometer una equivocación al entender un requisito o al escribir código. Esa equivocación puede quedar incorporada como un defecto. Luego, cuando el sistema se usa bajo ciertas condiciones, ese defecto puede producir una falla visible. Finalmente, alguien puede registrar una incidencia para que el equipo investigue el problema.
Un error es una equivocación humana. Puede ocurrir al analizar un requisito, diseñar una solución, programar, configurar un ambiente, escribir documentación o ejecutar una prueba.
Por ejemplo, si una regla de negocio dice que un cliente premium tiene 15% de descuento y una persona entiende que el descuento es de 10%, esa equivocación es un error. Todavía no estamos hablando del comportamiento del sistema, sino de una interpretación incorrecta realizada por una persona.
Los errores pueden aparecer por muchos motivos:
El testing ayuda a detectar consecuencias de esos errores, pero también puede prevenirlos si participa temprano en la revisión de requisitos y criterios de aceptación.
Un defecto es un problema presente en algún artefacto del producto o del proyecto. Puede estar en el código, en una configuración, en una base de datos, en un documento, en un diseño de pantalla o en una especificación.
Si el desarrollador implementa el descuento premium como 10% en lugar de 15%, el código contiene un defecto. Ese defecto puede permanecer oculto hasta que alguien pruebe o use exactamente esa situación.
Algunos ejemplos de defectos son:
El defecto es la causa potencial de un comportamiento incorrecto. Puede existir aunque todavía nadie lo haya observado.
Una falla es el comportamiento incorrecto que se observa cuando el sistema se ejecuta. Es decir, es la manifestación visible de un defecto.
Siguiendo el ejemplo anterior, si un cliente premium realiza una compra de $1000 y el sistema descuenta $100 en lugar de $150, se observa una falla. El resultado mostrado no coincide con el resultado esperado.
Una falla puede presentarse de muchas maneras:
En testing normalmente observamos fallas. A partir de ellas, el equipo investiga cuál es el defecto que las causa.
Una incidencia es un registro formal de una situación que debe ser analizada. Puede corresponder a una falla, a una duda, a una mejora, a un comportamiento inesperado o a una diferencia entre lo observado y lo esperado.
No toda incidencia termina siendo un defecto. A veces el sistema se comporta correctamente, pero la especificación no estaba clara para quien probó. Otras veces se registra una incidencia porque falta información para decidir si el comportamiento es correcto.
Una incidencia bien registrada suele incluir:
El objetivo de una incidencia no es culpar a alguien, sino aportar información suficiente para que el equipo pueda analizar y resolver la situación.
La palabra bug se usa habitualmente como sinónimo informal de defecto o falla. En muchos equipos se dice "hay un bug" para referirse a cualquier comportamiento incorrecto.
En la práctica diaria no siempre es grave usar la palabra bug, siempre que el equipo se entienda. Sin embargo, para aprender testing conviene conocer los términos más precisos:
La precisión en el lenguaje mejora la calidad de los reportes y de las conversaciones técnicas.
| Concepto | Qué representa | Dónde aparece | Ejemplo |
|---|---|---|---|
| Error | Equivocación humana. | En el análisis, diseño, programación, configuración o prueba. | Una persona interpreta mal una regla de descuento. |
| Defecto | Problema incorporado al producto o a un artefacto. | En código, documentación, diseño, datos o configuración. | El código calcula 10% en lugar de 15%. |
| Falla | Comportamiento incorrecto observable. | Durante la ejecución del sistema. | El total de la compra se muestra mal. |
| Incidencia | Registro formal de una situación a revisar. | En una herramienta de seguimiento o documentación del equipo. | Se crea un ticket con pasos, resultado obtenido y resultado esperado. |
Veamos un ejemplo en una tienda en línea:
En este ejemplo:
Un defecto puede existir en el sistema y no manifestarse en todas las ejecuciones. Para que aparezca una falla, deben darse ciertas condiciones.
Por ejemplo, si el defecto está en el cálculo de descuentos para clientes premium, un usuario común podría comprar sin problemas. La falla solo aparecerá cuando se pruebe o use una combinación específica: cliente premium, producto seleccionado y descuento aplicable.
Esto explica por qué algunos defectos permanecen ocultos durante mucho tiempo. No basta con ejecutar una funcionalidad de manera superficial; es necesario pensar en datos, condiciones y variantes relevantes.
No siempre una falla tiene una causa evidente. Un botón que no funciona podría deberse a muchas razones:
Por eso, cuando registramos una incidencia, debemos describir lo observado sin inventar la causa si no la conocemos. Es mejor decir "el botón Guardar no responde al presionarlo" que afirmar sin evidencia "hay un error en la base de datos".
Una de las habilidades más importantes al reportar problemas es distinguir entre resultado esperado y resultado obtenido.
Ejemplo:
Esta comparación permite identificar claramente la diferencia entre lo correcto y lo observado. Sin resultado esperado, una incidencia puede quedar incompleta o ser difícil de analizar.
Durante una prueba podemos encontrar situaciones que parecen errores, pero luego se descubre que no lo son. Algunos ejemplos:
Por eso es correcto registrar una incidencia cuando hay una diferencia o duda relevante. Luego, el equipo la analizará y decidirá si corresponde corregir, aclarar, cerrar o transformar en una mejora.
El lenguaje preciso evita discusiones innecesarias. En lugar de decir "todo está mal", conviene describir con claridad:
Un reporte objetivo mejora la colaboración. El propósito del testing no es señalar culpables, sino ayudar a encontrar y resolver problemas que afectan la calidad del producto.
Distinguir entre error, defecto, falla e incidencia permite pensar y comunicar mejor dentro de un proyecto de software. Estos conceptos ayudan a ordenar el análisis: una persona puede cometer un error, ese error puede generar un defecto, el defecto puede provocar una falla y la situación puede registrarse como una incidencia.
Para un estudiante que comienza en testing, lo más importante es aprender a observar con precisión. No basta con decir que algo "no funciona"; debemos explicar qué se esperaba, qué ocurrió, bajo qué condiciones y con qué evidencia.
En el próximo tema estudiaremos el rol del tester, del desarrollador y del equipo de calidad, para comprender cómo colaboran las distintas personas en la construcción de software confiable.