TL;DR

  • Estructura los reportes con charter, notas con timestamps, evidencia de bugs (capturas/grabaciones) y acciones de seguimiento
  • Usa sesiones timeboxed de 90 minutos (metodología SBTM): 70 min exploración + 15 min documentación
  • Convierte los hallazgos en tickets accionables de inmediato — los insights no documentados se pierden

Ideal para: Ingenieros QA que realizan sesiones exploratorias y necesitan un framework de documentación repetible Omite si: Solo ejecutas pruebas con scripts sin práctica de testing exploratorio

Las pruebas exploratorias generan entre el 30 y el 40% de todos los defectos críticos encontrados en proyectos de software, según el informe State of Software Quality de SmartBear. Sin embargo, la mayoría de los equipos pierde el 60% del valor de estas sesiones porque los hallazgos no se documentan y los conocimientos permanecen en las cabezas de los testers. Los informes de sesiones exploratorias efectivos transforman la investigación ad-hoc en conocimiento estructurado. Un informe bien escrito captura el charter de prueba, observaciones con timestamps, bugs con pasos de reproducción y capturas de pantalla, áreas de cobertura y acciones de seguimiento. La metodología Session-Based Test Management (SBTM) de James Bach establece el estándar de oro: sesiones de 90 minutos con timebox, notas de debriefing estructuradas y métricas de cobertura explícitas. Los equipos que usan SBTM reportan un 45% mejor trazabilidad de errores.

Componentes Clave de Reportes de Sesión

estructura_reporte_sesion:
  metadatos_sesion:

    - id_sesion
    - nombre_tester
    - fecha_y_hora
    - duracion
    - charter_mision
    - version_build
    - entorno

  notas_exploracion:

    - areas_exploradas
    - tecnicas_prueba_usadas
    - datos_usados
    - observaciones
    - proceso_pensamiento

  hallazgos:

    - bugs_descubiertos
    - riesgos_identificados
    - preguntas_planteadas
    - ideas_generadas

  evidencia:

    - capturas_pantalla
    - grabaciones
    - archivos_log
    - trazas_red

  resultados:

    - acciones_seguimiento
    - recomendaciones
    - areas_prueba_profunda
    - gaps_documentacion

Charter de Sesión y Time Boxing

Creando Charters Efectivos

# Plantilla de Charter de Prueba Exploratoria

## Charter ID: EXP-2025-042
**Creado**: 2025-10-10
**Tester**: Maria Garcia
**Duración**: 90 minutos

### Misión
Explorar el proceso de checkout para casos edge y manejo de errores, enfocándose particularmente en integración de gateway de pago y flujos de confirmación de pedido.

### Alcance
**En Alcance:**

- Métodos de pago: Tarjeta de crédito, PayPal, Apple Pay
- Escenarios de error: tarjetas rechazadas, timeouts de red, datos inválidos
- Confirmación de pedido: email, SMS, notificaciones in-app

**Fuera de Alcance:**

- Validación de dirección de envío (cubierto en EXP-2025-038)
- Catálogo de productos (charter separado)
- Gestión de cuenta de usuario

### Áreas a Explorar
1. Respuestas del gateway de pago a varias condiciones de error
2. Gestión de estado durante procesamiento de pago
3. Consistencia de datos de pedido entre servicios
4. Mecanismos de feedback al usuario para fallos
5. Casos edge en aplicación de código de descuento

### Técnicas de Prueba
- Análisis de valores límite en montos de pago
- Pruebas de transición de estado para flujo de checkout
- Error guessing para fallos de pago
- Pruebas de interrupción (caídas de red, cierre de navegador)

Notas de Sesión y Proceso de Pensamiento

Toma de Notas Estructurada

# Notas de Sesión Exploratoria

## Sesión: EXP-2025-042
**Fecha**: 2025-10-10, 14:00-15:30
**Tester**: Maria Garcia
**Build**: v2.5.3-staging

---

### Tiempo: 14:05 - Exploración Inicial

**Observación 1**: Flujo de checkout estándar funciona como esperado
- Agregué artículo al carrito: Producto #123
- Procedí a checkout
- Ingresé info de envío: Todos los campos validados correctamente

---

### Tiempo: 14:15 - Pruebas de Método de Pago

