Evaluación integral del Módulo 5 sobre testing de aplicaciones web: funcionalidades en tiempo real, rendimiento, accesibilidad, seguridad, SEO, SaaS, facturación, GDPR y caché.
Respuesta rápida
Evaluación del Módulo 5 cubre habilidades esenciales de QA — después de esta lección podrás demostrar comprensión integral del testing de aplicaciones web cubierto en el Módulo 5.
— Yuri Kan, Senior QA Lead
Lo Que Aprenderás
Demostrar comprensión integral del testing de aplicaciones web cubierto en el Módulo 5
Aplicar conceptos de testing web a escenarios realistas combinando múltiples temas
Crear una estrategia de testing web integrando rendimiento, seguridad, accesibilidad y funcionalidad
Felicitaciones por llegar al final del Módulo 5: Testing de Aplicaciones Web. Esta evaluación prueba tu comprensión de todos los temas cubiertos en las lecciones 5.1 a 5.29.
Contexto: Tu empresa lanza una plataforma e-commerce el próximo mes. Incluye: catálogo con búsqueda, carrito, checkout con Stripe, cuentas de usuario, blog SEO y 3 idiomas. Se esperan 50,000 usuarios: 40% EE.UU., 30% Europa, 20% LATAM.
Preguntas (5 puntos):
¿Cuáles son las 5 áreas de testing principales por riesgo? Justifica. (3 puntos)
¿Qué performance budget establecerías para páginas de producto? (2 puntos)
Solución
1. Flujo de pago (Crítico) → Seguridad (Crítico) → Cross-browser/responsive (Alto) → Performance y CDN (Alto) → Multi-idioma y SEO (Medio)
2. Peso total <400KB, JS <120KB, imágenes <150KB cada una (WebP), LCP <2.5s, CLS <0.1, TBT <200ms. Aplicar con Lighthouse CI en GitHub Actions.
Contexto: Un cliente reporta que puede ver nombres de proyectos de otra empresa en sus resultados de búsqueda. El índice global no filtraba por tenant_id.
Preguntas (5 puntos):
¿Qué testing inmediato realizarías? (2 puntos)
Diseña una suite de tests (5-7 casos) para prevenir recurrencia. (3 puntos)
Solución
1. Auditar búsqueda en 5+ tenants, auditar todos los endpoints API de listas, auditar exports/reportes, auditar autocomplete, purgar cachés y re-probar.
2. Tests: búsqueda aislada por tenant, API endpoints filtrados, acceso directo por ID bloqueado (404), export solo contiene datos del tenant, autocomplete scoped, operaciones masivas scoped, entidades nuevas con tenant_id automático.
Contexto: Un usuario con discapacidad visual presenta queja formal. Reporta: no puede completar checkout con screen reader, imágenes sin descripciones, no puede cerrar modales con teclado. Necesitas WCAG 2.2 AA en 90 días.
Preguntas (5 puntos):
Plan priorizado de 90 días en tres fases. (3 puntos)
¿Cómo integrarías testing de accesibilidad en el workflow? (2 puntos)
Solución
1. Fase 1 (Días 1-30): Corregir los 3 issues reportados + axe-core scan de todas las páginas + contraste + skip nav. Fase 2 (31-60): Auditoría manual de teclado + screen reader de flujos principales + ARIA labels. Fase 3 (61-90): axe-core en CI/CD + capacitación + auditoría externa.
2. CI/CD: axe-core en cada PR. Code review: checklist obligatorio. Sprint testing: keyboard + screen reader en DoD. Trimestral: auditoría externa.
Escenario: App web de salud y fitness con: perfiles con datos de salud, seguimiento de ejercicios con timer WebSocket, planificación de comidas, funciones sociales, suscripción premium $9.99/mes vía Stripe, 2 idiomas (EN, ES), 200K usuarios, 70% móvil, AWS + CloudFront.
Tu tarea: Cubre 5 áreas (3 puntos cada una): riesgos principales, performance, seguridad/privacidad, accesibilidad y testing de tiempo real.
Solución
Los 5 riesgos principales: privacidad de datos de salud, procesamiento de pagos, timer de ejercicio en tiempo real, performance móvil, seguridad de funciones sociales.
Performance: LCP <2s, TBT <150ms, peso <300KB, API <200ms, mobile-first con 4G/3G, Lighthouse CI.
Seguridad: Cifrado AES-256, no-store para endpoints de salud, GDPR compliance, rate limiting, settings de privacidad granulares.
Accesibilidad: WCAG 2.2 AA, timer accesible con aria-live, búsqueda de nutrición navegable por teclado, axe-core en CI.
Tiempo real: Ciclo de vida WebSocket completo, persistencia local durante desconexión, sincronización al reconectar, prueba multi-dispositivo, test de carga con 10K conexiones concurrentes.
Si obtuviste 28+ de 40, estás listo para el Módulo 6: Testing de API y Backend. Si obtuviste menos, revisa los temas donde perdiste puntos. El Módulo 6 profundiza en testing de API con Postman, arquitectura REST, autenticación y validación de schemas.
Prueba de Conocimiento
1. ¿Cuál es la diferencia principal entre WebSocket y HTTP?
WebSocket establece una conexión persistente permitiendo a ambos lados enviar datos en cualquier momento, mientras HTTP requiere que el cliente inicie cada ciclo request-response.
2. ¿Qué métrica Core Web Vital reemplazó a FID en marzo 2024?
INP reemplazó a FID porque mide la responsividad durante todo el ciclo de vida de la página, no solo la primera interacción.
3. ¿Cuál es el ratio mínimo de contraste para texto normal a nivel WCAG 2.2 AA?
WCAG 2.2 AA requiere un ratio de al menos 4.5:1 para texto normal y 3:1 para texto grande.
4. En testing SaaS multi-tenant, ¿qué código HTTP debe retornarse cuando un usuario intenta acceder al recurso de otro tenant?
Retornar 404 en lugar de 403 previene divulgación de información — el usuario no debe saber si el recurso existe en otro tenant.
5. ¿Qué es el prorrateo en facturación de suscripciones?
El prorrateo calcula un cargo proporcional cuando la suscripción cambia a mitad de ciclo.
6. Bajo GDPR, ¿cuánto tiempo tiene una organización para responder a un DSAR?
GDPR Artículo 15 requiere respuesta a DSARs en 30 días. Puede extenderse 2 meses para solicitudes complejas, notificando al usuario dentro de 30 días.
7. ¿Qué significa Cache-Control: no-store?
no-store instruye a navegadores y cachés intermedios a nunca almacenar la respuesta. Crítico para datos sensibles.
8. ¿Cuál es la prueba más básica para XSS?
Ingresar script tags en campos de entrada es la prueba XSS más simple. Si el JavaScript se ejecuta, la aplicación es vulnerable.
9. ¿Por qué debes ejecutar Lighthouse en modo incógnito?
Las extensiones modifican el DOM, inyectan scripts y hacen solicitudes de red que alteran los resultados de Lighthouse.
10. ¿Cuál es el propósito del tag canonical en SEO?
El tag canonical indica a motores de búsqueda cuál URL es la versión autoritativa, previniendo problemas de contenido duplicado.
Preguntas frecuentes
Que es evaluación del módulo 5?
Evaluación del Módulo 5 es un concepto clave en Testing de Aplicaciones Web. Esta leccion te ensena a demostrar comprensión integral del testing de aplicaciones web cubierto en el Módulo 5, proporcionando habilidades practicas aplicables inmediatamente.
Como aplico evaluación del módulo 5 en proyectos reales?
Comienza practicando las tecnicas principales de esta leccion. Especificamente, deberias aplicar conceptos de testing web a escenarios realistas combinando múltiples temas. Aplica estas habilidades en tu proyecto actual para ver resultados inmediatos.
Por que es importante evaluación del módulo 5 para ingenieros QA?
Evaluación del Módulo 5 es una habilidad central que los empleadores buscan en profesionales QA. Impacta directamente en la cobertura de pruebas, deteccion de defectos y eficiencia del equipo. Dominarlo fortalece tus capacidades en Testing de Aplicaciones Web.
Que debo saber antes de aprender evaluación del módulo 5?
Debes tener conocimientos basicos de fundamentos de testing de software. La familiaridad con quiz testing web sera util, pero la leccion incluye secciones de repaso.
Como ayuda evaluación del módulo 5 a mi carrera en QA?
El conocimiento de evaluación del módulo 5 se menciona frecuentemente en descripciones de puestos QA y entrevistas. Demuestra experiencia en quiz testing web, examen módulo 5 y muestra que puedes contribuir profesionalmente al aseguramiento de calidad.