La arquitectura cliente-servidor es un modelo en el que una parte del sistema solicita datos o una acción y otra los proporciona. El cliente inicia una solicitud; el servidor la procesa y devuelve un resultado.
Parece sencillo, pero es uno de los modelos fundamentales para QA. Cuando empiezas a ver un producto así, muchos errores dejan de parecer «comportamientos extraños de la UI» y se convierten en puntos de fallo identificables: cliente, red, servidor, base de datos, integración externa, caché, cola o autorización.
Cómo funciona
En un producto web o móvil típico, el cliente es un navegador, una aplicación móvil u otro servicio. El usuario pulsa un botón, el cliente recopila datos y envía una solicitud. El servidor la recibe, comprueba permisos, valida la entrada, ejecuta la lógica de negocio y, si es necesario, accede a una base de datos o a sistemas externos.
- →El cliente puede ser un navegador, una aplicación móvil, otro servicio o un socio externo.
- →El servidor no siempre es un único proceso ni un monolito.
- →Entre cliente y servidor suelen intervenir pasarelas, balanceadores de carga, cachés, colas, bases de datos e integraciones externas.
Por eso, un solo clic puede desencadenar toda una cadena de acciones en lugar de una única operación.
Un ejemplo sencillo
Un usuario pulsa «Pagar pedido». El cliente envía una solicitud con el ID del pedido, el importe y los datos del usuario. El servidor comprueba si el pedido existe, si el usuario puede pagarlo y si su estado actual permite el pago. Después llama al proveedor de pagos, guarda el resultado y devuelve una respuesta al cliente.
El usuario solo ve el botón y el mensaje final. QA necesita ver toda la cadena. De lo contrario, resulta fácil atribuir el defecto a una causa equivocada.
Qué debe comprobar QA
- →Si se envió alguna solicitud.
- →Qué solicitud se envió exactamente.
- →Qué devolvió el servidor.
- →Cómo interpretó el cliente la respuesta.
- →Si los datos cambiaron en todos los lugares donde debían cambiar.
- →Si interviene un servicio externo o un entorno inestable.
Si la UI muestra un importe incorrecto, hay varias causas posibles: el servidor devolvió un valor erróneo, la base de datos contiene datos incorrectos, un servicio externo respondió de forma inesperada o el cliente representó incorrectamente una respuesta correcta. El síntoma visible es el mismo, pero los puntos de fallo difieren.
Las capas que se prueban con más frecuencia
- →Capa del cliente: si se envió la solicitud, se construyeron correctamente los parámetros y se mostró bien el resultado.
- →Capa del servidor: si funcionaron correctamente la validación, el control de acceso y la lógica de negocio.
- →Capa de datos: si se crearon, actualizaron o eliminaron los datos según lo esperado.
- →Capa de integración: cómo gestiona el sistema fallos, tiempos de espera agotados y respuestas inesperadas de servicios externos.
Dónde ayuda en la práctica
Primero, en la investigación de defectos. Quien solo ve la pantalla escribe «no funciona». Quien comprende la arquitectura escribe: la solicitud contenía un parámetro incorrecto; el servidor devolvió 403 aunque el rol debería tener acceso; la base de datos no se actualizó. El informe es mucho más preciso.
Segundo, en el diseño de pruebas. Comprender las capas de un escenario ayuda a diseñar comprobaciones más sólidas: recorrido correcto en la UI, errores de red, solicitudes repetidas, fallos parciales, datos incoherentes y problemas de integración.
Tercero, en la comunicación del equipo. Este modelo permite concretar: el problema está en el cliente, el servidor, los datos o el proveedor externo. Ahorra tiempo y facilita la clasificación de incidencias.
Ideas clave para QA
- →Una acción del usuario suele implicar varios pasos técnicos.
- →El mismo defecto visible de UI puede originarse en distintas capas del sistema.
- →Para aislar un problema, examina solicitud, respuesta, datos y dependencias, además de la pantalla.
- →Comprender la arquitectura cliente-servidor mejora la precisión de los informes y acelera las investigaciones.
Lecturas adicionales
- →En esta base de conocimiento: ¿Qué es una API? — introducción a la interfaz utilizada para comunicarse.
- →En esta base de conocimiento: HTTP y HTTPS — para comprender mejor la capa de transporte de solicitudes y respuestas.
- →En esta base de conocimiento: Métodos, códigos de estado y encabezados — para interpretar con mayor confianza las señales técnicas de la API.
Sigue una acción desde el navegador hasta el almacenamiento
Escenario ficticio: un estudiante guarda el nombre visible de su perfil. Se espera que una lectura posterior muestre el nombre nuevo para la misma cuenta autorizada. Una notificación de éxito solo demuestra que el cliente mostró un mensaje; no establece el estado guardado.
Capa Observación Qué puede demostrar
Navegador Acción, entrada, cuerpo de solicitud y tiempos Qué envió realmente el cliente
Red/API Método, URL, estado, cuerpo, ID de correlación La respuesta observada de la API
Registros del servicio Mismo ID de correlación y resultado de validación Qué ruta del servidor gestionó la solicitud, si hay registros disponibles
Almacenamiento Lectura de prueba autorizada del registro objetivo Valor guardado en el momento observado
Lectura posterior por API Respuesta GET para la misma cuenta Si la ruta de lectura expone el valor guardadoUsa una lectura de prueba autorizada o una fixture, en lugar de suponer que existe acceso a la base de datos. Los sistemas asíncronos pueden no prometer coherencia inmediata: acuerda primero la señal de finalización y el intervalo de tiempo. Si el navegador agota el tiempo después de enviar una escritura, inspecciona el resultado antes de reintentar. El servidor puede haberla confirmado ya.
Para aislar un fallo, compara observaciones contiguas. Los datos incorrectos en la solicitud apuntan a la preparación del cliente; una solicitud correcta con un error de validación documentado apunta a la interpretación del contrato o la entrada; una respuesta de éxito con datos ausentes exige investigar la escritura o el flujo asíncrono. Son líneas de investigación, no causas demostradas. Conserva marcas de tiempo e IDs de correlación y elimina los secretos de las evidencias.