Hola bonita comunidad, leyendo el libro “Thinking Fast and Slow” de Daniel Kahneman, noté que el capitulo que habla sobre la forma en la que evaluamos alguna información me di cuenta que hay un sesgo que, sin darme cuenta, puede afectar seriamente cómo estoy probando el software: el Halo Effect o efecto halo.
Este fenómeno psicológico es más común de lo que imaginamos, y si bien suele mencionarse en contextos como entrevistas de trabajo o primeras impresiones personales, también se manifiesta en nuestro día a día como testers, sobre todo durante pruebas manuales o chequeos visuales.
Hoy quiero contarte cómo lo he identificado en mis sesiones de testing y qué estrategias me han ayudado a reducir su impacto.
¿Qué es el Halo Effect?
El Halo Effect es un sesgo cognitivo que ocurre cuando nuestra impresión positiva o negativa sobre un aspecto de algo o alguien influye injustificadamente en nuestra percepción del resto.
Por ejemplo:
- Si alguien llega muy bien vestido a una entrevista, podrías asumir que también es inteligente y organizado, sin ninguna evidencia objetiva de eso.
- Si un desarrollador explica muy bien su computrabajo y es muy bueno impresionando con su conocimiento del negocio, podrías creer automáticamente que también está bien implementado por dentro.
¿Y en el testing? Aquí empieza lo interesante…
Cómo se manifiesta en el testing
En las pruebas manuales —especialmente durante sesiones exploratorias o validaciones visuales— me he sorprendido varias veces “suavizando” mi criterio sin querer.
A veces pasa esto:
👁️ Veo una interfaz limpia, bien alineada, intuitiva… y doy por hecho que todo lo demás también estará bien hecho, y me vuelvo mucho menos objetivo con el resto de las pruebas.
Entonces me relajo, dejo de ser tan riguroso, y hasta podría omitir escenarios que normalmente verificaría.
O al revés:
🐞 Encuentro un bug muy evidente apenas empiezo, y ya todo lo que sigue me parece mal.
Empiezo a buscar errores en cada esquina, a asumir que está todo roto, incluso donde no lo está.
Este sesgo afecta tanto la objetividad como la cobertura. Porque en lugar de validar con un criterio claro, me dejo influenciar por la impresión inicial.
¿Cuales son los escenarios posibles donde en mi experiencia aplico este sesgo?
✅ En los módulos favoritos
“Este siempre funciona, ni lo reviso mucho”.
✅ Con los Devs en quienes confio
“Si esto lo hizo el Dev A, seguro está perfecto”.
✅ Con los componentes visualmente atractivos
“Esto se ve tan bien que seguro ya está bien validado”.
Todo esto lleva a omisiones, errores que se escapan, o sesgos de confirmación donde terminamos viendo solo lo que esperábamos ver.
¿Cómo combatir el Halo Effect en nuestras pruebas?
No es sencillo eliminar un sesgo cognitivo, pero sí se puede reducir su impacto con consciencia y estructura. Aquí te dejo algunas estrategias que me han ayudado:
🧭 1. Prueba con intención, no con intuición
Antes de comenzar una sesión, define claramente lo que vas a validar. No confíes en que “todo se ve bien”. Lo visual no garantiza lógica, rendimiento ni flujos alternativos bien implementados.
🔁 2. Cambia el orden de los chequeos
Si siempre empiezas por la misma pantalla o flujo, tu cerebro se acomoda y asume resultados. Cambiar el orden te obliga a observar con otra mirada.
📋 3. Usa checklists o heurísticas
Tener una lista de aspectos a revisar, aunque sea breve, te protege de pasar por alto detalles solo porque “todo luce bien”. Puedes usar heurísticas como las de NIelsen, hacer una matriz de pruebas o adaptar una checklist propia.
🧪 4. Automatiza datos y pasos repetitivos
Cuando tienes herramientas que eliminan la carga mental de generar datos o repetir pasos, te liberas para observar con mayor enfoque y evitar caer en la rutina del “esto ya lo vi antes”.
⏸️ 5. Toma pausas y revisa en bloques
Cuando llevas mucho tiempo seguido validando, tu cerebro tiende a automatizar la evaluación. Tomar pausas o dividir la validación en sesiones más pequeñas mejora la atención al detalle. Puedes usar la tecnica Pomodoro
👥 6. Haz pruebas en pareja o en rotación
Compartir la sesión con otra persona o hacer revisiones cruzadas con otro QA te puede mostrar ángulos que tú no viste por estar sesgado desde el inicio. Casi siempre tiendo a conversar con otras personas del equipo o con diferentes roles y los veo utilizar las funcionalidades¡Claro! Aquí tienes los puntos clave del documento, en tono informal:
🧠 ¡El Efecto Halo también te engaña en las pruebas!
- ¿Has oído hablar del Efecto Halo? Es cuando algo te parece bien (o mal) en un aspecto y asumes que todo lo demás también lo está, sin pruebas.
- No solo pasa en entrevistas o primeras citas, ¡también se nos cuela a los testers! Especialmente en pruebas manuales o visuales.
¿Qué onda con el Efecto Halo en el testing?
- Si ves una interfaz súper bonita y bien organizada, ¡cuidado! Puedes relajarte y pensar que todo lo de adentro está perfecto, y hasta te saltas pruebas importantes.
- O al revés: encuentras un bug feo al principio y de repente, ¡todo te parece roto! Empiezas a buscar errores por todos lados, incluso donde no los hay.
- Esto nos quita objetividad y hace que probemos menos de lo que deberíamos.
¿Dónde me ha pasado a mí?
- Con mis módulos favoritos: “Este siempre funciona, ni lo reviso mucho”. ¡Error!
- Con los devs en quienes confío: “Si lo hizo X, seguro está genial”. ¡No siempre!
- Con cosas que se ven súper bien: “Esto es tan bonito que ya debe estar validado”. ¡Ojo!
- Todo esto nos lleva a que se nos pasen bugs o que solo veamos lo que queremos ver.
¿Cómo le hacemos frente a este rollo?
- Prueba con cabeza, no con corazonadas: Antes de empezar, ten claro qué vas a revisar. Que algo se vea bien no significa que funcione bien por dentro.
- Cambia el orden: Si siempre empiezas por lo mismo, tu cerebro se acostumbra. Varía el orden para ver las cosas con otros ojos.
- Usa listas: Un checklist, aunque sea pequeño, te ayuda a no olvidar detalles solo porque “todo luce bien”.
- Automatiza lo aburrido: Si las herramientas hacen el trabajo repetitivo, tú puedes enfocarte mejor y no caer en la rutina.
- Toma tus pausas: Si pruebas mucho tiempo seguido, te cansas y se te escapan cosas. Date un respiro o divide las sesiones. La técnica Pomodoro puede ayudar.
- Prueba con alguien más: Otra cabeza siempre ayuda. Prueba en pareja o pídele a otro QA que revise. Así ven cosas que a ti se te pasaron.
Para cerrar…
- El Efecto Halo no es que seamos malos, ¡es cómo funciona nuestro cerebro para ir más rápido!
- Pero en testing, esa rapidez puede costarnos cara.
- Saber que existe ya es un gran paso.
- Podemos crear formas de ser más objetivos y justos con el software y con el equipo que lo crea.
¿Y a ti? ¿Te ha pasado algo parecido? ¡Cuéntanos si alguna vez confiaste demasiado en que algo “se veía bien” o en el trabajo de un dev! Seguro muchos se sentirán identificados.
Una reflexión final
El efecto halo no es culpa de nadie. Es parte de cómo funciona nuestro cerebro para ahorrar energía y tomar decisiones rápidas. Pero en testing, esa rapidez puede salirnos cara.
Ser consciente de que este sesgo existe ya es un primer paso para contrarrestarlo.
No siempre lo vamos a detectar a tiempo, pero sí podemos construir estructuras que nos permitan ser más objetivos, más rigurosos y —sobre todo— más justos con el software que probamos y con los equipos que lo construyen.
¿Y tú? ¿Has notado que el Halo Effect afecta tus pruebas?
Me encantaría saber si te ha pasado algo similar.
¿Has dado por hecho que algo estaba bien solo porque “se veía bien”?
¿O confiaste en que un Dev no se equivoca y dejaste de probar como deberías?
Cuéntamelo en los comentarios. Estoy seguro de que más de un colega se va a sentir identificado
