En más de una ocasión he visto equipos construir productos técnicamente impecables que, aun así, no logran despegar. No fallan por errores críticos, ni por una mala arquitectura, ni por decisiones técnicas deficientes. Fallan porque, simplemente, nadie los necesita o nadie los quiere usar. Esta es una realidad incómoda, pero frecuente, y tiene mucho que ver con cómo entendemos la calidad dentro de los equipos de software.
Entré a uno de esos equipos hace algunos años y trabajé con ellos durante aproximadamente un año y medio. Desde el primer día quedé impresionado. La arquitectura estaba bien pensada, los patrones eran claros, el foco en performance era evidente y las decisiones técnicas eran sólidas. Desde una perspectiva interna, el producto estaba bien construido. No había improvisación ni desorden. Todo estaba “correcto”.
El negocio también estaba presente. Participaba activamente, se discutían objetivos, se hablaba de prioridades y se hacían preguntas sobre para quién se estaba construyendo el producto. Existía una intención genuina de hacer las cosas bien. Sin embargo, con el tiempo empecé a notar una desconexión sutil pero constante entre lo que se construía y cómo eso iba a ser recibido por los usuarios finales.
Había preguntas que no se abordaban con la profundidad necesaria. ¿Qué estamos entregando exactamente? ¿Cómo van a interpretar esto los usuarios? ¿Qué tan importante es realmente para ellos? ¿Qué problema concreto les estamos resolviendo? Estas preguntas aparecían de forma superficial o tardía, cuando el producto ya estaba definido o incluso construido. Desde la perspectiva de QA, esa falta de claridad era una señal de riesgo.
Trabajar en calidad no consiste únicamente en validar que el software funcione según lo especificado. Implica también entender si lo que se construye tiene sentido para quienes lo van a usar. Sin embargo, en muchos equipos, QA no tiene acceso directo a información clave sobre usuarios: retroalimentación real, contexto de uso, expectativas, frustraciones o razones de abandono. QA termina probando funcionalidades bien implementadas, pero desconectadas del valor real que deberían generar.
Las consecuencias de esta desconexión no siempre son inmediatas. El producto puede salir a producción sin problemas técnicos importantes, pero empezar a acumular malas reseñas, falta de adopción, poco uso o un boca a boca negativo. Entonces surge la pregunta inevitable: ¿cómo pudo fracasar algo que estaba tan bien hecho? La respuesta suele ser incómoda: el producto no falló técnicamente, falló en relevancia.
Esta experiencia reforzó una convicción que considero fundamental: QA no está únicamente para probar que algo funcione ni para validar decisiones de negocio sin cuestionarlas. QA también cumple un rol clave en cómo un producto es percibido externamente. La calidad no es un concepto único. Tiene, al menos, dos dimensiones claras. La calidad interna, relacionada con cómo está construido el software, y la calidad externa, que se manifiesta en la experiencia, utilidad y percepción de valor por parte de los usuarios.
Ignorar cualquiera de estas dimensiones puede llevar a productos técnicamente correctos pero comercialmente irrelevantes. Por eso, la pregunta no debería ser solo qué salió mal en estos casos, sino qué puede hacer QA para reducir este riesgo desde el inicio.
De la experiencia a la práctica: qué puede hacer QA
No todos los equipos permiten acceso directo a usuarios, pero eso no significa que QA esté completamente limitado. Existen formas concretas de incorporar la perspectiva del usuario al trabajo diario, incluso cuando la información es parcial. Una de las más efectivas es empezar a hacer mejores preguntas antes de probar.
A continuación, presento una técnica simple que utilizo de forma recurrente y que puede aplicarse sin herramientas adicionales ni grandes cambios de proceso.
Técnica: Checklist de Calidad Externa para QA
Antes de probar una funcionalidad, tómate el tiempo de responder estas preguntas. No como un ejercicio burocrático, sino como una forma de identificar riesgos que no aparecen en los requisitos técnicos.
1. Sobre el usuario
¿Quién va a usar esta funcionalidad? ¿En qué contexto la va a usar? ¿Es algo que utilizará frecuentemente o de forma ocasional?
2. Sobre el problema
¿Qué problema real intenta resolver esta funcionalidad? ¿Qué hacía el usuario antes de que existiera? ¿Qué alternativa tiene si esto no funciona o no le resulta útil?
3. Sobre el valor
¿Cómo sabrá el usuario que esto le ayudó? ¿Qué sería un fallo inaceptable desde su perspectiva? ¿Qué podría hacer que abandone este flujo?
4. Sobre el riesgo
¿Qué pasa si esto funciona técnicamente, pero es confuso? ¿Qué ocurre si tarda demasiado? ¿Qué sucede si el usuario no entiende qué hacer después?
Si QA no puede responder estas preguntas, el principal riesgo no es técnico, es de producto. Este ejercicio no reemplaza el contacto directo con usuarios, pero ayuda a visibilizar vacíos importantes antes de que se conviertan en problemas reales.
Este tipo de reflexión suele conectarse de forma natural con técnicas más estructuradas como User Personas, que ayudan a dejar de diseñar y probar para usuarios genéricos, o User Journey Mapping, que permite identificar fricciones a lo largo del recorrido completo del usuario. Asimismo, sesiones tempranas como una Inception o Lean Inception ofrecen el espacio ideal para que estas preguntas aparezcan antes de que exista código y no cuando QA empieza a probar.
La lección clave
Los productos no fracasan únicamente por errores. Fracasan porque los usuarios no quieren usarlos. Ningún nivel de excelencia técnica compensa la falta de relevancia o de valor percibido. La calidad no se limita a que el sistema funcione correctamente; se construye entendiendo profundamente a las personas para quienes ese sistema existe.
Si queremos crear productos exitosos, necesitamos dejar de enfocarnos únicamente en que “todo esté bien hecho” y empezar a preguntarnos con más frecuencia si aquello que construimos realmente le importa a alguien. QA no puede garantizar el éxito de un producto, pero sí puede ayudar a evitar que productos técnicamente “perfectos” fracasen por razones que nadie quiso cuestionar a tiempo.
Y muchas veces, todo empieza con hacer mejores preguntas.
