La Distincion Fundamental
Todo testing de software cae en dos categorias:
Testing funcional verifica QUE hace el sistema — sus features, reglas de negocio, procesamiento de datos e interacciones. El formulario de login acepta credenciales validas? La busqueda retorna resultados correctos?
Testing no funcional verifica COMO el sistema ejecuta sus funciones — velocidad, seguridad, fiabilidad, usabilidad y otros atributos de calidad. La pagina carga en menos de 2 segundos? El sistema maneja 10,000 usuarios concurrentes?
Analogia: Probar un auto. Testing funcional: El motor arranca? Los frenos detienen el auto? Testing no funcional: Que tan rapido acelera? Que tan silencioso es? Que tan eficiente es el combustible?
Tipos de Testing Funcional
Testing de Features
Verificar que cada feature funciona: login, registro, busqueda, carrito, pagos.
Testing de Reglas de Negocio
Verificar logica de negocio: precios, control de acceso, flujos de aprobacion, reglas de cumplimiento.
Testing de UI
Verificar interfaz: formularios, botones, navegacion, mensajes de error, contenido dinamico.
Testing de API
Verificar APIs: formatos de respuesta, operaciones CRUD, manejo de errores, paginacion.
Testing de Base de Datos
Verificar datos: creacion/lectura/actualizacion/eliminacion, integridad, transacciones, procedimientos almacenados.
Tipos de Testing No Funcional
Rendimiento
- Tiempo de respuesta: Que tan rapido responde?
- Throughput: Cuantas transacciones por segundo?
- Utilizacion de recursos: Cuanto CPU, memoria y disco usa?
- Escalabilidad: Puede manejar carga creciente?
Seguridad
- Autenticacion: Pueden entrar usuarios no autorizados?
- Autorizacion: Pueden acceder recursos mas alla de sus permisos?
- Proteccion de datos: Datos sensibles cifrados?
- Escaneo de vulnerabilidades: OWASP Top 10?
Usabilidad
- Aprendibilidad: Nuevos usuarios descubren el sistema sin entrenamiento?
- Eficiencia: Usuarios experimentados completan tareas rapido?
- Accesibilidad: Usuarios con discapacidades pueden usarlo (WCAG)?
- Recuperacion de errores: Pueden recuperarse de errores facilmente?
Fiabilidad
- Disponibilidad: Que porcentaje del tiempo esta operativo (99.9%)?
- Tolerancia a fallos: Maneja fallas de componentes adecuadamente?
- Recuperabilidad: Que tan rapido se recupera de fallas?
Compatibilidad
- Navegadores: Chrome, Firefox, Safari, Edge
- Dispositivos: Desktop, tablet, mobile
- Sistemas operativos: Windows, macOS, Linux, iOS, Android
Mantenibilidad
- Calidad del codigo, modularidad, testeabilidad, documentacion.
Portabilidad
- Instalabilidad, adaptabilidad, reemplazabilidad.
ISO 25010: El Modelo de Calidad
| Caracteristica | Categoria | Pregunta Clave |
|---|---|---|
| Adecuacion Funcional | Funcional | Hace lo que debe? |
| Eficiencia de Rendimiento | No Funcional | Es rapido y eficiente? |
| Compatibilidad | No Funcional | Funciona con otros sistemas? |
| Usabilidad | No Funcional | Es facil de usar? |
| Fiabilidad | No Funcional | Es confiable? |
| Seguridad | No Funcional | Esta protegido? |
| Mantenibilidad | No Funcional | Es facil de cambiar? |
| Portabilidad | No Funcional | Puede moverse a nuevos ambientes? |
Solo una de ocho caracteristicas es funcional. Esto resalta cuanto de la calidad del software es no funcional.
Tabla Comparativa
| Aspecto | Testing Funcional | Testing No Funcional |
|---|---|---|
| Prueba | Que hace el sistema | Como se desempena |
| Basado en | Requisitos, user stories | Atributos de calidad, SLAs |
| Ejemplos | Login, busqueda, pago | Rendimiento, seguridad, usabilidad |
| Herramientas | Selenium, Cypress, Postman | JMeter, k6, OWASP ZAP, Lighthouse |
| Quien | Ingenieros QA | QA + especialistas |
| Cuando | Durante todo el desarrollo | Despues de estabilidad funcional |
Ejercicio: Clasifica Actividades de Testing
Clasifica cada actividad como Funcional (F) o No Funcional (NF). Para NF, especifica la caracteristica.
- Verificar que un usuario puede registrarse con email valido
- Verificar que la pagina de registro carga en menos de 3 segundos
- Verificar que el formulario es accesible con lector de pantalla
- Verificar que emails duplicados son rechazados
- Verificar que el sistema maneja 500 registros simultaneos
- Verificar que funciona en Chrome, Firefox y Safari
- Verificar que las contrasenas se hashean antes de almacenar
- Verificar que el email de confirmacion se envia en menos de 1 minuto
- Verificar que el formulario muestra mensajes de error claros
- Verificar que el sistema se recupera si el servicio de email cae
- Verificar que la API retorna 201 para creacion exitosa
- Verificar que el formulario mobile es usable en pantalla de 5 pulgadas
Pista
Pregunta: "Estoy probando QUE hace el sistema (feature, regla de negocio) o COMO lo hace (velocidad, seguridad, facilidad de uso)?"Solucion
- F — Feature (funcionalidad de registro)
- NF — Rendimiento — Tiempo de respuesta
- NF — Usabilidad (Accesibilidad) — Cumplimiento de accesibilidad
- F — Regla de negocio (restriccion de unicidad)
- NF — Rendimiento (Carga) — Capacidad del sistema
- NF — Compatibilidad (Navegador) — Soporte cross-browser
- NF — Seguridad — Proteccion de datos (hashing)
- NF — Rendimiento / Fiabilidad — Oportunidad de proceso dependiente
- F — Comportamiento de UI (mostrar errores es un feature). La claridad es usabilidad.
- NF — Fiabilidad (Tolerancia a fallos) — Degradacion elegante
- F — Comportamiento de API (codigo de estado correcto es contrato funcional)
- NF — Usabilidad — Facilidad de uso en factor de forma especifico
Cuando Probar Que
Funcional primero. No tiene sentido probar rendimiento si el feature no funciona. Asegurar correccion funcional antes de invertir en no funcional.
No funcional requiere builds estables. Resultados de rendimiento no tienen sentido si la app se cae a mitad del test.
Planificar no funcional temprano. Aunque se ejecuta despues, planificar temprano. Requisitos de rendimiento, seguridad y accesibilidad deben definirse desde el inicio.
Tips Profesionales
Tip 1: Requisitos no funcionales son frecuentemente implicitos. Los stakeholders rara vez dicen “la pagina debe cargar en 2 segundos.” Lo asumen. QA debe preguntar.
Tip 2: Fallas no funcionales causan mas dano. Un bug funcional afecta un feature. Una brecha de seguridad afecta toda la organizacion.
Tip 3: Muchos equipos ignoran testing no funcional. 500 tests funcionales y cero de rendimiento o seguridad es comun. Esta brecha te alcanza en produccion.
Conclusiones Clave
- Funcional verifica QUE hace el sistema; no funcional verifica COMO se desempena
- ISO 25010 define ocho caracteristicas — solo una es funcional
- Tipos no funcionales: rendimiento, seguridad, usabilidad, fiabilidad, compatibilidad, mantenibilidad, portabilidad
- Probar funcional primero, luego no funcional con build estable
- Requisitos no funcionales son frecuentemente implicitos — QA debe preguntar proactivamente
- Muchos equipos subinvierten en testing no funcional, creando brechas que aparecen en produccion