**Prueba**: Tarjeta de crédito expirada
- Ingresé tarjeta: 4111111111111111, Exp: 01/2020
- Resultado: ❌ **BUG ENCONTRADO** - Sistema aceptó tarjeta expirada
- Esperado: Error de validación antes de envío
- Actual: Aceptado y enviado a gateway de pago, que lo rechazó
- Impacto: UX pobre, llamada API desperdiciada
- Screenshot: `bug_001_tarjeta_expirada.png`
- *Ticket Creado: BUG-4532*

**Prueba**: Interrupción de red durante pago
- Pasos:
  1. Inicié pago con tarjeta válida
  2. Deshabilitéred (modo offline Chrome DevTools)
  3. Observé comportamiento
- Resultado: ⚠️ **PROBLEMA** - Spinner continúa indefinidamente, sin timeout
- Esperado: Timeout después de 30s con mensaje de error
- Actual: Carga infinita, usuario debe refrescar página
- Riesgo: Confusión del usuario, potenciales pedidos duplicados si refresca
- *Ticket Creado: BUG-4533*

---

### Tiempo: 14:30 - Montos de Caso Edge

**Prueba**: Pedido de cero dólares (con código de descuento 100%)
- Apliqué código de descuento: TESTFREE100
- Total: $0.00
- Resultado: ❌ **BUG ENCONTRADO** - Paso de pago aún requerido
- Esperado: Saltar pago, proceder a confirmación
- Actual: Formulario de pago mostrado, UX confuso
- *Ticket Creado: BUG-4534*

---

### Tiempo: 14:45 - Pruebas de Consistencia de Estado

**Prueba**: Botón atrás del navegador durante procesamiento de pago
- Resultado: ❌ **BUG MAYOR** - Pedido creado dos veces
- Detalles:
  - Pago procesado exitosamente
  - Botón atrás retornó al formulario de checkout
  - Formulario aún habilitado, permitió segundo envío
  - Dos pedidos creados con mismos artículos
  - Dos cargos a tarjeta de crédito
- Severidad: Alta - Impacto financiero
- *Ticket Creado: BUG-4535 (Prioridad: P0)*

---

### Tiempo: 15:15 - Cierre de Sesión

**Áreas Exploradas**:
✅ Validación de método de pago
✅ Manejo de fallos de red
✅ Montos de casos edge
✅ Consistencia de estado (botón atrás, refresh)
✅ Flujo de notificación de pedido

**Técnicas Usadas**:

- Análisis de valores límite (montos)
- Pruebas de transición de estado (flujo checkout)
- Error guessing (fallos de red)
- Pruebas de interrupción (atrás navegador, caída red)

**Métricas**:

- Duración sesión: 90 minutos
- Bugs encontrados: 4
- Preguntas planteadas: 2
- Ideas generadas: 3
- Screenshots capturados: 12

Documentación de Hallazgos

Reporte de Bug desde Sesión Exploratoria

# BUG-4535: Creación de Pedido Duplicado vía Botón Atrás del Navegador

**Descubierto en**: Sesión Exploratoria EXP-2025-042
**Reporter**: Maria Garcia
**Fecha**: 2025-10-10
**Severidad**: Alta (P0)

## Resumen
Usar botón atrás del navegador durante procesamiento de pago permite creación de pedido duplicado y doble cargo.

## Pasos para Reproducir
1. Agregar artículos al carrito
2. Proceder a checkout
3. Ingresar información de envío y pago
4. Click en botón "Pagar Ahora"
5. Mientras el pago está procesando (spinner visible)
6. Click en botón atrás del navegador
7. Observar que formulario de checkout sigue activo
8. Click en "Pagar Ahora" nuevamente

## Resultado Esperado
- Botón atrás debe prevenirse durante procesamiento de pago, O
- Formulario debe deshabilitarse después del primer envío, O
- Verificación de pedido duplicado debe prevenir segundo pedido

## Resultado Actual
- Botón atrás funciona durante procesamiento
- Formulario de checkout permanece habilitado
- Segundo click crea pedido duplicado
- Tarjeta de crédito cargada dos veces

## Evidencia
- Screenshots: `bug_003_pedido_duplicado_1.png`, `bug_003_pedido_duplicado_2.png`
- Grabación de pantalla: `bug_003_reproduccion.mp4`
- Logs de red: `bug_003_network_har.har`

