exploratory-testing

---
name: exploratory-testing
description: "Usar para testing exploratorio con sesiones documentadas. También: probar sin script, buscar bugs, testing manual, edge cases, sesión de testing."
---

# Testing exploratorio

## Resumen

Este skill ejecuta sesiones de testing exploratorio estructurado. A diferencia de los tests automatizados que verifican comportamientos conocidos, el testing exploratorio busca descubrir comportamientos inesperados que nadie pensó en probar. Es el complemento humano imprescindible a la suite automatizada.

Cada sesión tiene un objetivo concreto, un tiempo limitado y produce documentación de lo encontrado. No es "probar cosas al azar" sino una exploración guiada por heurísticas.

## Proceso

1. **Definir el objetivo de la sesión.** Cada sesión se centra en un área o aspecto:

   - "Explorar el flujo de registro buscando estados inconsistentes."
   - "Probar la API de pagos con datos inválidos."
   - "Verificar el comportamiento bajo carga simulada."

   Un objetivo demasiado amplio ("probar todo") no es un objetivo.

2. **Establecer tiempo limitado.** Las sesiones duran 25 minutos (un pomodoro). El límite de tiempo obliga a centrarse y evita la fatiga que reduce la efectividad. Si se necesita más tiempo, iniciar una nueva sesión con objetivo refinado.

3. **Aplicar heurísticas de exploración.** Estas heurísticas guían la búsqueda de problemas:

   - **Límites:** valores en los extremos de lo permitido (0, 1, máximo, máximo+1).
   - **Estados:** qué pasa al cambiar de estado rápidamente (crear y eliminar inmediatamente, editar mientras otro usuario edita).
   - **Flujos alternativos:** seguir caminos que no son el happy path (cancelar a mitad, volver atrás, refrescar la página).
   - **Datos inválidos:** inyectar datos que no se esperan (HTML, SQL, unicode exótico, strings vacíos, valores negativos).
   - **Interrupciones:** qué pasa si la conexión se corta a mitad de una operación, si el navegador se cierra, si se agota el timeout.
   - **Concurrencia:** dos usuarios haciendo lo mismo a la vez, requests duplicadas, doble click.
   - **Rendimiento:** operaciones con volumen grande de datos, búsquedas con resultados masivos.

4. **Documentar en tiempo real.** Durante la sesión, registrar:

   - Qué se probó (acción concreta).
   - Qué se esperaba que pasase.
   - Qué pasó realmente.
   - Si es un bug, un comportamiento confuso o un área sin cobertura.

5. **Clasificar los hallazgos:**

   - **Bug:** comportamiento incorrecto que debe corregirse.
   - **UX issue:** funciona pero confunde al usuario.
   - **Falta de cobertura:** área sin tests automatizados que debería tenerlos.
   - **Duda:** comportamiento que no se sabe si es correcto sin consultar el requisito.

6. **Documentar lo que NO se probó.** Tan importante como lo probado es lo que quedó fuera. Esto alimenta futuras sesiones.

7. **Generar informe de sesión.** Resumen con: objetivo, duración, hallazgos clasificados, áreas no cubiertas, próximos pasos sugeridos.

## Criterios de éxito

- La sesión tenía un objetivo concreto y un tiempo limitado.
- Se aplicaron al menos 3 heurísticas de exploración distintas.
- Los hallazgos están documentados con: acción, resultado esperado y resultado real.
- Los hallazgos están clasificados (bug, UX, cobertura, duda).
- Se han documentado las áreas que no se pudieron cubrir.