Hola mi amigo y amiga de la calidad y colegas del mundo del desarrollo. Hoy quiero compartir algo contigo que veo que es una idea que también veo bastante repetida en equipos, incluso en personas con experiencia, y es esta: que las pruebas exploratorias solo tienen sentido cuando hay una interfaz gráfica que tocar.
Y lo entiendo. Es fácil planificar la exploración cuando tienes botones, formularios y pantallas. Puedes ver lo que pasa, interactuar directamente y cambiar cosas con relativa facilidad. Pero cuando hablamos de APIs, servicios, funciones o procesos batch, muchas personas sienten que ya no hay mucho que “explorar”.
Y esto tiene sentido pero cuando piensas que no puedes explorar un sistema sin UI, lo más probable es que estés dejando pasar una cantidad importante de riesgos.
¿Por qué asociamos tanto la exploración con interfaces gráficas?
Creo que tiene que ver con cómo muchas personas aprendieron testing. La exploración se suele enseñar con ejemplos visuales: una web, una app móvil, un formulario. Entonces se crea una asociación automática entre “explorar” y “hacer clic”.
Pero en realidad, lo que hace poderosa a la exploración no es la interfaz.
Es la forma de pensar.
Explorar no se trata de mover botones. Se trata de entender un sistema a partir de cómo responde cuando cambias cosas. Y eso aplica exactamente igual, tengas o no una pantalla.
Entonces, ¿cómo exploras algo que no puedes “ver”?
Aquí es donde cambia un poco el enfoque.
Cuando no hay UI, la exploración deja de ser visual y se vuelve más analítica. Empiezas a pensar en términos de entradas, salidas y comportamiento. Por ejemplo, imagina que estás probando una API, no tienes botones, pero sí tienes requests y responses. Entonces puedes empezar a preguntarte:
- ¿Qué pasa si envío datos vacíos?
- ¿Qué ocurre si los datos son demasiado largos?
- ¿Qué pasa si uso caracteres especiales o encoding distinto?
- ¿Qué sucede si envío uno, cero o muchos elementos?
Fíjate que la lógica es la misma que usarías en una interfaz. Lo único que cambia es el medio.
Recuerdo una conversación que tuve con un desarrollador que trabajaba en una función para comparar textos. Él estaba convencido de que el testing exploratorio no aplicaba en su caso, porque no había interfaz, solo código.
Cuando empezamos a revisar la función, lo primero que hicimos fue identificar qué podíamos variar. En este caso, eran dos strings. Entonces empezaron a aparecer preguntas interesantes:
- ¿Qué pasa si ambos strings son iguales?
- ¿Qué pasa si son completamente distintos?
- ¿Qué ocurre si están vacíos?
- ¿Y si son extremadamente largos?
- ¿Y si contienen caracteres especiales o idiomas diferentes?
A partir de ahí empezaron a surgir cosas que no eran tan evidentes. Por ejemplo, con textos muy largos el rendimiento caía bastante. No era un bug funcional, pero sí un problema importante si esa función se iba a usar en escenarios reales.
Y eso no lo hubiéramos encontrado ejecutando un par de casos “bonitos”. Lo mismo aplica cuando trabajas con servicios o integraciones. Muchas veces creemos que si la respuesta es 200 OK, todo está bien. Pero explorar un servicio implica ir mucho más allá de eso.
Puedes cuestionarte cosas como:
- ¿Qué pasa si el XML o JSON está mal formado?
- ¿Qué ocurre si envío valores que no existen en el dominio?
- ¿El sistema diferencia entre mayúsculas y minúsculas?
- ¿Cómo responde ante caracteres especiales?
- ¿Qué pasa si envío múltiples filtros o ninguno?
Cada una de esas variaciones te da información. Y esa información te permite entender mejor cómo se comporta realmente el sistema, no solo cómo debería comportarse en el escenario ideal.
Y aquí hay algo importante que quiero que te lleves. Siempre que exista una interfaz, hay posibilidad de explorar, y ojo, cuando digo interfaz, no me refiero solo a algo visual. Una API es una interfaz. Un servicio es una interfaz. Incluso una función es una interfaz entre partes del sistema.
Tal vez no está pensada para humanos, pero sigue siendo una forma de interacción. Y donde hay interacción, hay comportamiento. Y donde hay comportamiento, hay cosas que pueden salir mal.
Entonces, ¿qué cambia realmente cuando no hay UI?
No cambia la esencia de la exploración. Cambia la forma en que observas, pues en lugar de ver pantallas, analizas respuestas, construyes requests, interpretas datos. Pero el pensamiento es el mismo: variar, observar, aprender. Y ¿Por qué esto es tan importante hoy? Porque cada vez más sistemas dependen de integraciones. APIs, microservicios, procesamiento de datos, pipelines… muchas veces lo crítico no está en la interfaz que ve el usuario, sino en lo que pasa detrás.
Y si tu estrategia de testing se queda solo en lo visual, estás cubriendo solo una parte del problema.
Mi recomendación para ti
La próxima vez que te enfrentes a algo sin interfaz, no pienses que no puedes explorar. Cambia la forma en que haces las preguntas.
En lugar de “¿dónde hago clic?”, pregúntate:
- ¿Qué puedo variar aquí?
- ¿Qué comportamiento espero y cuál me sorprendería?
- ¿Qué pasaría si rompo las reglas?
Empieza pequeño. Un request, una función, un flujo simple. Observa lo que ocurre y deja que el sistema te guíe hacia nuevas preguntas. Porque al final, explorar no depende de tener una pantalla, depende de tu capacidad de cuestionar.
Recurso práctico
Mini guía para explorar sistemas sin interfaz
- Define qué estás explorando Ejemplo: endpoint de creación de usuarios.
- Identifica entradas y salidas ¿Qué datos recibe? ¿Qué devuelve?
- Piensa en variaciones Vacíos, extremos, inválidos, combinaciones, encoding.
- Observa respuestas Códigos, tiempos, errores, consistencia.
- Profundiza ¿Esto merece un bug, un test case o una conversación?
