QA no es calidad de producto: la diferencia que se paga

Un SaaS con el que trabajé tenía la suite de pruebas en verde, doscientas pruebas automatizadas y cero incidencias abiertas. También tenía una activación del 19 % y clientes que no renovaban sin dar explicaciones. Las dos cosas eran verdad a la vez, y no es una contradicción: son dos preguntas distintas.

El QA responde a si el producto está roto. La calidad de producto responde a si el producto sirve. Un equipo puede tener la primera resuelta y la segunda sin empezar, y desde dentro se parece mucho a estar haciéndolo bien.

Qué cubre el QA de un SaaS

Vale la pena enumerarlo porque es mucho, y porque la conclusión de este artículo no es que el QA importe poco.

Pruebas funcionales. Cada función hace lo que la especificación decía. Manuales o automatizadas.

Pruebas de regresión. Lo que funcionaba antes sigue funcionando después del cambio. En un producto que despliega varias veces por semana, es la red de seguridad más rentable de todas.

Pruebas de rendimiento y carga. El sistema aguanta con muchos usuarios simultáneos y no se degrada.

Pruebas de integración y de API. Las piezas hablan entre sí y con los sistemas del cliente.

Pruebas de seguridad. Que nadie vea datos que no le tocan y que nadie entre donde no debe.

Pruebas de compatibilidad. Navegadores, dispositivos, tamaños de pantalla.

Pruebas de respaldo y recuperación. Se pueden restaurar los datos. La que más equipos tienen escrita y menos han ejecutado de verdad.

Todo eso comparte una característica: mide el producto contra su especificación. Y ahí está el hueco.

Los cinco fallos de calidad que pasan en verde

Ninguno de estos aparece en una suite de pruebas. Los cinco cuestan clientes.

1. La especificación estaba equivocada. La función se construyó exactamente como se pidió y nadie la necesitaba. El QA no puede detectarlo porque su vara de medir es precisamente el documento que estaba mal. Es el fallo más caro que existe en producto, y la forma de reducirlo es decidir mejor antes de construir: cómo priorizar features.

2. Funciona y no se entiende. El flujo se completa en las pruebas porque quien las escribió sabe dónde hay que pulsar. Un cliente nuevo no lo sabe. Esto se manifiesta como tickets de “¿dónde está…?” y como abandono silencioso en la mitad del formulario.

3. Los estados intermedios. Las pruebas recorren el camino feliz y a veces el error obvio. El estado vacío del primer día, la espera de once segundos sin señal de que algo pasa, el mensaje de error que dice “algo ha ido mal”: ahí no hay ninguna prueba, y ahí es donde la gente decide que el producto no es serio. Lo desarrollé en cómo diseñar un empty state que active.

4. La distancia entre lo prometido y lo entregado. Tu web promete una cosa, el producto hace otra parecida. Ninguna prueba compara el producto con el argumentario comercial, y el abandono que produce este desajuste parece de usabilidad sin serlo.

5. La degradación lenta. Cada despliegue añade un campo, una opción, un aviso. Ninguno rompe nada, todos pasan las pruebas, y a los dieciocho meses el producto es un panel de control de un avión. No existe la prueba de regresión de la complejidad acumulada.

La tabla

	QA	Calidad de producto
Pregunta que responde	¿Está roto?	¿Sirve?
Vara de medir	La especificación	El resultado del cliente
Cuándo se ejecuta	Antes de desplegar	Semanas después, en el uso real
Quién lo detecta	Pruebas y monitorización	Activación, soporte, churn
Coste de un fallo	Horas	Un cliente, o un trimestre
Se puede automatizar	Sí, casi todo	No

La fila que más consecuencias tiene es la última. Como el QA se automatiza y la calidad de producto no, los equipos derivan de forma natural hacia medir lo que se automatiza. No es negligencia, es gravedad.

Cómo saber cuál es tu problema

Coge los tickets del último mes y clasifícalos en cuatro cubos. La distribución te da el diagnóstico sin ambigüedad:

• “Se ha roto” / “da error”. Problema de QA. Invierte en pruebas de regresión y en monitorización.
• “No hace lo que esperaba”. Problema de adecuación funcional. La función existe y resuelve otra cosa.
• “No sé cómo hacer X”. Problema de experiencia. El producto funciona y la persona no puede usarlo sola, que a efectos de renovación es lo mismo que si no funcionara.
• “Pensaba que esto hacía otra cosa”. Problema de promesa. Se decide en el marketing y en el proceso comercial, no en el código.

Si el primer cubo tiene menos del 20 % y sigues teniendo clientes que se van, tu problema no es de QA y contratar más pruebas no lo va a mover. Las señales para medir los otros tres están en calidad de productos SaaS: cómo medirla sin equipo de QA.

Qué montar si no tienes equipo de QA

Por debajo de treinta personas no vas a tener QA dedicado, y no hace falta. Lo mínimo que aguanta:

1. Pruebas automatizadas solo de los dos o tres flujos que generan ingresos. Alta, pago, la acción principal. Ignora el resto sin culpa.
2. Una prueba de recuperación de datos ejecutada de verdad, con fecha, al menos una vez. No basta con tener el respaldo configurado.
3. Cinco minutos de uso real por despliegue, hechos por alguien que no escribió el código, entrando como entra un cliente nuevo.
4. Los cuatro cubos de tickets revisados una vez al mes. Es lo más rentable de esta lista y no cuesta nada.
5. La activación instrumentada. Si eliges una sola cosa de las cinco, esta. Es lo único que te avisa de los fallos de calidad que ninguna prueba ve.

El marco formal para la parte técnica, si necesitas un vocabulario común con el equipo o con un cliente que lo pide por contrato, es la ISO 25010: cuáles de sus nueve características valen tal cual en un SaaS y cuáles sobran, en la ISO 25010 aplicada a un SaaS.

Y si lo que tienes es todo en verde y una métrica que no se mueve, eso es un diagnóstico de producto, no de pruebas. Es el alcance exacto de una auditoría de producto: dos semanas, los dos flujos que más te cuestan, y una lista ordenada de qué arreglar primero con la evidencia de por qué. Cómo se hace por dentro está en cómo auditar un producto SaaS en una semana.