Fundamentos del testing
¿Qué es el testing y por qué es importante?
El testing consiste en comprobar que una aplicación hace exactamente lo que se supone que debe hacer, de forma manual o automática. No se trata solo de que “no falle”, sino de verificar de manera sistemática que cada comportamiento esperado ocurre y que los errores se gestionan de forma controlada.
En una aplicación web real, esto implica asegurarse de que una ruta responde correctamente, que un formulario valida los datos adecuados, que una operación guarda información coherente en la base de datos y que los fallos no se manifiestan directamente ante el usuario final ni comprometen la estabilidad del sistema.
Imagina una aplicación de gestión de usuarios. Un usuario introduce sus credenciales y pulsa “Iniciar sesión”. Si no ocurre nada, si el acceso se concede cuando no debería o si aparece un error inesperado, el sistema tiene un problema. El testing existe para detectar ese tipo de fallos antes de que lleguen a producción.
El testing es como revisar una aplicación de banca online antes de publicarla. ¿Puedes iniciar sesión? ¿Las transferencias se realizan solo si hay saldo suficiente? ¿El historial de movimientos muestra datos correctos? ¿La aplicación sigue funcionando bien con miles de usuarios simultáneos? Si no se prueba, el sistema puede funcionar “a medias” y fallar justo en los momentos críticos.
Esta analogía pone el foco en una idea clave: que una aplicación cargue no significa que sea fiable, segura ni usable.
Por qué el testing es imprescindible
No aplicar testing de forma sistemática tiene consecuencias claras y acumulativas:
- Es fácil romper funcionalidades existentes al introducir cambios aparentemente pequeños.
- Los errores llegan al usuario final, afectando a la confianza, la credibilidad y la imagen del producto.
- Los fallos en producción suelen ser más caros de corregir, tanto en tiempo como en impacto.
- Los problemas de rendimiento, seguridad o accesibilidad suelen detectarse demasiado tarde si no se prueban de forma explícita.
El testing actúa como una capa de seguridad transversal que acompaña al código durante toda su evolución, desde las primeras funciones hasta la aplicación completa en producción.
Tipos de pruebas en aplicaciones web: una visión global
En el desarrollo profesional de aplicaciones web no existe un único tipo de prueba. Las pruebas se agrupan en categorías, según qué aspecto del sistema se quiere validar. Entender esta clasificación ayuda a no confundir objetivos y a diseñar una estrategia de testing coherente.
A alto nivel, podemos distinguir cuatro grandes bloques:
- Pruebas funcionales
- Pruebas no funcionales
- Pruebas de seguridad
- Pruebas de entorno y red
Cada bloque cubre riesgos distintos y complementarios.
Pruebas funcionales: verificar que la aplicación hace lo correcto
Las pruebas funcionales comprueban que el sistema cumple los requisitos funcionales definidos, es decir, que hace lo que se espera desde el punto de vista del negocio y del usuario.
Dentro de esta categoría se incluyen varios niveles.
1. Pruebas unitarias: una pieza aislada
Una prueba unitaria verifica una parte pequeña y concreta del sistema, sin depender del resto de la aplicación. En una aplicación web, suele aplicarse a funciones de validación, cálculos o lógica de negocio.
Por ejemplo, una función que incrementa el número de notificaciones no leídas de un usuario.
Pseudocódigo ilustrativo:
func incrementarNotificaciones(usuario):
usuario.notificaciones = usuario.notificaciones + 1
Prueba conceptual:
usuario.notificaciones = 0
incrementarNotificaciones(usuario)
esperado: usuario.notificaciones == 1
Este ejemplo es pseudocódigo. Su objetivo no es mostrar sintaxis real, sino centrar la atención en la lógica que se está probando. En una prueba unitaria no importa la base de datos, el servidor ni la interfaz, solo el comportamiento de esa pieza aislada.
Una prueba unitaria valida reglas internas del sistema sin depender del entorno.
2. Pruebas de integración: componentes que trabajan juntos
Las pruebas de integración comprueban que varias partes del sistema colaboran correctamente. Aquí ya no se prueba una función aislada, sino su interacción con otros componentes.
En una aplicación web típica, un ejemplo sería:
– Un endpoint recibe datos.
– Valida la información.
– Guarda el resultado en la base de datos.
– Devuelve una respuesta coherente.
Pseudocódigo conceptual:
peticion POST /registro
→ validar datos
→ guardar usuario en base de datos
→ responder con éxito o error
La prueba de integración verifica que todo ese flujo funciona como conjunto y que los datos pasan correctamente de una capa a otra.
Este nivel detecta errores que no aparecen en pruebas unitarias, como configuraciones incorrectas, dependencias mal conectadas o datos mal transformados.
3. Pruebas de regresión: evitar que lo que funcionaba deje de hacerlo
Las pruebas de regresión aseguran que cambios nuevos no rompen funcionalidades existentes. No validan algo nuevo, sino que revalidan comportamientos ya conocidos.
Cada vez que se corrige un bug o se añade una funcionalidad, las pruebas de regresión ayudan a garantizar que el sistema sigue comportándose como antes en los casos críticos.
4. Pruebas de interfaz de usuario
Estas pruebas se centran en la interacción visual y funcional de la aplicación: formularios, botones, flujos de navegación, mensajes de error visibles.
No prueban lógica interna, sino que la interfaz responde correctamente a las acciones del usuario.
5. Pruebas de aceptación
Las pruebas de aceptación validan que la aplicación cumple las expectativas del usuario o del cliente, según criterios definidos previamente. No se centran en cómo está construida la aplicación, sino en si resuelve el problema para el que fue creada.
Suelen ser el último filtro antes de considerar una aplicación lista para producción.
Pruebas no funcionales: cómo se comporta la aplicación
Las pruebas no funcionales no validan qué hace la aplicación, sino cómo lo hace.
1. Pruebas de rendimiento
Evalúan tiempos de respuesta, consumo de recursos y comportamiento bajo carga. Responden a preguntas como:
- ¿La aplicación sigue siendo usable con muchos usuarios simultáneos?
- ¿Las respuestas son aceptables en escenarios reales?
2. Pruebas de usabilidad
Analizan si la aplicación es fácil de usar, comprensible y coherente para el usuario final. No son puramente técnicas, pero influyen directamente en la calidad percibida del producto.
3. Pruebas de compatibilidad
Verifican que la aplicación funciona correctamente en distintos navegadores, dispositivos y tamaños de pantalla.
4. Pruebas de accesibilidad
Comprueban que la aplicación puede ser utilizada por personas con distintas capacidades, siguiendo criterios como navegación por teclado, lectores de pantalla o contraste visual adecuado.
Pruebas de seguridad: proteger el sistema y los datos
Las pruebas de seguridad se centran en detectar vulnerabilidades y riesgos.
Incluyen aspectos como:
- Validación de autenticación.
- Control de autorización y permisos.
- Protección frente a accesos no autorizados.
- Detección de vulnerabilidades comunes.
Estas pruebas son críticas en aplicaciones que gestionan datos sensibles o acciones importantes.
Pruebas de entorno y red
Este tipo de pruebas valida cómo se comporta la aplicación en condiciones reales de infraestructura.
1. Pruebas de API
Comprueban que los endpoints responden correctamente, con los códigos de estado adecuados y datos coherentes, independientemente del frontend.
2. Pruebas de recuperación ante fallos
Evalúan qué ocurre si un servicio cae, si la base de datos no responde o si hay problemas de red. El objetivo es verificar que el sistema falla de forma controlada y recuperable.
Qué se debe testear y cuándo hacerlo
No todo requiere el mismo nivel de pruebas, pero sí todo lo que sea crítico para el funcionamiento del sistema.
En una aplicación web real, esto incluye preguntas como:
- ¿Un formulario valida correctamente los datos antes de enviarlos?
- ¿Una operación sensible se ejecuta solo con permisos adecuados?
- ¿La aplicación responde bien bajo carga?
- ¿Los datos están protegidos frente a accesos indebidos?
Una regla práctica es sencilla:
si esa parte falla, ¿la aplicación sigue siendo usable, segura y fiable? Si la respuesta es no, entonces debe testearse.