✦ Antes de empezar — Consideraciones
Ahora bien — usar IA en tu trabajo es muy distinto y lo valoramos: si tienes experiencia en automatización con IA o has venido incorporándola en tus procesos de QA, eso suma mucho. Cuéntanoslo con ejemplos en la Sección 7, que creamos justo para eso.
Contexto
Eres parte del equipo de QA de una startup de e-commerce. El equipo actualmente es el cuello de botella del ciclo de releases: cada deploy espera validación manual y los sprints se acumulan.
Tu misión en esta prueba es doble: demostrar tu capacidad técnica como QA senior sobre una app real, y proponer cómo el equipo puede dejar de ser ese cuello de botella sin sacrificar calidad.
| Usuario | Contraseña | Observación |
|---|---|---|
| standard_user | secret_sauce | Normal |
| problem_user | secret_sauce | Comportamientos anómalos |
| performance_glitch_user | secret_sauce | Latencia inusual |
| locked_out_user | secret_sauce | No puede ingresar |
1.1 Mapa de riesgo
Analiza la aplicación y completa la tabla identificando las áreas de mayor riesgo. Justifica tu criterio.
| Área / Funcionalidad | Nivel de riesgo | Justificación |
|---|---|---|
1.2 Priorización
Dado que solo tienes 45 minutos para ejecutar pruebas antes de un release urgente, ¿qué pruebas primero y qué dejas para después?
2.1 Flujo de compra completo
Diseña los casos de prueba para el flujo: Login → Selección de producto → Carrito → Checkout → Confirmación.
Todos los casos deben estar escritos usando la estructura Given / When / Then. Puedes complementar con And y But donde sea necesario.
| ID | Título | Prioridad | Given | When | Then | And / But |
|---|---|---|---|---|---|---|
| TC-01 |
No hay problema — escribe el resto de los casos en el formato que usas habitualmente, pero incluye un ejemplo adicional con esa metodología y explica brevemente por qué prefieres aplicarla y en qué contextos la consideras más útil que Gherkin.
Lo que se evalúa es qué eliges cubrir y por qué, no la cantidad de casos.
2.2 Casos negativos y de excepción
Lista al menos 5 casos negativos o de excepción que consideres críticos. Escríbelos también en Gherkin.
| ID | Título | Given | When | Then | Por qué es crítico |
|---|---|---|---|---|---|
| CN-01 | |||||
| CN-02 | |||||
| CN-03 | |||||
| CN-04 | |||||
| CN-05 |
3.1 Ejecución
Ejecuta pruebas sobre la aplicación web usando los usuarios disponibles. Presta especial atención a problem_user y performance_glitch_user.
3.2 Reporte de bugs
Reporta todos los defectos que encuentres. Mínimo 3 bugs esperados.
🐛 BUG-001
Esta sección tiene dos partes: mobile web y app nativa. No necesitas instalar nada especial.
4.1 Comparativa web vs. mobile
Abre saucedemo.com desde el navegador de tu celular con el usuario standard_user y ejecuta el flujo Login → Agregar producto → Checkout.
| Aspecto | ¿Funciona igual que en desktop? | Diferencias observadas |
|---|---|---|
| Login | ||
| Navegación del catálogo | ||
| Agregar al carrito | ||
| Formulario de checkout | ||
| Confirmación de compra |
4.2 Bugs mobile
Si no encuentras bugs, documenta qué verificaste y por qué concluyes que no hay defectos. Eso también es válido.
Tú eliges la app, pero debe ser robusta: autenticación, flujos multi-paso, manejo de estado y al menos 2-3 módulos diferenciados (cuenta, catálogo, pagos, historial).
Estas apps requieren login. Puedes crear un usuario ficticio para la prueba, o si encuentras una app que permita modo invitado, también es válido. No uses credenciales reales ni datos personales sensibles.
Indica qué app elegiste, SO (iOS / Android), versión del SO y versión de la app.
4.3 Análisis rápido (10 minutos de exploración)
- ¿Cuáles son los 3 flujos más críticos para el negocio?
- ¿Qué área te generó más dudas o inconsistencias?
- ¿Detectaste algún bug? Repórtalo brevemente.
4.4 Casos específicos de mobile nativo
Diseña 5 casos de prueba exclusivos o especialmente importantes en app nativa. Escríbelos en Gherkin.
| ID | Título | Given | When | Then | Por qué es específico de mobile nativo |
|---|---|---|---|---|---|
| MOB-01 | |||||
| MOB-02 | |||||
| MOB-03 | |||||
| MOB-04 | |||||
| MOB-05 |
4.5 Escenario: el app "se va al fondo"
Estás probando el flujo de checkout en la app. En el paso 2 recibes una llamada, la atiendes y vuelves a la app 5 minutos después.
¿Qué esperas que pase? ¿Qué testeas? ¿Qué consideras un comportamiento aceptable vs. un bug?
5.1 Estrategia de regresión
Diseña una estrategia de regresión sostenible en el tiempo para un equipo pequeño con releases cada dos semanas. Incluye:
- Qué cubriría tu suite de regresión
- Cómo la organizas (smoke, sanity, full regression)
- Cómo decides qué entra y qué sale con cada release
5.2 Regresión impactada
El equipo acaba de hacer un cambio en el módulo de ordenamiento de productos (sort by price / name). ¿Qué casos de regresión ejecutas y cuáles puedes saltear con confianza?
El equipo de QA es el cuello de botella: cada feature espera validación manual antes de poder salir. Los developers ya terminaron sus cambios pero QA tarda 3-4 días en validar cada release. El negocio quiere deployar más rápido.
6.1 Diagnóstico
¿Cuáles crees que son las causas más probables? ¿Qué preguntas o investigas para confirmar tu hipótesis?
6.2 Propuesta concreta
Propone un plan para reducir el tiempo de validación sin bajar la calidad. Qué cambiarías primero, qué herramientas usarías, cómo medirías el éxito.
6.3 Herramientas y recursos
¿Qué herramientas o técnicas usas actualmente para hacer tu trabajo más eficiente? ¿Hay algo que hayas incorporado recientemente que cambió tu forma de trabajar?
7.1 Tu experiencia
¿Has incorporado automatización o inteligencia artificial en tu trabajo como QA? Cuéntanos qué hiciste, en qué contexto y qué problema resolvía.
7.2 Herramientas
¿Qué herramientas usaste? (frameworks de automatización como Playwright, Cypress, Selenium, Appium; herramientas de IA como Copilot, ChatGPT, TestRigor, Applitools, etc.)
7.3 Caso de negocio o resultado
Si lo deseas, comparte un caso de negocio o un resultado concreto: por ejemplo, cuánto tiempo ahorró, cómo mejoró la cobertura o la calidad, o qué impacto tuvo en el equipo.
7.4 Evidencias (opcional)
Solo si quieres, adjunta enlaces, capturas, repositorios o cualquier material que respalde lo que contaste. No es obligatorio, pero suma.
📦 Entrega
Cuando termines, envía únicamente estos dos elementos:
- El documento resuelto en PDF (adjunto)
- El enlace a tu Google Doc, con permiso de lectura activado
No aceptamos otros formatos (Word, Notion, Confluence, Markdown, etc.). Verifica que el enlace de Google Doc tenga permisos de visualización antes de enviarlo.
Si tomaste supuestos o algo no quedó claro, documéntalos dentro del documento — eso también se evalúa. Cualquier duda, responde este correo. ¡Mucha suerte!