Hola mi amigo y amiga de la calidad. Te doy la bienvenida a tu blog del dia lunes.
Hoy quiero hablarte de algo que, si te soy honesto no entendia completamente cuando comencé mi carrera y es algo que veo que sigue pasando muchísimo en equipos: QAs probando sin entender realmente el producto.
Durante mucho tiempo pensé que hacer bien mi trabajo era:
- Tener mis test cases listos
- Ejecutarlos correctamente
- Reportar bugs claros
Y listo… misión cumplida. Pero aparte de sentir que era un trabajo bastante monotomo y bastante limitado me daba cuenta que a pesar de mis esfuerzos, aun así el producto fallaba en producción, y generalmentre el problema era el “tester”. En algun momento pense que quizas era el momento de pensar en regresar a la programación.
El momento incómodo que te hace crecer
Recuerdo una vez (y esto seguro te ha pasado también):
Habíamos probado todo, los flujos funcionaban, los casos estaban cubiertos, no había bugs críticos…
y cuando salió a producción… Los usuarios simplemente no lo usaban como esperábamos.
Eso me dio a entender que en ese punto no entendíamos cómo el usuario realmente iba a usar el producto. Y luego de mucha lectura y aprendizaje entendi que la percepción de calidad, recaia en gran medida sobre los usuarios y por ello era importante entender el producto, es decir, no puedes probar bien algo que no entiendes.
Lo interesante de Google (y por qué esto conecta contigo)
En el libro How Google Tests Software, hay muchas ideas que suenan innovadoras, incluso avanzadas.
Pero hay algo que me gusta muchísimo, porque no se enfocan en el proceso, se enfocan en el valor. Y esto es clave para el QA moderno, porque hoy ya no basta con saber herramientas o escribir casos de prueba, hoy necesitas entender:
- El negocio
- El usuario
- El contexto en el que se usa el producto
Porque ahí es donde realmente está el riesgo.
Una forma simple (pero poderosa) de entender mejor lo que pruebas
Google propone algo que, cuando lo lees, parece simple… pero cambia todo, y es lo siguiente dividir el entendimiento del producto en tres niveles. Te lo voy a explicar con mas detalle a continuación:
1. Atributos → ¿Qué tan bueno es esto?
Son las cualidades del sistema.
- ¿Es rápido?
- ¿Es seguro?
- ¿Es fácil de usar?
- ¿Es confiable?
Esto conecta directamente con lo que el usuario percibe. Y aquí es donde muchas veces fallamos sin darnos cuenta. Porque algo puede “funcionar”, pero tambien puede ser lento, confuso o frustrante. Y eso también bajo la perspectiva de los usurios es un error.
2. Componentes → ¿De qué está hecho?
Son las piezas del sistema.
- Login
- Carrito de compras
- API de pagos
- Base de datos
Esto es lo que normalmente probamos. Aquí es donde los testers suelen sentirse más cómodos, porque es tangible, es técnico, es “testeable”.
3. Capacidades → ¿Qué puede hacer el usuario?
Aquí es donde quizás aunque sabemos que sera la parte mas valiosa, es donde gfallamos en entender la fotografia completa. Por ejemplo:
- Registrarse
- Comprar
- Compartir contenido
- Recuperar contraseña
Esto es el producto real, lo que el usuario viene a hacer, y si esto falla, todo lo demás que hayas hecho no importa.
El problema real: probamos piezas, no experiencias
Aquí viene la parte incómoda. muchos testers trabajan en:
- Validar endpoints
- Revisar formularios
- Ejecutar casos por componente
Pero muy pocos se preguntan: ¿El usuario realmente puede lograr lo que vino a hacer? Y esa es la diferencia entre hacer pruebas funcionalidades y probar valor.
Entonces… ¿qué significa entender el producto?
No es leer un documento, saberte los flujos de memoria. Es algo mucho más profundo, y es poder explicar por qué este producto existe. Si tú no puedes responder fácilmente:
- ¿Qué problema resuelve esto?
- ¿Para quién está hecho?
- ¿Qué pasaría si esto falla?
Entonces todavía no estás listo para probarlo bien.
Y no pasa nada, lo que si pasa es si te sientes comodo si te quedas ahí, y no intentas entenderlo mejor.
Un ejercicio simple que te puede cambiar el juego
La próxima vez que entres a probar algo, haz esto:
Antes de abrir Postman, antes de correr un test, antes de ejecutar nada…
pregúntate:
- ¿Qué atributos son críticos aquí? (velocidad, seguridad, UX…)
- ¿Qué componentes están involucrados?
- ¿Qué capacidad del usuario estoy validando realmente?
Si no puedes responder esto, date un tiempo para buscar las respuestas porque probablemente comiences a probar a ciegas.
Cierro con algo que quiero que te lleves
El QA que más crece no es el que más herramientas sabe. Es el que mejor entiende lo que está probando.
Nosotros no solo estamos probamos código, sino experiencias y decisiones de negocio. Al tener en cuenta esto te aseguro que vas a cambiar la forma en la que haces tu trabajo.
En los próximos blogs de esta serie quiero profundizar contigo en estos temas:
- Cómo pensar en riesgos de verdad
- Por qué los test cases no son suficientes
- Cómo usar exploración de forma estructurada
- Y cómo convertirte en un QA que realmente aporta valor
Todo inspirado en ideas como estas… pero aterrizadas a la realidad que tú y yo vivimos en los proyectos.
Y ahora quiero escuchar tu opinión al respecto. Te leo.
