Qué es la calidad
En resumen: La calidad es hasta qué punto un producto da a las personas a su alrededor lo que necesitan. La ISO/IEC 25010:2023 la divide en nueve características: una para lo que hace el sistema y ocho para lo bien que lo hace.
Problema
Todo funciona. Los clientes se van
Después de lanzar la tienda nueva, pasan los 300 tests. El envío se calcula bien, los códigos promocionales funcionan, y cancelar un pedido solo se permite antes de enviarlo.
Pero la página del carrito tarda 9 segundos en cargar en el teléfono. La mitad de los clientes la cierra antes de ver el total. El programa hace todo bien. Y aun así es malo.
Así que «bien» no es toda la calidad. ¿Qué es el resto?
La idea
¿Calidad para quién?
Una misma tienda es «buena» por razones distintas para personas distintas:
- el cliente quiere encontrar el producto, pagar rápido y que no le roben la tarjeta;
- el almacén quiere que el pedido llegue a su programa en el formato correcto;
- contabilidad quiere que los totales y los descuentos cuadren al céntimo;
- el equipo de desarrollo, que el año que viene cambiará el umbral de envío, quiere encontrarlo en un solo lugar.
Calidad es hasta qué punto el producto da a estas personas lo que necesitan: lo dicho y lo no dicho. Por eso la primera pregunta no es «¿es bueno?», sino «¿para quién y en qué?».
La idea
Las nueve características
El estándar ISO/IEC 25010:2023 ordena la calidad del producto en nueve características. Es un modelo de calidad (quality model): una lista para que no olvides nada.
| Característica | En la tienda |
|---|---|
| Adecuación funcional (functional suitability) | El envío es gratis desde 50 €, el descuento se resta bien. |
| Eficiencia de desempeño (performance efficiency) | El carrito se abre en menos de 2 segundos con 500 clientes a la vez. |
| Compatibilidad (compatibility) | El pedido llega al programa del almacén y a la mensajería en el formato de cada uno. |
| Capacidad de interacción (interaction capability) | Un cliente con lector de pantalla pide por su cuenta; un error dice qué hacer. |
| Fiabilidad (reliability) | Si la mensajería no responde, el pedido se guarda y se envía más tarde. |
| Seguridad (security) | Nadie ve pedidos ajenos; un código promocional no se puede adivinar. |
| Mantenibilidad (maintainability) | El umbral de 50 € se cambia en un solo lugar, y los tests dicen qué se ve afectado. |
| Flexibilidad (flexibility) | La tienda aguanta cinco veces más clientes en el Black Friday y abre en un país nuevo. |
| Protección (safety) | Los alimentos sin alérgenos indicados no se venden: el sistema los retiene en lugar de mostrarlos. |
Los nombres en español son la traducción de este curso. Los nombres en inglés son los que encontrarás en el estándar y en el examen.
Más precisamente, para curiosos
La ISO/IEC 25010 define la calidad del producto como el grado en que un producto satisface las necesidades declaradas e implícitas de sus partes interesadas. La edición de 2023 cambió varias cosas respecto a 2011:
- la protección (safety) es una característica nueva, la novena;
- la usabilidad (usability) ahora se llama capacidad de interacción (interaction capability) y tiene subcaracterísticas nuevas, por ejemplo la inclusividad (inclusivity) y la autodescriptividad (self-descriptiveness);
- la portabilidad (portability) ahora se llama flexibilidad (flexibility) e incluye la escalabilidad (scalability).
Cada característica tiene subcaracterísticas. La adecuación funcional, por ejemplo, es completitud, corrección y pertinencia. El modelo de calidad en uso (quality in use: cómo le va a la persona que usa el producto) está desde 2023 en un estándar aparte, la ISO/IEC 25019.
En español, security y safety suelen llamarse ambas «seguridad». En este curso, como en la versión en español del modelo, «seguridad» es security y «protección» es safety.
Ejercicio
Clasifica las quejas
1. Quejas de clientes. Todas las quejas son reales. ¿A qué característica pertenece cada una?
La idea
Funcional y no funcional
La primera de las nueve características dice qué hace el sistema: con un carrito de 50 €, el envío cuesta 0 €. Esos son los requisitos funcionales.
Las otras ocho dicen qué tan bien lo hace: qué tan rápido, para quién, qué tan seguro, cuánto tiempo sin interrupción, qué tan rápido se puede cambiar. Esos son los requisitos no funcionales (non-functional).
Los no funcionales son los que más se olvidan. Nadie los dice, porque «se sobreentienden»: la tienda, claro, tiene que ser rápida y segura. Hasta que resulta que no lo es. En la historia del principio todos los tests funcionales pasaron. Faltaba un requisito no funcional.
Pruébalo
¿Qué hace, o qué tan bien lo hace?
La idea
La calidad se acuerda
«El sitio debería ser rápido» no se puede comprobar. ¿Qué tan rápido? ¿Qué página? ¿Con cuántos clientes? ¿En qué teléfono?
La frase se vuelve un requisito cuando recibe una medida: «El 95 % de las aperturas del carrito tardan menos de 2 segundos con 500 clientes a la vez, en red móvil». Ahora el tester sabe qué medir, y el dueño de la tienda sabe qué se prometió.
Las características tiran en direcciones opuestas. Entrar con un código por SMS hace la tienda más segura y más lenta para el cliente. Por eso no todas pesan igual, y cuánto pesa cada una es una decisión del negocio. En la tienda, la velocidad y la seguridad del pago pesan más que la protección. En el software de un hospital es al revés. Es el principio «las pruebas dependen del contexto», aplicado a los requisitos.
La idea
Verificar y validar la calidad
Las dos preguntas de la primera lección también valen aquí.
- Verificación: el requisito dice «menos de 2 segundos» y lo medido es 1,8 segundos. Pasa.
- Validación: pero ¿son 2 segundos el límite correcto? ¿Se midió donde están los clientes: en un teléfono, en una red móvil? Si los clientes aun así se van, el requisito está mal, no el programa.
Un requisito no funcional puede tener un defecto como cualquier otro. Y lo atrapa lo mismo: una pregunta y un ejemplo concreto, antes de escribir código.
Test