En el tema anterior vimos los niveles de prueba: unitarias, integración, sistema y aceptación. Esos niveles indican dónde o con qué alcance probamos. En este tema veremos los tipos de prueba, que indican qué aspecto del producto queremos evaluar.
Una clasificación muy importante divide las pruebas en funcionales y no funcionales. Las pruebas funcionales revisan lo que el sistema hace. Las no funcionales revisan cómo lo hace y con qué calidad lo hace.
Un sistema puede cumplir una funcionalidad y aun así tener problemas graves si es lento, inseguro, difícil de usar o incompatible con los dispositivos esperados.
Las pruebas funcionales verifican que el sistema realice las funciones esperadas según requisitos, reglas de negocio y criterios de aceptación.
Responden preguntas como:
Por ejemplo, si una aplicación permite transferir dinero, una prueba funcional verificará que el monto se descuente de una cuenta, se acredite en la otra y se registre la operación.
Algunos ejemplos comunes son:
Estas pruebas suelen estar muy conectadas con requisitos funcionales, historias de usuario, casos de uso y criterios de aceptación.
Dentro de las pruebas funcionales podemos distinguir pruebas positivas y negativas.
| Tipo | Qué verifica | Ejemplo |
|---|---|---|
| Positiva | Que el sistema funcione correctamente con datos válidos y condiciones esperadas. | Ingresar usuario y contraseña correctos para iniciar sesión. |
| Negativa | Que el sistema maneje correctamente datos inválidos, errores o acciones no permitidas. | Ingresar contraseña incorrecta y comprobar que el acceso sea rechazado. |
Un error frecuente es probar solo el camino exitoso. Las pruebas negativas son esenciales porque los usuarios pueden equivocarse, los datos pueden llegar incompletos y los sistemas externos pueden fallar.
Las pruebas no funcionales evalúan atributos de calidad del sistema. No se enfocan únicamente en qué hace el sistema, sino en cómo se comporta bajo ciertas condiciones.
Responden preguntas como:
Estas pruebas suelen depender mucho del contexto. No todas las aplicaciones necesitan el mismo nivel de rendimiento, seguridad o compatibilidad.
| Tipo no funcional | Qué evalúa | Ejemplo |
|---|---|---|
| Rendimiento | Tiempo de respuesta, velocidad y uso de recursos. | La búsqueda debe responder en menos de 3 segundos. |
| Carga | Comportamiento con cierta cantidad de usuarios o transacciones. | El sistema debe soportar 500 usuarios simultáneos. |
| Seguridad | Protección de datos, permisos y accesos. | Un usuario común no debe acceder a funciones administrativas. |
| Usabilidad | Facilidad de uso y claridad para el usuario. | Un usuario nuevo debe completar el registro sin ayuda externa. |
| Compatibilidad | Funcionamiento en plataformas, navegadores o dispositivos esperados. | La aplicación debe funcionar en Chrome, Firefox y Edge. |
| Accesibilidad | Uso por personas con distintas capacidades. | Los campos deben tener etiquetas legibles por lectores de pantalla. |
La diferencia puede entenderse con una pregunta simple:
Ejemplo con una tienda en línea:
Ambas miradas son necesarias. Un carrito que calcula bien pero tarda veinte segundos en responder puede ser técnicamente correcto, pero poco aceptable para usuarios reales.
Las pruebas de rendimiento evalúan cómo responde el sistema en términos de velocidad, estabilidad y uso de recursos. Son importantes cuando el tiempo de respuesta afecta la experiencia del usuario o la operación del negocio.
Ejemplos de preguntas de rendimiento:
En este curso solo introducimos el concepto. Más adelante, el curso de pruebas de rendimiento permitirá profundizar técnicas y herramientas específicas.
Las pruebas de seguridad buscan detectar riesgos relacionados con accesos no autorizados, exposición de datos, permisos incorrectos o vulnerabilidades.
Ejemplos básicos:
La seguridad no se resuelve únicamente con testing, pero las pruebas ayudan a encontrar problemas importantes antes de que lleguen a producción.
Las pruebas de usabilidad evalúan si el sistema es fácil de entender y utilizar. Una funcionalidad puede estar correctamente programada, pero ser difícil de usar si los textos son confusos, los pasos no son claros o los errores no orientan al usuario.
Preguntas típicas:
Estas pruebas pueden incluir observación de usuarios reales, revisión heurística o validación con representantes del negocio.
Las pruebas de compatibilidad verifican que el sistema funcione en los entornos requeridos: navegadores, dispositivos, sistemas operativos, resoluciones, versiones de base de datos o configuraciones específicas.
Ejemplos:
No siempre es posible probar todas las combinaciones. Por eso se priorizan las más usadas, críticas o comprometidas contractualmente.
Las pruebas de accesibilidad buscan que el software pueda ser utilizado por personas con distintas capacidades. Esto incluye usuarios que navegan con teclado, lectores de pantalla, alto contraste, zoom o tecnologías de asistencia.
Algunos aspectos básicos son:
La accesibilidad también es calidad. No debe tratarse como un detalle final, especialmente en aplicaciones públicas o de uso masivo.
La confiabilidad evalúa si el sistema puede funcionar correctamente durante un período de tiempo y responder de forma controlada ante problemas.
La recuperación analiza cómo se comporta el sistema después de una falla. Por ejemplo:
Estas pruebas son especialmente importantes en sistemas que no pueden permitirse pérdida de datos o interrupciones frecuentes.
Los tipos de prueba y los niveles de prueba no son lo mismo, pero se combinan. Un tipo de prueba puede ejecutarse en distintos niveles.
| Tipo de prueba | Nivel posible | Ejemplo |
|---|---|---|
| Funcional | Unitaria | Verificar que una función calcule correctamente un impuesto. |
| Funcional | Sistema | Comprobar un flujo completo de compra. |
| Seguridad | Integración o sistema | Verificar que una API rechace usuarios sin permiso. |
| Rendimiento | Sistema | Medir tiempo de respuesta de una búsqueda con muchos usuarios. |
| Usabilidad | Aceptación | Observar si usuarios reales completan una tarea sin ayuda. |
El nivel indica el alcance; el tipo indica el atributo que evaluamos.
Tomemos una funcionalidad conocida: inicio de sesión.
| Tipo de prueba | Ejemplo |
|---|---|
| Funcional positiva | Ingresar correo y contraseña correctos y comprobar que se abre la pantalla principal. |
| Funcional negativa | Ingresar contraseña incorrecta y comprobar que el acceso se rechaza. |
| Seguridad | Intentar acceder a una página privada sin sesión activa. |
| Usabilidad | Revisar si el mensaje de error ayuda al usuario a corregir el problema. |
| Rendimiento | Medir si el inicio de sesión responde en menos de dos segundos. |
| Compatibilidad | Probar el flujo en los navegadores soportados. |
| Accesibilidad | Comprobar que el formulario pueda completarse usando teclado. |
Una misma funcionalidad puede necesitar varios tipos de prueba si es importante para el producto.
No siempre se pueden ejecutar todos los tipos de prueba con la misma profundidad. La selección depende del contexto, los riesgos y los recursos disponibles.
Algunas preguntas útiles son:
La estrategia de testing debe enfocarse en los riesgos más relevantes, no en una lista genérica de pruebas.
Al trabajar con tipos de prueba, algunos errores frecuentes son:
Estos errores pueden producir un sistema que funciona en casos básicos, pero falla cuando se enfrenta a condiciones reales de uso.
Para aplicar bien los tipos de prueba conviene:
Una buena estrategia combina tipos de prueba para obtener una visión más completa de la calidad.
Las pruebas funcionales y no funcionales permiten observar el software desde perspectivas complementarias. Las primeras responden si el sistema hace lo correcto; las segundas responden si lo hace con la calidad necesaria.
Un producto confiable necesita ambas miradas. No alcanza con que una operación dé el resultado correcto si tarda demasiado, expone datos, confunde al usuario o falla en los dispositivos requeridos.
En el próximo tema estudiaremos la diferencia entre pruebas manuales y automatizadas, para comprender cuándo conviene usar criterio humano, cuándo conviene automatizar y cómo se complementan ambos enfoques.