Error, Defecto y Falla

Por Que Importa la Precision #

En conversaciones cotidianas, la gente usa “bug,” “error,” “defecto” y “falla” indistintamente. En testing profesional, estos terminos tienen significados especificos y distintos. Entender la diferencia no es pedanteria — determina si corriges el sintoma o la causa raiz.

Cuando un cliente reporta “la app se cayo,” esta describiendo una falla. Cuando un desarrollador encuentra la excepcion de puntero nulo en la linea 42, encontro el defecto. Cuando el equipo descubre que el desarrollador olvido manejar el caso donde la base de datos retorna resultados vacios, identificaron el error.

Tres cosas diferentes. Tres niveles diferentes del problema. Corregir solo la falla (reiniciar la app) o solo el defecto (agregar verificacion de null) sin abordar el error (por que los resultados vacios no se manejan sistematicamente?) garantiza que el problema se repetira.

Error: La Equivocacion Humana #

Un error (tambien llamado equivocacion) es una accion humana que produce un resultado incorrecto. Los errores ocurren porque los humanos son falibles — malinterpretamos requisitos, cometemos typos, olvidamos edge cases, aplicamos logica incorrecta, o simplemente tenemos un mal dia.

Ejemplos de Errores #

• Un desarrollador malinterpreta la especificacion e implementa “mayor que” en lugar de “mayor o igual que”
• Un disenador usa el codigo de color incorrecto (#FF0000 en vez de #EE0000)
• Un analista de negocio escribe un requisito ambiguo que puede interpretarse de dos formas
• Un ingeniero DevOps escribe la direccion IP incorrecta en la configuracion de despliegue
• Un tester escribe un caso de prueba con un resultado esperado incorrecto

Punto Clave #

No todo error lleva a un defecto. Un desarrollador podria cometer un error mental mientras codifica pero detectarlo inmediatamente en una auto-revision. El error ocurrio (el pensamiento incorrecto) pero no se creo ningun defecto (el codigo se corrigio antes del commit).

Defecto: El Bug en el Artefacto #

Un defecto (tambien llamado bug o fallo) es una falla en un producto de trabajo — codigo, documentacion, diseno, configuracion — que puede causar que el sistema falle. Un defecto es la manifestacion concreta de un error en un artefacto.

Ejemplos de Defectos #

• Un error off-by-one en un loop: for (i = 0; i <= array.length; i++) en lugar de i < array.length
• Una validacion faltante para numeros negativos en un campo de cantidad
• Una consulta SQL incorrecta que une las tablas equivocadas
• Un typo en un mensaje de error: “Su contrasena es incorrecto”
• Un valor de timeout mal configurado en un archivo de configuracion

Punto Clave #

No todo defecto lleva a una falla. Un defecto puede existir en codigo que nunca se ejecuta, en una funcionalidad desactivada por un feature flag, o en una condicion que requiere inputs especificos (y raros) para activarse. Estos se llaman defectos latentes — existen pero aun no se han manifestado como fallas.

Falla: El Problema Observable #

Una falla es una desviacion del sistema de su comportamiento esperado durante la ejecucion. Es lo que el usuario ve, experimenta o reporta. Una falla es la consecuencia observable de un defecto que se activa.

Ejemplos de Fallas #

• La aplicacion se cae al enviar un formulario
• La pagina de checkout muestra $0.00 para un producto de $99.99
• La busqueda retorna resultados en el idioma incorrecto
• La pagina de login tarda 45 segundos en cargar
• El email de restablecimiento de contrasena nunca se envia

Punto Clave #

No toda falla es causada por un defecto en el software. Las fallas tambien pueden ser causadas por:

• Problemas ambientales: Servidor sin memoria, timeout de red, disco lleno
• Dependencias externas: API de terceros caida, pool de conexiones agotado
• Problemas de datos: Datos corruptos en la base de datos, formato de datos inesperado
• Factores humanos: El usuario ingresa datos de forma inesperada

La Cadena: Error → Defecto → Falla #

La cadena funciona asi:

1. Una persona comete un error — un desarrollador malinterpreta que las fechas deben almacenarse en UTC
2. El error produce un defecto — el codigo almacena fechas en hora local en lugar de UTC
3. El defecto puede causar una falla — usuarios en diferentes zonas horarias ven fechas incorrectas

Pero la cadena puede romperse en cualquier eslabon:

• Un error podria no producir un defecto (detectado en code review)
• Un defecto podria no causar una falla (el camino de codigo nunca se ejecuta)
• Una falla podria no ser notada (ocurre en una funcionalidad raramente usada)

Analisis de Causa Raiz #

Entender la cadena error-defecto-falla habilita el analisis de causa raiz (RCA) — la practica de rastrear una falla a traves de su defecto hasta el error subyacente que la causo.

La Tecnica de los Cinco Por Que #

Una tecnica RCA simple pero poderosa es preguntar “Por que?” cinco veces:

Falla: El reporte mensual muestra totales de ingresos incorrectos.

1. Por que? Porque la consulta del reporte suma pedidos que fueron reembolsados.
2. Por que? Porque la consulta no filtra pedidos reembolsados.
3. Por que? Porque el desarrollador no sabia que los pedidos reembolsados permanecen en la tabla de pedidos.
4. Por que? Porque la documentacion del esquema no explica el manejo de reembolsos.
5. Por que? Porque no hay un proceso para documentar decisiones del modelo de datos.

La solucion real no es solo actualizar la consulta (corregir el defecto). Es crear estandares de documentacion para el modelo de datos (corregir la causa raiz del error) y establecer un proceso de revision (prevenir errores similares).

Niveles de RCA #

Corregir solo el sintoma es apagar incendios. Corregir la causa raiz es ingenieria. Corregir la causa sistemica es aseguramiento de calidad.

Clasificacion Practica #

Un escenario completo rastreado a traves de los tres niveles:

Escenario: Un sitio de e-commerce cobro a un cliente dos veces por el mismo pedido.

Falla: La tarjeta de credito del cliente fue cobrada $149.99 dos veces por el pedido #12847.

Defecto: La llamada al API de pago carecia de idempotencia — cuando un timeout de red hizo que la primera llamada retornara un error, el reintento envio una segunda solicitud de pago. El API proceso ambas porque no tenia mecanismo para detectar duplicados.

Error: El desarrollador asumio que el API de pago era idempotente (seguro de reintentar). No leyo la documentacion del API, que explicitamente indica que los llamadores deben incluir un ID de transaccion unico para prevenir cargos duplicados.

Causa raiz: No existe checklist de code review para integraciones de pago. No hay testing de integracion que verifique comportamiento idempotente.

Ejercicio: Clasifica Error, Defecto y Falla #

Para cada escenario, identifica el error, defecto y falla:

Escenario 1: Un usuario se registra con el email “john@example.com” y recibe un email de bienvenida dirigido a “null.”

Escenario 2: Un sistema de reservas de vuelos permite que un pasajero reserve un asiento que ya fue reservado por otra persona.

Escenario 3: Un cajero automatico dispensa $300 cuando un cliente solicita $200.

Tips Profesionales #

Tip 1: Siempre rastrea hasta la causa raiz. Cuando encuentres un defecto, no solo reportes el bug y sigas adelante. Pregunta “que error llevo a este defecto?” y “podrian errores similares producir otros defectos?” El defecto que encontraste podria ser uno de muchos causados por la misma causa raiz.

Tip 2: Los defectos pueden existir en cualquier artefacto. La mayoria piensa en defectos como bugs en codigo. Pero los defectos pueden existir en documentos de requisitos, especificaciones de diseno, casos de prueba, archivos de configuracion y documentacion. Un requisito incorrecto tambien es un defecto.

Tip 3: Rastrea la cadena error-defecto-falla en tus bug reports. En lugar de solo describir la falla (“la pagina se cae”), describe los tres niveles cuando sea posible. Esto da a los desarrolladores el contexto que necesitan para corregir la causa raiz, no solo el sintoma.

Puntos Clave #

• Error es una equivocacion humana; defecto es una falla en un artefacto; falla es comportamiento incorrecto observable
• La cadena fluye: Error → Defecto → Falla, pero puede romperse en cualquier eslabon
• No todos los errores producen defectos, y no todos los defectos causan fallas
• El analisis de causa raiz rastrea fallas hasta sus errores subyacentes
• Corregir sintomas (fallas) sin abordar causas raiz (errores) garantiza recurrencia
• La tecnica de los “Cinco Por Que” es una herramienta simple pero poderosa para analisis de causa raiz