ISO/IEC 25010: el mapa de qué significa “software de calidad”

En una reunión de proyecto, alguien dice: "el software tiene que ser de calidad". Todos asienten. Nadie discute. Y ese es el problema: cada quien asintió pensando en algo distinto. Uno pensó en que no se cae. Otro, en que carga rápido. Otro, en que se entiende sin manual. La palabra "calidad" los hizo creer que estaban de acuerdo cuando en realidad ni siquiera estaban hablando de lo mismo.

La ISO/IEC 25010 existe para terminar esa confusión. No es una regla que te obligue a nada: es un vocabulario. Descompone eso tan resbaladizo que llamamos "calidad" en ocho características concretas, cada una con nombre propio. Y cuando algo tiene nombre, deja de ser opinión y empieza a poder medirse.

01 · el problemaPor qué "calidad" a secas no sirve para acordar nada

La respuesta corta: porque "calidad" es un contenedor vacío que cada persona llena con su prioridad. El comercial la llena con "que se vea bien", el de infraestructura con "que aguante la carga", el de soporte con "que nadie llame". Los tres tienen razón y ninguno se entiende con los otros.

La ISO/IEC 25010 forma parte de la familia SQuaRE (System and Software Quality Requirements and Evaluation), la serie de estándares ISO/IEC 250xx dedicada a definir y evaluar calidad de software [1]. Su aporte central es un modelo de calidad del producto: en lugar de una palabra, ocho características. Y cada característica se subdivide en subcaracterísticas todavía más concretas. Así, en vez de pedir "calidad", puedes pedir "tiempo de respuesta por debajo de 200 ms bajo 500 usuarios concurrentes", que es una frase con la que un equipo sí puede trabajar.

La calidad no se discute. Se nombra, y entonces se mide.

El estándar no dice que todo software deba ser excelente en las ocho. Dice algo más útil: aquí están las ocho, elige cuáles importan en tu contexto y con qué exigencia. Un marcapasos y un juego de celular no comparten prioridades, y está bien que así sea.

02 · el mapaLas ocho características, en el idioma de todos los días

Estas son las ocho características del modelo de calidad del producto según la ISO/IEC 25010 [1]. Las traduzco a preguntas que cualquiera entiende.

1. Adecuación funcional. ¿Hace lo que debe hacer? Es la pregunta de si las funciones existen, son correctas y cubren lo que el usuario necesita. Un botón de "guardar" que no guarda falla aquí, aunque sea bello y rápido.

2. Eficiencia de desempeño. ¿Lo hace usando recursos razonables? Cubre tiempos de respuesta, uso de memoria y CPU, y capacidad ante carga. No es "que sea rápido" a secas, sino rápido en relación con los recursos que consume.

3. Compatibilidad. ¿Convive con lo demás? Mide si el sistema coexiste con otros en el mismo entorno sin estorbarse (coexistencia) y si intercambia información con ellos (interoperabilidad). Tu app que exporta a un formato que nadie más lee falla aquí.

4. Usabilidad. ¿La gente la entiende y la usa sin sufrir? Reúne si se aprende sin manual, si protege de errores, si es accesible. Un sistema potente que nadie logra operar tiene un problema real de usabilidad, no un capricho de diseño.

5. Fiabilidad. ¿Se puede confiar en que seguirá funcionando? Habla de madurez (falla poco), disponibilidad (está cuando se le necesita), tolerancia a fallos y capacidad de recuperarse. Es la diferencia entre "funcionó en la demo" y "funciona el martes a las 3 de la mañana".

6. Seguridad. ¿Protege la información y el acceso? Cubre confidencialidad, integridad, autenticidad y que las acciones queden registradas. Aquí no se trata de que el sistema funcione, sino de que no funcione para quien no debe.

7. Mantenibilidad. ¿Se puede cambiar sin romperlo todo? Mide qué tan modular es, qué tan fácil se prueba, se modifica y se reutiliza. Un código que nadie se atreve a tocar por miedo a lo que se rompa falla aquí, aunque hoy funcione.

8. Portabilidad. ¿Se puede mover a otro lado? Habla de adaptarse a nuevos entornos, instalarse sin dolor y reemplazar a otro sistema. Software amarrado a una sola máquina o un solo proveedor tiene poca portabilidad.

03 · el uso realNo persigas las ocho: elige cuáles importan en tu contexto

Aquí está el error más común y también el más caro: creer que un buen producto debe puntuar alto en las ocho características a la vez. No. Perseguir las ocho por igual es la receta para gastar el triple y no destacar en ninguna. El estándar es un menú, no una lista de tareas obligatorias.

La pregunta que sí vale la pena es: en este producto, para este usuario, ¿qué característica es innegociable y cuál puede quedar en "suficiente"? Un sistema de pagos pone seguridad y fiabilidad por encima de todo, y aceptará una usabilidad correcta pero no deslumbrante. Un prototipo para validar una idea prioriza adecuación funcional y usabilidad, y puede permitirse una eficiencia mediocre porque nunca verá carga real.

Esta es exactamente la manera en que en Qirava usamos el modelo: no como una checklist para aprobar, sino como el tablero donde una conversación de producto se vuelve honesta. Antes de escribir un caso de prueba, antes de pelear por una fecha, ponemos las ocho características sobre la mesa y decidimos, en voz alta, cuáles son las dos o tres que este producto no puede fallar. Lo demás se atiende, pero no se persigue hasta la perfección.

Ese acto de elegir es lo que separa a un equipo que "quiere calidad" de uno que sabe qué calidad quiere. El primero discute sin fin porque nadie definió la palabra. El segundo señala el mapa, apunta a tres casillas y dice: aquí. Todo lo demás es negociable.

Elegir en qué ser excelente es una decisión de producto, no una renuncia a la calidad.

La próxima vez que alguien pida "software de calidad", no asientas. Pregunta cuál de las ocho. Convertir una palabra vaga en una elección concreta es, probablemente, el trabajo de QA más barato y más valioso que puedes hacer en todo el proyecto.