¿Qué Es Error Guessing?
Error guessing es una técnica de test design basada en experiencia donde los testers usan su conocimiento de errores comunes, defectos típicos y fallas pasadas para anticipar dónde es probable que el software falle. A diferencia de las técnicas formales que siguen reglas, error guessing aprovecha la intuición y la experiencia de dominio.
Por Qué Funciona Error Guessing
Los testers experimentados desarrollan intuición sobre dónde se esconden los defectos. Esto viene de:
- Años encontrando bugs similares en diferentes proyectos
- Conocimiento de errores de programación comunes
- Comprensión de comportamientos típicos del usuario que rompen el software
- Conciencia de puntos de integración que frecuentemente fallan
El Enfoque de Taxonomía de Defectos
Para hacer el error guessing sistemático, construye una taxonomía de defectos:
Categorías Comunes de Errores
Manejo de Input:
| Patrón de Error | Test |
|---|---|
| Null/vacío | Enviar campos de formulario vacíos |
| Caracteres especiales | <script>alert(1)</script>, '; DROP TABLE-- |
| Extremadamente largo | String de 10,000 caracteres en campo nombre |
| Unicode | Emojis, texto RTL, caracteres chinos |
| Números negativos | -1 en campo de cantidad |
| Cero | 0 items, pago de $0 |
| Espacios al inicio/final | " admin " como username |
Cálculos:
| Patrón de Error | Test |
|---|---|
| División por cero | Calcular promedio de 0 items |
| Integer overflow | Cantidad = 2,147,483,647 + 1 |
| Precisión float | $0.1 + $0.2 = ? |
| Aritmética de fechas | Agregar 1 mes a Ene 31 |
Estado/Timing:
| Patrón de Error | Test |
|---|---|
| Double submit | Click botón enviar dos veces rápido |
| Botón atrás | Enviar formulario, presionar atrás, enviar de nuevo |
| Sesión expirada | Dejar página abierta toda la noche, luego enviar |
| Edición concurrente | Dos usuarios editan el mismo registro |
Ejemplo Real: Testing de Carrito de Compras
| # | Error Guess | Razón |
|---|---|---|
| 1 | Agregar item, luego se agota el stock | Race condition de inventario |
| 2 | Agregar 999,999 del mismo item | Overflow de cantidad |
| 3 | Aplicar cupón expirado | Validación de fecha |
| 4 | Cambiar moneda a mitad del checkout | Corrupción de estado |
| 5 | Abrir carrito en dos tabs, checkout en ambos | Modificación concurrente |
| 6 | Agregar item con precio $0.001 | Redondeo en total |
| 7 | Carrito con 100+ items únicos | Performance/renderizado |
| 8 | Eliminar todos los items y proceder a checkout | Manejo de estado vacío |
Construyendo Tu Catálogo Personal de Defectos
Framework Estructurado de Error Guessing
Crea un catálogo organizado por:
1. Categoría — ¿Qué tipo de error? 2. Trigger — ¿Qué input o acción lo causa? 3. Síntoma — ¿Qué ve el usuario? 4. Probabilidad — ¿Qué tan común es en tu dominio?
Ejemplo de Entradas del Catálogo:
| Categoría | Trigger | Síntoma | Probabilidad |
|---|---|---|---|
| Input | Pegar texto con chars Unicode ocultos | Corrupción de datos | Media |
| Timing | Enviar durante auto-guardado | Datos duplicados o perdidos | Alta |
| Auth | Token expira durante formulario multi-paso | Falla silenciosa | Alta |
| Datos | Importar CSV con columnas extra | Crash o mapeo incorrecto | Media |
| Display | Texto muy largo sin espacios | Layout se rompe | Alta |
| Locale | Campo fecha con DD/MM vs MM/DD | Fecha incorrecta guardada | Alta |
Combinando Error Guessing con Técnicas Formales
Mejor práctica:
- Aplicar técnicas formales primero
- Luego error guessing para encontrar lo que las técnicas formales perdieron
- Enfocar error guessing en áreas de mayor riesgo y complejidad
Ejercicio: Sesión de Error Guessing
Escenario: Estás probando una página de edición de perfil con campos: Nombre, Bio (máx 500 chars), Carga de foto de perfil, Fecha de nacimiento y URL de sitio web.
Tarea: Genera al menos 10 test cases de error guessing organizados por categoría.
Pista
Piensa en cada campo: ¿Qué es lo peor que un usuario podría ingresar? ¿Qué pasa en los límites? ¿Qué hay de edge cases de carga de archivos (0 bytes, 10GB, formato incorrecto, archivo ejecutable)?
Solución
| # | Categoría | Test | Razón |
|---|---|---|---|
| 1 | Input | Nombre = <img src=x onerror=alert(1)> | XSS en campo almacenado |
| 2 | Input | Bio = exactamente 500 chars + 1 más | Enforcement de límite |
| 3 | Input | Bio con solo emojis (500 emojis) | Manejo Unicode, conteo |
| 4 | Upload | Foto = archivo de 0 bytes | Manejo de archivo vacío |
| 5 | Upload | Foto = .exe renombrado a .jpg | Bypass de validación de tipo |
| 6 | Upload | Foto = imagen de 50MB | Enforcement de límite de tamaño |
| 7 | Fecha | Nacimiento = fecha de mañana | Fecha futura inválida |
| 8 | Fecha | Nacimiento = Feb 29, 2023 (no bisiesto) | Manejo de fecha inválida |
| 9 | URL | Website = javascript:alert(1) | XSS por esquema URL |
| 10 | URL | Website = URL muy larga (2000+ chars) | Validación de longitud |
| 11 | Estado | Editar nombre, no guardar, navegar fuera | ¿Advertencia de cambios? |
| 12 | Concurrente | Editar perfil en dos tabs, guardar ambos | ¿Last-write-wins o conflicto? |
Tips de Profesional
- Mantén un diario personal de bugs. Registra cada bug interesante — con el tiempo se convierte en tu activo de testing más valioso.
- Aprende de incidentes de producción. Los post-mortems revelan patrones de error que el test design formal raramente cubre.
- Piensa como un atacante. Estudia OWASP Top 10 para patrones de testing web.
- Considera el entorno del usuario. Redes lentas, browsers antiguos, ad blockers, herramientas de accesibilidad — crean errores que los desarrolladores raramente anticipan.
- Comparte tu catálogo con el equipo. Una taxonomía de defectos de equipo es más poderosa que el conocimiento individual.