Un sistema puede pasar todas las pruebas funcionales y aun así ser un fracaso.
Hace exactamente lo que pedía la especificación. Cada botón funciona, cada cálculo es correcto, cada flujo se completa solo. Y aun así, es lento hasta el punto de irritar, se bloquea cuando mucha gente lo usa, filtra datos en el primer intento de ataque y está tan enredado que nadie puede cambiarlo sin romper otras tres cosas. Funciona y es malo.
Esta diferencia entre "hace lo que se supone que debe hacer" y "lo hace lo suficientemente bien como para ser utilizado" es exactamente territorio de las pruebas no funcionales. Son, en mi opinión, la parte de calidad que más distingue los productos profesionales de los prototipos disfrazados.
Funcional versus no funcional
La distinción es sencilla de formular y profunda en sus consecuencias.
Las pruebas funcionales verifican lo que hace el sistema: dada una entrada, ¿produce la salida correcta? ¿Se ahorra el registro? ¿Se procesa el pago? ¿El informe proporciona las cifras correctas? Estas son preguntas sobre comportamiento y corrección.
Las pruebas no funcionales comprueban cómo funciona el sistema: qué tan rápido, qué tan seguro, qué tan confiable, qué tan escalable, qué tan fácil de usar y mantener. No preguntan "¿funciona?", sino "¿funciona bien?". Velocidad, seguridad, estabilidad bajo carga, accesibilidad, todo esto no es funcional.
La trampa es que lo funcional es fácil de especificar y cobrar, por lo que recibe casi toda la atención. Lo no funcional es difuso, fácil de posponer y por lo tanto suele descuidarse, hasta convertirse en la razón por la que el sistema falla en producción.
Las dimensiones que importan
"No funcional" es un paraguas grande. Vale la pena conocer las dimensiones principales, porque cada una es una forma diferente de decepcionar el sistema incluso cuando está funcionando.
El rendimiento es el más visible: tiempos de respuesta, velocidad de uso. Un sistema correcto pero lento pierde usuarios silenciosamente. La escalabilidad y la capacidad responden a si puede manejar el crecimiento y los picos de la demanda, en lugar de funcionar únicamente cuando pocas personas lo usan.
La confiabilidad y la disponibilidad tienen que ver con la continuidad: ¿el sistema resiste el paso del tiempo, se recupera de fallas, no de datos corruptos? La seguridad comprueba si resiste el uso malicioso, y aquí es donde reside la categoría de defectos más cara, porque un fallo de seguridad no frustra al usuario, sino que lo expone.
La usabilidad y la accesibilidad preguntan si personas reales, con diferentes capacidades y contextos, realmente pueden usarlo. Y la mantenibilidad, la más invisible de todas, pregunta si el equipo puede hacer evolucionar el sistema sin que cada cambio se convierta en un campo minado.
Por qué se difiere lo no funcional (y por qué es un error)
Hay una razón estructural por la que se descuida lo no funcional: no aparece en la demostración.
Cuando muestra el sistema a un cliente o administrador, muestra funcionalidad. "Mira, haz esto, haz aquello". Nadie demuestra "mira cómo aguanta diez mil usuarios" o "mira cómo resiste un ataque". Estas cualidades son invisibles hasta el día en que faltan, y entonces aparecen como una crisis.
El resultado es una economía falsa. La prueba de carga, seguridad, accesibilidad se pospone, porque "primero hay que trabajar". Luego, el sistema entra en producción, falla en el primer pico, filtra datos o excluye a parte de los usuarios, y el costo de corregir tarde es varias veces mayor de lo que hubiera sido probarlo a tiempo.
En el sector público esto es especialmente grave. Un sistema de atención ciudadana que funciona pero que es lento, inseguro o inaccesible no atiende a quienes más lo necesitan. Y cuando se trata de datos personales, el fallo de seguridad no funcional se topa directamente con la LGPD, deja de ser un problema técnico y pasa a ser un problema legal.
Probar lo no funcional requiere una mentalidad diferente
La funcionalidad de prueba es relativamente sencilla: definir entradas, verificar salidas. Probar lo no funcional es más difícil porque requiere definir qué es "suficientemente bueno", y eso es una decisión, no un hecho.
¿Qué tan rápido es lo suficientemente rápido? ¿Cuántos usuarios simultáneos puede "manejar"? ¿Qué nivel de disponibilidad es aceptable? Estas preguntas no tienen una respuesta universal; Dependen del contexto de la empresa y de los usuarios. Por lo tanto, el primer trabajo de las pruebas no funcionales es transformar cualidades vagas en objetivos mensurables. "Rápido" no se prueba; Se prueba "responder por debajo de ese tiempo en el 95% de los casos".
La consecuencia práctica es que es necesario definir tempranamente los requisitos no funcionales, junto con los funcionales. Tratarlos como una ocurrencia tardía es garantizar que se les hará la prueba demasiado tarde o nunca.
Los errores que hacen inútil el esfuerzo
El primer error es no fijarse objetivos. Sin un objetivo, "probar el rendimiento" se convierte en recopilar números sin saber si son buenos o malos. El objetivo tiene que venir antes de la prueba.
El segundo es realizar pruebas en un entorno poco realista. Medir el rendimiento en una máquina que no sea la de producción, o la seguridad sin escenarios de ataque realistas, genera resultados engañosos. Lo no funcional es especialmente sensible al entorno, los números sólo son válidos si las condiciones se parecen a la realidad.
La tercera es tratarlo como un evento único. El rendimiento, la seguridad y la confiabilidad se degradan con el tiempo, con cada cambio en el sistema. Una prueba de seguridad realizada una vez en el lanzamiento dice poco sobre la seguridad seis meses y cincuenta lanzamientos después. Las necesidades no funcionales recurren.
La calidad es lo que queda cuando se da por sentada la funcionalidad
Hay un momento en la madurez de un producto, y de una organización, en el que el “funciona” deja de ser un logro y se convierte en un punto de partida. A partir de entonces, la verdadera calidad se define por lo no funcional: es rápido, es seguro, aguanta, se sostiene, es accesible, es posible evolucionar.
Los equipos de startups celebran que "funciona". Los equipos maduros saben que esto es sólo la cancha. Lo que distingue a un sistema profesional de uno amateur rara vez es lo que hace, sino lo bien que lo hace, bajo presión, con el tiempo, para todos. Este "qué tan bien" es precisamente lo que protegen las pruebas no funcionales.
Ignorarlos no ahorra esfuerzo. Simplemente traslada el coste al peor momento posible: la producción, con el usuario presente.
Si su producto "funciona" pero nunca ha medido qué tan rápido, seguro o resistente es, probablemente exista un riesgo no funcional esperando a surgir. Tengo otros artículos en el blog sobre rendimiento, seguridad, confiabilidad y calidad del software que abordan cada una de estas dimensiones.
Lea también
- Pruebas de carga: qué son y por qué tu sistema debe hacerlas antes que el cliente
- Pruebas de estrés: descubre cómo se rompe el sistema antes de que se rompa a sí mismo
- Pruebas No Funcionales: Script con Casos Reales
- Pruebas no funcionales: Script con lista de verificación
- Pruebas automatizadas: por qué el código no probado es deuda
- Pruebas de estrés: modelos de negocio cotidianos