## Impacto
- **Negocio**: Responsabilidad financiera, quejas de clientes, costos de reembolso
- **Usuario**: Cargado dos veces, confusión, mala experiencia

## Corrección Sugerida
1. Implementar clave de idempotencia para creación de pedido
2. Deshabilitar formulario y botón atrás durante procesamiento
3. Agregar detección de pedido duplicado

Gestión de Evidencia

Organización de Screenshots

convencion_nombres_screenshot:
  patron: "{id_sesion}_{tipo}_{secuencia}_{descripcion}.png"
  ejemplos:

    - "EXP-2025-042_bug_001_tarjeta_expirada_aceptada.png"
    - "EXP-2025-042_observacion_002_monto_maximo_pedido.png"

estructura_almacenamiento:
  sesiones_exploratorias/
    2025-10-10_EXP-042/
      screenshots/
        001_tarjeta_expirada_aceptada.png
        002_timeout_red.png
      grabaciones/
        sesion_completa.mp4
      logs/
        consola_navegador.log
      reporte_sesion.md

Acciones de Seguimiento

Plantilla de Ítems de Acción

# Acciones de Seguimiento de EXP-2025-042

## Acciones Inmediatas (Este Sprint)

### 1. Correcciones de Bugs Críticos
- [ ] **BUG-4535**: Corregir creación de pedido duplicado
  - Asignado a: Dev Team Lead
  - Prioridad: P0
  - Estimado: 8 horas

- [ ] **BUG-4532**: Agregar validación de tarjeta expirada
  - Asignado a: Frontend Team
  - Prioridad: P1
  - Estimado: 3 horas

### 2. Exploración Adicional Necesaria
- [ ] **EXP-2025-043**: Explorar casos edge de integración PayPal
  - Asignado a: Maria Garcia
  - Duración: 90 minutos

### 3. Decisiones de Producto Requeridas
- [ ] **QUESTION-892**: Definir regla de negocio para valor máximo de pedido
  - Asignado a: Product Owner

### 4. Mejoras Técnicas
- [ ] Agregar claves de idempotencia a API de pedidos
- [ ] Implementar bloqueo de sesión durante checkout
- [ ] Agregar triggers de detección de fraude

Métricas de Sesión

Tablero de Pruebas Exploratorias

MétricaSesión EXP-042Promedio EquipoObjetivo
Duración90 min75 min60-90 min
Bugs Encontrados42.32+
Bugs Alta Severidad10.4Cualquiera
Preguntas Planteadas21.11+
Ideas Generadas31.82+
Screenshots128.25+
Acciones Seguimiento84.53+

Conclusión

Los Reportes Efectivos de Sesión de Pruebas Exploratorias transforman el descubrimiento espontáneo en aprendizaje y mejora sistemáticos. Al documentar charters, capturar notas detalladas, preservar evidencia y crear seguimientos accionables, las pruebas exploratorias se convierten en un complemento poderoso a las pruebas con script.

Recuerda: El valor de las pruebas exploratorias no está solo en encontrar bugs, sino en entender el producto profundamente, cuestionar supuestos y descubrir riesgos que las pruebas con script pierden. Documenta exhaustivamente para preservar y compartir ese valor.

Ver También

Recursos Oficiales

“Un informe de sesión que toma cinco minutos en escribir puede ahorrar cinco horas de reinvestigación. El mejor informe de bug es aquel que contiene suficiente contexto para que otro tester pueda reproducir el fallo sin necesidad de hablar contigo.” — Yuri Kan, Senior QA Lead

FAQ

¿Qué incluir en un informe de sesión exploratoria?

Metadatos de sesión, notas con timestamps, bugs con capturas y pasos de reproducción, áreas de cobertura y acciones de seguimiento con responsables y plazos.

¿Cuánto debe durar una sesión exploratoria?

90 minutos según SBTM. Sesiones de 45 minutos para charters enfocados. Evita sesiones de más de 2 horas: la concentración cae significativamente.

¿Qué es un charter de pruebas?

Una declaración de misión que define qué explorar. Formato: “Explorar [área] usando [técnica] para descubrir [información]”. Estructura sin prescribir pasos.

¿Cómo documentar bugs en sesiones exploratorias?

Documenta inmediatamente con capturas y pasos exactos. Vincula cada bug al charter de sesión para trazabilidad.