Pruebas funcionales vs no funcionales: qué mides con cada una

La diferencia cabe en una sola frase: las pruebas funcionales comprueban qué hace el sistema; las no funcionales comprueban cómo lo hace. Si un botón de "Pagar" cobra el monto correcto, eso es funcional. Si ese mismo botón responde en menos de un segundo con 5.000 personas comprando a la vez, eso es no funcional. Un producto puede pasar cada prueba funcional y aun así caerse el día del lanzamiento porque nadie midió lo segundo.

Ese es el error caro. Los equipos llenan hojas de casos que verifican reglas de negocio (funcional) y dan por hecho que "funciona". Pero funcionar en la máquina del desarrollador, con un solo usuario y datos limpios, no es lo mismo que funcionar en producción con carga real, redes lentas y usuarios que usan lector de pantalla. Este artículo separa los dos ejes y muestra por qué necesitas ambos.

01 · el quéPruebas funcionales: verifican el comportamiento

Una prueba funcional confirma que una función del producto hace lo que dice su especificación. Le das una entrada, esperas una salida concreta, y comparas. Si la regla dice "un carrito con más de tres productos aplica 10 % de descuento", la prueba mete cuatro productos y verifica que el total baje ese 10 %. No importa cuánto tardó ni cuánta memoria gastó: importa que el resultado sea el correcto.

El estándar internacional de calidad de producto de software, la ISO/IEC 25010, agrupa esto bajo idoneidad funcional (functional suitability): que las funciones estén completas, sean correctas y sean apropiadas para la tarea [1]. En la práctica, casi todo lo que un analista de QA escribe como "caso de prueba" con pasos y resultado esperado es funcional.

Funcional responde una sola pregunta: dado esto, ¿el sistema devuelve lo que debería?

Ejemplos típicos de pruebas funcionales:

• Login: con credenciales válidas entra; con contraseña incorrecta muestra el error correcto.
• Validaciones: un correo sin arroba se rechaza; un campo obligatorio vacío no deja continuar.
• Reglas de negocio: el impuesto se calcula según el país; el envío gratis aplica sobre cierto monto.
• Flujos completos: registrar, confirmar por correo, iniciar sesión y comprar de principio a fin.

02 · el cómoPruebas no funcionales: verifican la calidad de servicio

Una prueba no funcional no pregunta si el resultado es correcto, sino si el sistema es bueno mientras lo entrega: rápido, estable, seguro, usable, accesible. Son las cualidades que el usuario siente aunque nunca las nombre. Nadie dice "qué buena idoneidad funcional"; la gente dice "esto vuela" o "esto se cae a cada rato".

La ISO/IEC 25010 nombra estas características de calidad más allá de lo funcional. Entre las más usadas en QA [1]:

• Eficiencia de desempeño (performance): tiempos de respuesta, uso de recursos, capacidad bajo carga.
• Seguridad: confidencialidad, integridad, autenticación, resistencia a ataques.
• Fiabilidad: disponibilidad, tolerancia a fallos, capacidad de recuperación.
• Usabilidad: qué tan fácil es aprender y operar el producto sin frustración.
• Compatibilidad, mantenibilidad y portabilidad: convive con otros sistemas, se cambia sin romperse, se mueve de entorno.

La accesibilidad merece su propio renglón. Un producto puede pasar toda prueba funcional y ser inutilizable para alguien que navega con teclado o con lector de pantalla. Las pautas WCAG del W3C dan criterios verificables (contraste de color, texto alternativo, foco visible, orden de tabulación) que convierten "accesible" en algo medible y no en una opinión [3].

Lo funcional te dice si el producto sirve. Lo no funcional te dice si sobrevive el contacto con usuarios reales.

03 · juntasPor qué necesitas los dos ejes, no uno

La trampa mental es tratarlos como niveles: "primero lo funcional y, si sobra tiempo, lo no funcional". No son niveles, son ejes independientes. Un producto ocupa un punto en ambos a la vez. Puedes tener funcionalidad perfecta y desempeño desastroso, o al revés: algo velocísimo que calcula mal el impuesto.

Piensa en un cajero automático. Funcional: entrega el monto exacto que pediste y actualiza tu saldo. No funcional: hace esa operación en pocos segundos, no revela tu PIN, y sigue funcionando aunque cientos de personas lo usen el día de pago. Si falla el eje funcional, te da dinero de más o de menos. Si falla el no funcional, tarda cinco minutos, se cuelga en hora pico o filtra tu clave. Ninguno de los dos fallos es aceptable, y ninguna cantidad de pruebas de un eje detecta los fallos del otro.

El ISTQB, el cuerpo de certificación de referencia en pruebas de software, clasifica explícitamente los tipos de prueba en funcionales, no funcionales, de caja blanca y de confirmación/regresión, precisamente para que un plan de pruebas cubra ambos ejes de forma deliberada y no por accidente [2].

Una regla práctica para saber ante cuál estás: si la prueba se puede describir con "dado X, el sistema debe devolver Y", es funcional. Si se describe con un adverbio o una cualidad ("rápidamente", "de forma segura", "sin caerse", "de manera accesible"), es no funcional, y entonces te falta ponerle un número.

La lección para cualquiera que construya producto: pasar todos los casos funcionales es condición necesaria pero no suficiente. El día que tu producto crezca, la carga, la seguridad y la accesibilidad dejan de ser detalles y pasan a ser lo que decide si la gente se queda o se va. Mídelos antes de que lo haga producción por ti.