Descripción de la Evaluación del Módulo 2
Felicitaciones por llegar a la última lección del Módulo 2. Esta evaluación integral prueba tu comprensión de todos los temas cubiertos en las 35 lecciones del módulo.
La evaluación consiste en tres partes:
- Preguntas de Conocimiento — 10 preguntas quiz en el frontmatter (tómalas antes de seguir leyendo)
- Preguntas Basadas en Escenarios — Clasifica y aplica conceptos a situaciones reales
- Ejercicio Práctico — Crea una estrategia de testing para un proyecto nuevo
Guía de Puntuación
- Parte 1 (Quiz): 10 preguntas × 3 puntos = 30 puntos
- Parte 2 (Escenarios): 5 escenarios × 6 puntos = 30 puntos
- Parte 3 (Ejercicio): 40 puntos
- Total: 100 puntos. Aprobación: 70 puntos
Temas Cubiertos
| Área | Lecciones | Conceptos Clave |
|---|---|---|
| Niveles de Testing | 2.1-2.6 | Unitario, integración, sistema, E2E, UAT, pirámide |
| Tipos Funcionales | 2.7-2.10 | Smoke, sanity, regresión, retesting |
| Testing No Funcional | 2.11-2.25 | Rendimiento, seguridad, usabilidad, accesibilidad, compatibilidad, confiabilidad |
| Métodos de Testing | 2.26-2.28 | White-box, black-box, grey-box |
| Estático vs. Dinámico | 2.29-2.31 | Revisiones, inspecciones, análisis estático |
| Enfoques Exploratorios | 2.32-2.34 | Exploratorio, ad hoc, monkey testing, SBTM |
Parte 2: Preguntas Basadas en Escenarios
Escenario 1: Tu equipo desplegó un hotfix de seguridad en producción que cambia el flujo de autenticación. Tienes 30 minutos antes de que cierre la ventana de despliegue.
¿Qué tipo(s) de testing deberías realizar y por qué?
Escenario 2: Una aplicación de salud almacena registros de pacientes, procesa reclamos de seguros y genera reportes médicos. La nueva versión agrega gestión de recetas.
Lista todos los tipos de testing por prioridad.
Escenario 3: SonarQube reporta: 0 bugs, 0 vulnerabilidades, 3 code smells menores, 45% cobertura en código nuevo. El Quality Gate requiere 80%.
¿Debería mergearse el PR? ¿Qué acciones tomar?
Escenario 4: Una app bancaria móvil recibe quejas de “crashes aleatorios” que QA no puede reproducir con test cases con scripts.
¿Qué enfoque(s) recomendarías?
Escenario 5: Tu empresa construye una nueva plataforma de e-commerce desde cero. ¿Cuándo en el SDLC debería comenzar cada tipo de testing?
Solución — Escenario 1
**Smoke testing** primero (5-10 min), luego **testing de seguridad dirigido** al fix específico (10-15 min), luego **regresión dirigida** de features de autenticación (10-15 min). No hay tiempo para regresión completa.Solución — Escenario 2
**Crítico:** Funcional, seguridad (HIPAA), regresión, integración. **Alta prioridad:** Rendimiento, accesibilidad, compatibilidad, usabilidad. **Media:** Recovery, exploratorio, estático. **También:** UAT con profesionales de salud.Solución — Escenario 3
No mergearse — el Quality Gate falla. El desarrollador debe escribir más tests, no bajar el umbral. Investigar por qué la cobertura es baja.Solución — Escenario 4
Monkey testing con Android Monkey, testing exploratorio con SBTM enfocado en navegación rápida y condiciones de red, testing de compatibilidad en dispositivos específicos de los crash reports, análisis de logs de crashes, profiling de memoria.Solución — Escenario 5
Requisitos: testing estático (revisiones). Diseño: revisión de arquitectura. Implementación: unit tests, análisis estático, revistas de código. Integración: API testing. Sistema: funcional, regresión, exploratorio. No funcional: rendimiento, seguridad, accesibilidad. Pre-release: UAT, E2E. Post-release: smoke, monitoreo.Parte 3: Ejercicio Práctico — Construye una Estrategia de Testing
Eres el QA Lead de una nueva plataforma de aprendizaje en línea con: gestión de usuarios, catálogo de cursos, reproductor de video, motor de quizzes, sistema de pagos, notificaciones, panel de admin y apps móviles.
Crea una estrategia cubriendo: A (10pts): Niveles de testing y distribución de esfuerzo. B (10pts): Matriz de tipos de testing por feature. C (10pts): Plan de testing estático vs. dinámico con herramientas. D (10pts): Plan de testing exploratorio con 3 charters y gestión SBTM.
Solución del Ejercicio
Parte A: Testing trophy (énfasis en integración). Unit 25%, Integración 35%, Sistema 25%, E2E 10%, UAT 5%.
Parte B: Pagos y video requieren security/performance crítico. Todas las features necesitan functional alto. Mobile apps necesitan compatibility y usability críticos.
Parte C: Estático: revisiones de requisitos, revisión de arquitectura, SonarQube en CI, code reviews. Dinámico: Jest/pytest para unit, Postman para API, Playwright para web, k6 para carga, OWASP ZAP para seguridad.
Parte D: Charters enfocados en: reproductor de video bajo condiciones de red degradadas, flujo de pagos y reembolsos con edge cases, motor de quizzes bajo presión de tiempo. Sesiones SBTM de 90 minutos, debrief dentro de 1 hora, 2-3 sesiones por sprint.
¿Qué Sigue?
Felicitaciones por completar el Módulo 2. Ahora tienes comprensión integral de niveles, tipos y métodos de testing.
Módulo 3: Técnicas de Diseño de Pruebas toma las técnicas de caja negra introducidas en la Lección 2.27 y las explora en profundidad: partición de equivalencia, análisis de valores límite, tablas de decisión, transiciones de estado, testing pairwise y más.