exploratory-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.