Dos Formas de Pensar
El desarrollo de software requiere dos modos de pensamiento fundamentalmente diferentes. El desarrollador pregunta: “Como hago que esto funcione?” El tester pregunta: “Como podria fallar esto?”
Ninguna pregunta es mas importante que la otra. Ambas son esenciales. Pero requieren modelos mentales diferentes, suposiciones diferentes e instintos diferentes. Entender la mentalidad de testing es la base sobre la cual se construyen todas las habilidades de testing.
La Mentalidad del Desarrollador
Los desarrolladores son constructores. Su modo principal de pensamiento es constructivo:
- “Como implemento este requisito?”
- “Cual es el algoritmo mas eficiente?”
- “Como manejo las entradas esperadas?”
- “Cual es la solucion limpia y mantenible?”
Esta mentalidad es esencial para crear software. Pero tiene un punto ciego: los desarrolladores naturalmente piensan en como las cosas deberian funcionar, no en como podrian romperse.
Cuando un desarrollador prueba su propio codigo, tiende a:
- Probar los caminos que considero mientras codificaba (el happy path)
- Usar entradas razonables y esperadas
- Seguir el flujo de trabajo que diseno
- No detectar edge cases que no considero durante el desarrollo
Esto no es una critica a los desarrolladores — es naturaleza humana. El creador de algo tiene las mismas suposiciones y modelo mental que aquello que creo.
La Mentalidad del Tester
Los testers son investigadores. Su modo principal de pensamiento es analitico y a veces destructivo:
- “Que pasa si no ingreso nada?”
- “Que pasa si dos usuarios hacen esto al mismo tiempo?”
- “Que pasa si la red se cae a mitad de operacion?”
- “Que pasa en los limites — 0, -1, MAX_INT?”
- “Que pasa si el usuario hace las cosas en orden incorrecto?”
La mentalidad del tester se caracteriza por:
Escepticismo Saludable
Un tester no confia en que el software funciona hasta tener evidencia. “Funciona en mi maquina” no es evidencia. “El desarrollador dijo que lo probo” no es evidencia. Resultados reales de pruebas con pasos documentados son evidencia.
Curiosidad
Los grandes testers son inherentemente curiosos. Quieren saber que pasa cuando hacen clic en ese boton sin etiqueta, ingresan caracteres Unicode en el campo de telefono, o redimensionan el navegador a 200 pixeles de ancho. Exploran rincones de la aplicacion para los que nadie diseno pruebas.
Atencion al Detalle
La diferencia entre un bug critico y un test aprobado puede ser un solo caracter, una diferencia de 1 milisegundo en timing, o un pixel de desalineacion. Los testers desarrollan un ojo para notar cosas que estan “casi bien” pero no del todo.
Empatia por los Usuarios
Los mejores testers piensan como usuarios, no como ingenieros. Preguntan: “Mi abuela entenderia este mensaje de error?” y “Que veria un usuario daltonico aqui?” Representan la voz del usuario en el proceso de desarrollo.
Pensamiento “Que Podria Salir Mal?”
Este es el nucleo de la mentalidad de testing. Para cada funcionalidad, cada entrada, cada flujo de trabajo — un tester instintivamente cataloga las formas en que podria fallar:
- Entradas invalidas
- Condiciones limite
- Acceso concurrente
- Fallas de red
- Problemas de permisos
- Corrupcion de datos
- Rendimiento bajo carga
- Problemas de accesibilidad
Sesgos Cognitivos en Testing
Incluso testers experimentados son susceptibles a sesgos cognitivos que pueden comprometer la calidad del testing. Reconocer estos sesgos es el primer paso para mitigarlos.
Sesgo de Confirmacion
Que es: La tendencia a buscar evidencia que confirme lo que ya crees e ignorar evidencia que lo contradiga.
En testing: Si crees que una funcionalidad funciona correctamente, inconscientemente disenas pruebas que pasaran. Pruebas el happy path, usas datos validos y sigues el flujo esperado. No intentas activamente romper el software.
Contramedida: Disena deliberadamente pruebas que pretendan fallar. Por cada prueba que confirma comportamiento esperado, escribe una que lo desafie.
Sesgo de Anclaje
Que es: Depender excesivamente de la primera informacion que recibes.
En testing: Si el desarrollador dice “solo cambie el componente del header,” podrias limitar tu testing al header y perder regresiones en areas no relacionadas causadas por dependencias compartidas.
Contramedida: Siempre ejecuta pruebas de regresion completas para cambios significativos, sin importar lo que te digan sobre el alcance del cambio.
Sesgo de Automatizacion
Que es: Confiar excesivamente en sistemas automatizados y no verificar suficientemente sus resultados.
En testing: “Los 500 tests automatizados pasaron, asi que el build debe estar bien.” Pero que si los tests mismos tienen bugs? Que si estan probando requisitos obsoletos? Que si no estan probando lo que crees?
Contramedida: Revisa resultados de tests automatizados criticamente con regularidad. Complementa el testing automatizado con testing exploratorio manual.
Efecto Manada
Que es: La tendencia a hacer o creer cosas porque otros lo hacen.
En testing: “Nadie mas reporto esto como bug, asi que quizas no lo es.” O “El equipo decidio no testear esta area, asi que debe estar bien.”
Contramedida: Confia en tus instintos. Si algo parece incorrecto, investigalo sin importar lo que otros piensen.
en Testing] --> C[Sesgo de Confirmacion
Buscando aprobaciones] CB --> A[Sesgo de Anclaje
Vision de alcance limitado] CB --> AU[Sesgo de Automatizacion
Confianza excesiva en herramientas] CB --> B[Efecto Manada
Seguir a la mayoria] C --> M1[Contra: Disenar tests
que pretendan fallar] A --> M2[Contra: Ejecutar regresion
completa siempre] AU --> M3[Contra: Revisar resultados
criticamente] B --> M4[Contra: Confiar en
tus instintos] style CB fill:#ef4444,color:#fff
Colaboracion Desarrollador-Tester
La mentalidad de testing no significa que testers y desarrolladores sean adversarios. Los mejores equipos aprovechan ambas mentalidades colaborativamente:
Three Amigos: Antes de que comience el desarrollo, un desarrollador, un tester y un product owner discuten cada user story juntos. El desarrollador hace preguntas de implementacion. El tester hace preguntas de “que podria salir mal?” El product owner clarifica la intencion. Esta sesion de 15 minutos previene mas bugs que horas de testing post-desarrollo.
Pair testing: Un desarrollador y un tester exploran una funcionalidad juntos. El desarrollador explica las decisiones de implementacion, y el tester sondea areas que el desarrollador podria haber pasado por alto. Ambos aprenden el uno del otro.
Empatia con bugs: Cuando un tester reporta un bug, no es un ataque al desarrollador. Es un esfuerzo colaborativo para mejorar el producto. Los mejores testers reportan bugs con empatia — pasos claros para reproducir, contexto relevante y tono constructivo.
Ejercicio: Revisa una Especificacion de Funcionalidad
Lee la siguiente especificacion e identifica al menos 8 problemas potenciales, brechas o preguntas que un tester con la mentalidad correcta plantearia:
Funcionalidad: Subida de Foto de Perfil
Los usuarios pueden subir una foto de perfil desde la pagina de configuracion. La imagen se muestra como un avatar circular en la barra de navegacion y en la pagina de perfil del usuario. Formatos soportados: JPG y PNG. Tamano maximo: 5 MB.
Escribe tus preguntas antes de revelar la solucion.
Pista
Piensa en: validacion de entradas, edge cases, manejo de errores, rendimiento, seguridad, accesibilidad, concurrencia y experiencia de usuario. Que NO se menciona en la especificacion que deberia estar?Solucion
Un tester con la mentalidad correcta preguntaria:
Validacion de Entradas:
- Que pasa si el usuario sube un archivo GIF, BMP, WebP o SVG? Que mensaje de error se muestra?
- Que si el archivo es exactamente 5 MB? Y 5.01 MB?
- Que si el archivo tiene extension .jpg pero en realidad es un .exe o .pdf renombrado?
- Hay tamano minimo — se puede subir un archivo de 1 byte?
- Cuales son las dimensiones minimas y maximas de imagen?
Manejo de Errores: 6. Que pasa si la subida falla a mitad de transferencia (desconexion de red)? 7. Cual es el mensaje de error si el archivo es muy grande? Es amigable? 8. Que pasa si el servidor se queda sin espacio de almacenamiento?
Experiencia de Usuario: 9. El usuario puede recortar o redimensionar la imagen antes de subirla? 10. Hay un indicador de carga durante la subida? 11. Cual es el avatar predeterminado si no se sube foto? 12. El usuario puede eliminar su foto de perfil despues de subirla?
Seguridad: 13. Se escanea la imagen por malware o scripts embebidos (XSS via SVG)? 14. La URL de la imagen es predecible? Alguien puede enumerar fotos de otros usuarios? 15. Las imagenes se sirven desde un dominio separado (para prevenir robo de cookies)?
Rendimiento: 16. Las imagenes se redimensionan/comprimen del lado del servidor, o se sirve el archivo completo de 5 MB? 17. Que pasa si 100 usuarios suben simultaneamente?
Accesibilidad: 18. Que texto alternativo se usa para la imagen del avatar? 19. Se puede completar la subida usando solo teclado?
Concurrencia: 20. Que si el usuario sube desde dos dispositivos simultaneamente? 21. Que pasa con las versiones en cache del avatar anterior en navegadores de otros usuarios?
La especificacion no menciona ninguna de estas preocupaciones, pero cada una podria llevar a un defecto o mala experiencia de usuario.
Tips Profesionales
Tip 1: Practica los “5 Por Ques” diariamente. Cuando veas cualquier comportamiento en software — esperado o no — pregunta “por que?” cinco veces. “Por que la pagina tarda 3 segundos en cargar?” “Por que esa consulta es lenta?” “Por que esa tabla no tiene indice?” Este habito construye comprension profunda.
Tip 2: Prueba como un principiante confundido, no como un experto. Tu perspectiva mas valiosa es la ignorancia. Que pasa cuando alguien que nunca ha visto esta interfaz intenta usarla? Donde se confundiria? Que haria clic primero?
Tip 3: Mantén un cuaderno de “cosas para probar.” Cuando uses cualquier software — tu app bancaria, un servicio de streaming, un flujo de checkout — nota que funciona y que no. Esto construye tu instinto de testing en todos los productos, no solo en el que te pagan por probar.
Puntos Clave
- La mentalidad del desarrollador (constructiva) y del tester (analitica) son ambas esenciales
- Los testers aportan escepticismo saludable, curiosidad, atencion al detalle y pensamiento “que podria salir mal?”
- Los sesgos cognitivos (confirmacion, anclaje, automatizacion, manada) pueden comprometer la calidad del testing
- Los mejores equipos usan ambas mentalidades colaborativamente mediante practicas como Three Amigos y pair testing
- El testing independiente detecta lo que el auto-testing pierde debido a suposiciones compartidas
- La mentalidad de testing es una habilidad que mejora con la practica, no un rasgo de personalidad innato