Arquitectura Web para QA

Por qué los ingenieros QA necesitan entender la arquitectura web #

Cuando encuentras un bug en una aplicación web, la primera pregunta que hará un developer es: “¿Es un problema de frontend o de backend?” Si no puedes responder esa pregunta, tu reporte de bug va a rebotar entre equipos, perdiendo el tiempo de todos.

Entender la arquitectura web te transforma de un tester que dice “está roto” a un ingeniero QA que dice “el API retorna un status 200 pero el response body contiene un array vacío cuando el usuario tiene items en su carrito — esto parece ser un problema de obtención de datos en el backend.”

Ese nivel de precisión se gana el respeto de los developers y hace que los bugs se corrijan más rápido.

El modelo cliente-servidor #

Toda aplicación web sigue el mismo patrón fundamental: un cliente envía un request, y un servidor envía un response.

El lado del cliente #

El cliente casi siempre es un navegador web — Chrome, Firefox, Safari, Edge. El trabajo del navegador es:

1. Enviar HTTP requests a los servidores
2. Recibir responses (HTML, CSS, JavaScript, imágenes, datos)
3. Renderizar la interfaz visual que ve el usuario
4. Ejecutar JavaScript para hacer la página interactiva

Las aplicaciones web modernas hacen trabajo significativo en el lado del cliente. Una aplicación React o Angular puede recibir una página HTML mínima y luego construir toda la interfaz usando JavaScript. Esto importa para testing porque los bugs del lado del cliente se comportan diferente a los bugs del lado del servidor.

El lado del servidor #

El servidor recibe requests, los procesa y retorna responses. Un servidor web típico:

1. Recibe el HTTP request
2. Lo enruta al handler apropiado
3. Ejecuta lógica de negocio (validar input, procesar datos, aplicar reglas)
4. Consulta la base de datos si es necesario
5. Construye y envía el HTTP response

Los servidores corren en frameworks como Express (Node.js), Django (Python), Spring (Java) o Rails (Ruby). Cada framework tiene sus propios patrones y categorías de bugs comunes.

La capa de base de datos #

Detrás del servidor se encuentra una o más bases de datos que almacenan datos persistentes — cuentas de usuario, catálogos de productos, registros de transacciones. La capa de base de datos introduce su propia clase de bugs:

• Datos no guardados correctamente
• Queries retornando datos obsoletos
• Race conditions cuando múltiples usuarios modifican el mismo registro
• Datos inconsistentes entre tablas

Cómo funciona HTTP #

HTTP (HyperText Transfer Protocol) es el lenguaje que usan clientes y servidores para comunicarse. Cada interacción que ves en un navegador web — cargar una página, enviar un formulario, obtener datos — es una conversación HTTP.

El ciclo request-response #

Cliente (Navegador)                 Servidor
     |                                |
     |--- HTTP Request (GET /home) -->|
     |                                | Procesa el request
     |                                | Consulta base de datos
     |<-- HTTP Response (200 OK) -----|
     |    HTML + CSS + JS             |
     |                                |
     | El navegador renderiza         |

Métodos HTTP importantes para testing #

Códigos de status HTTP #

Los códigos de status te dicen qué pasó en el servidor. Como ingeniero QA, necesitas conocer estas categorías:

• 2xx (Éxito): 200 OK, 201 Created, 204 No Content
• 3xx (Redirección): 301 Permanente, 302 Temporal, 304 Not Modified
• 4xx (Error del cliente): 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 422 Unprocessable Entity
• 5xx (Error del servidor): 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable

Cuando un usuario ve una página en blanco, el código de status te dice si el servidor falló (5xx), el recurso no existe (404), o el usuario no está autorizado (401/403).

Patrones de arquitectura web #

Arquitectura monolítica #

Todo corre en una sola aplicación. El frontend, la lógica backend y el acceso a base de datos se despliegan juntos. Los bugs en un área pueden afectar todo el sistema.

Impacto en testing: Más fácil configurar ambientes de test, pero más difícil aislar fallas. Un problema de base de datos puede manifestarse como un error de UI.

Arquitectura de microservicios #

La aplicación se divide en servicios pequeños e independientes. Un servicio de usuarios maneja autenticación, un servicio de productos gestiona inventario, un servicio de órdenes procesa compras.

Impacto en testing: Cada servicio puede fallar independientemente. Necesitas probar qué pasa cuando un servicio está caído mientras otros siguen funcionando. El testing de integración se vuelve crítico.

Arquitectura serverless #

Las funciones se ejecutan bajo demanda en la nube (AWS Lambda, Google Cloud Functions). No hay servidores permanentes que gestionar.

