¿Qué Es SBTM?
Session-Based Test Management (SBTM) fue desarrollado por Jonathan y James Bach para resolver un problema fundamental: ¿cómo gestionas, mides y reportas testing exploratorio?
El testing con scripts es fácil de gestionar — tienes test cases, rastreas cuáles pasaron y fallaron, y reportas una tasa de éxito. Pero el testing exploratorio no tiene test cases preescritos. Sin un framework de gestión, es invisible para gerentes y stakeholders.
SBTM resuelve esto dividiendo el testing exploratorio en sesiones — bloques ininterrumpidos de tiempo de testing enfocado con un charter definido, duración fija y resultados documentados.
Estructura de la Sesión
El Charter
Cada sesión comienza con un charter — una declaración de misión que define qué explorar y qué riesgos investigar.
El Time-Box
Las sesiones tienen duración fija: Corta: 45-60 minutos, Normal: 90 minutos, Larga: 120 minutos.
El time-box crea urgencia y enfoque. Las sesiones deben ser ininterrumpidas.
La Hoja de Sesión
HOJA DE SESIÓN
==============
Charter: Explorar el flujo de pagos con tarjetas expiradas y
rechazadas para descubrir gaps en manejo de errores.
Tester: Jane Smith
Fecha: 2026-03-19
Duración: 90 min (planificados), 85 min (reales)
NOTAS:
- Visa expirada: Muestra "Tarjeta rechazada" correctamente
- Mastercard expirada: Muestra error genérico — inconsistente
- Tarjeta rechazada (fondos insuficientes): Sin mensaje específico
- Después de 3 intentos fallidos, el pedido se cancela silenciosamente
BUGS:
1. BUG-1234 (Alto): Cancelación silenciosa después de 3 fallas de pago
2. BUG-1235 (Medio): Mensajes de error inconsistentes entre tarjetas
3. BUG-1236 (Medio): Reset del carrito al cambiar método de pago
ISSUES:
- ¿El límite de 3 fallas es por diseño o un bug?
- ¿Debería la app sugerir métodos de pago alternativos?
% EN CHARTER: 75%
ÁREAS NO CUBIERTAS: PayPal, Apple Pay, timeouts de pago
El Debrief
Después de cada sesión, el tester se reúne brevemente (10-15 minutos) con el lead de testing para revisar resultados: qué se probó, qué se encontró, qué falta, qué explorar después.
Métricas SBTM
| Métrica | Definición | Uso |
|---|---|---|
| Sesiones completadas | Número de sesiones ejecutadas | Rastrear volumen |
| Bugs por sesión | Promedio de bugs por sesión | Medir efectividad |
| % on charter | Tiempo en la misión del charter | Medir enfoque vs. descubrimiento |
| % session setup | Tiempo en configuración | Identificar problemas de ambiente |
| Áreas de cobertura | Features/áreas exploradas | Rastrear qué fue probado |
| Áreas de riesgo pendientes | Charters no ejecutados | Rastrear gaps |
Interpretando % On Charter
- 90-100%: Sesión muy enfocada. El área era bien entendida.
- 60-80%: Normal. Algo de tiempo siguiendo pistas inesperadas.
- Bajo 50%: El área tiene muchos issues o el charter era demasiado amplio.
SBTM en la Práctica
Reportando a Stakeholders
“Este sprint completamos 5 sesiones exploratorias cubriendo pagos, búsqueda y mobile. Tiempo total: 6.5 horas. Encontrados 8 bugs (2 altos, 4 medios, 2 bajos). Cobertura: 3 de 5 áreas completadas. Riesgo: timeouts de pago e integraciones de terceros sin probar.”
SBTM vs. Otros Enfoques
| Enfoque | Estructura | Trazabilidad | Mejor Para |
|---|---|---|---|
| Testing ad hoc | Ninguna | Ninguna | Verificaciones rápidas |
| Testing exploratorio | Solo charter | Baja | Investigación individual |
| SBTM | Charter + time-box + debrief + métricas | Alta | Gestión de testing en equipo |
| Testing con scripts | Test cases completos | Muy alta | Regresión, compliance |
Ejercicio: Conduce una Sesión SBTM
Parte 1: Eres el lead de testing para una aplicación de gestión de proyectos. Planifica 3 sesiones SBTM definiendo: charter, tester asignado, duración, prioridad y riesgo.
Parte 2: Elige un charter y simula la sesión. Llena una hoja de sesión completa con: al menos 10 observaciones, al menos 2 bugs, al menos 2 preguntas, % on charter y áreas no cubiertas.
Parte 3: Escribe el resumen del debrief cubriendo: hallazgos clave, charter recomendado para la próxima sesión y evaluación de riesgo.
Pista
Para la Parte 1, piensa en los aspectos más riesgosos de un tablero de tareas: drag-and-drop, persistencia de datos, ediciones concurrentes, interacciones táctiles móviles y actualizaciones en tiempo real.Solución
Parte 1: Plan de Sesiones
Sesión 1 (Alta prioridad):
- Charter: Explorar el drag-and-drop de tareas entre columnas con movimientos rápidos, multi-selección y ediciones simultáneas para descubrir pérdida de datos, estado incorrecto y race conditions.
- Tester: Jane, Duración: 90 min, Riesgo: Integridad de datos
Sesión 2 (Alta prioridad):
- Charter: Explorar actualizaciones en tiempo real con dos navegadores en el mismo tablero para descubrir fallas de sincronización y datos obsoletos.
- Tester: Mike, Duración: 90 min, Riesgo: Consistencia entre clientes
Sesión 3 (Media prioridad):
- Charter: Explorar el tablero en móviles con gestos táctiles y rotación para descubrir problemas de targets táctiles y layout responsivo.
- Tester: Ana, Duración: 60 min, Riesgo: Usabilidad móvil
Parte 2: Hoja de Sesión (Sesión 1)
Charter: Drag-and-drop de tareas entre columnas
Tester: Jane Smith
Duración: 90 min (plan) / 88 min (real)
NOTAS:
1. Drag simple de "Por hacer" a "En progreso" — funciona
2. Reordenar en misma columna — correcto, persiste en refresh
3. Drag rápido secuencial: segundo drag falla silenciosamente
4. Multi-selección pierde orden relativo
5. Drag mientras otro usuario edita: la edición se pierde
6. Drag a columna eliminada: tarea desaparece sin error
7. Undo funciona una vez, doble-undo no restaura
8. Drag de 50 tareas: UI se congela 3 segundos
9. Título largo desborda durante el drag
10. Drag con latencia: tarea vuelve sin feedback
BUGS:
1. BUG-501 (Crítico): Tarea desaparece al arrastrar a columna eliminada
2. BUG-502 (Alto): Race condition edición + drag causa pérdida de datos
% EN CHARTER: 80%
ÁREAS NO CUBIERTAS: Drag con teclado (accesibilidad), entre tableros
Parte 3: Resumen del Debrief
“La sesión de drag-and-drop reveló un bug crítico de pérdida de datos: cuando una tarea se arrastra a una columna eliminada simultáneamente, desaparece sin error ni opción de recuperación. El drag-and-drop individual funciona bien, pero los escenarios multi-usuario tienen riesgos significativos de integridad. Recomendación: explorar operaciones de eliminación y resolución de conflictos en la próxima sesión. El feature no está listo para producción con BUG-501 abierto.”
Puntos Clave
- SBTM hace al testing exploratorio trazable dividiéndolo en sesiones gestionadas
- Las hojas de sesión documentan qué se probó, qué se encontró y qué queda pendiente
- El debrief es la reunión más importante — transfiere conocimiento y forma la próxima sesión
- Las métricas (sesiones completadas, bugs por sesión, % on charter) permiten reportar a stakeholders
- SBTM ocupa el punto óptimo entre la flexibilidad de la exploración y la trazabilidad del testing con scripts
- Planifica sesiones basándote en riesgo — las áreas de alto riesgo primero