Impacto en testing: Los cold starts pueden causar picos de latencia. Las funciones tienen límites de tiempo de ejecución. El testing debe considerar ejecución concurrente y statelessness.

El recorrido completo de un request #

Cuando un usuario escribe una URL y presiona Enter, esto es lo que realmente sucede:

1. Resolución DNS: El navegador busca la dirección IP para el nombre de dominio
2. Conexión TCP: El navegador establece una conexión con el servidor
3. Handshake TLS: Si es HTTPS, se negocia el cifrado
4. HTTP Request: El navegador envía el request
5. Load Balancer: Distribuye el request a un servidor disponible
6. Servidor web: Recibe y enruta el request
7. Lógica de aplicación: Procesa el request, consulta bases de datos
8. Response: El servidor envía de vuelta HTML, JSON u otros datos
9. Renderizado del navegador: Parsea HTML, carga CSS, ejecuta JavaScript
10. Llamadas API: JavaScript hace requests adicionales para datos dinámicos

Cada paso es un punto potencial de falla y, por lo tanto, una oportunidad de testing.

Investigación práctica de arquitectura para QA #

Ahora que entiendes la teoría, vamos a aplicarla a escenarios reales de testing.

Leyendo tráfico de red #

Abre Chrome DevTools (F12), ve a la pestaña Network y carga cualquier página web. Verás cada request que hace el navegador:

1. Request del documento: La página HTML inicial
2. Assets estáticos: Archivos CSS, bundles de JavaScript, imágenes, fuentes
3. Llamadas API: Requests XHR o Fetch para datos dinámicos
4. Requests de terceros: Analytics, ads, recursos de CDN

Para cada request, observa:

• Código de status: ¿Fue exitoso?
• Tiempo: ¿Cuánto tardó?
• Tamaño: ¿Cuántos datos se transfirieron?
• Headers: ¿Qué metadata se envió y recibió?

Identificando la arquitectura desde el navegador #

Puedes determinar mucho sobre la arquitectura de una aplicación solo observando:

Single Page Application (SPA): La carga inicial obtiene un bundle de JavaScript. Las navegaciones siguientes no disparan recargas completas de página — solo llamadas API para datos. Busca frameworks como React, Angular o Vue en el código fuente.

Server-Side Rendered (SSR): Cada navegación de página dispara un response HTML completo. El HTML contiene todo el contenido de la página. Se necesita menos JavaScript para el renderizado inicial.

Híbrido: La carga inicial es renderizada por el servidor para SEO y performance, luego el framework del lado del cliente toma el control para interacciones siguientes (patrones de Next.js, Nuxt.js).

Ejercicio: Mapear la arquitectura de una aplicación #

Elige una aplicación web que uses regularmente (un sitio de e-commerce, una herramienta de gestión de proyectos, una plataforma de redes sociales). Usando DevTools del navegador:

1. Carga la página principal y cuenta cuántos HTTP requests se hacen
2. Navega a otra página — ¿hace una recarga completa o una llamada API?
3. Envía un formulario — ¿qué método HTTP y endpoint usa?
4. Revisa los headers del response buscando Server, X-Powered-By o Via que revelen el stack tecnológico

Documenta tus hallazgos en este formato:

Bugs comunes relacionados con la arquitectura #

Entender la arquitectura te ayuda a predecir dónde aparecerán los bugs:

Construyendo tu checklist de arquitectura #

Para cada proyecto nuevo, crea un mapa de arquitectura antes de empezar a probar:

1. ¿Cuál es la tecnología frontend? Esto determina qué bugs específicos del navegador buscar
2. ¿Cómo se comunica el frontend con el backend? ¿REST API, GraphQL, WebSocket?
3. ¿Qué base de datos se usa? Las bases de datos SQL tienen modos de falla diferentes a NoSQL
4. ¿Hay una capa de caching? Redis, Memcached o caching de CDN afectan la frescura de los datos
5. ¿Qué servicios de terceros están integrados? Procesadores de pago, servicios de email, analytics — cada uno es una dependencia que puede fallar

Puntos clave #

• Las aplicaciones web siguen el modelo cliente-servidor: el navegador envía requests, el servidor procesa y responde
• Los métodos HTTP (GET, POST, PUT, DELETE) y los códigos de status (2xx, 4xx, 5xx) son el vocabulario de la comunicación web
• Los patrones de arquitectura (monolítico, microservicios, serverless) introducen diferentes desafíos de testing
• Entender el recorrido completo del request te ayuda a ubicar dónde ocurren las fallas
• DevTools del navegador son tu herramienta principal para investigar la arquitectura web
• El conocimiento de arquitectura transforma reportes de bugs vagos en reportes precisos y accionables