QA Engineer Jr route: learn for free from scratch in 6 weeks
De cero a diseñar casos, reportar bugs, probar APIs y automatizar un flujo simple en un equipo real, con ejemplos de banca. With free videos in Spanish, plain-words explanations, hands-on challenges, quizzes and review by a teacher.
- Level: Beginner
- 6 weeks
- 57 challenges
- 29 free videos
- 48 questions
- Certificate at the end
Route content is in Spanish.
Week-by-week syllabus
Week 1 · Fundamentos del testing, tipos de prueba y ciclo de vida del bug + Git
QA (control de calidad) es revisar que una app funcione bien antes de que la usen miles de personas, como el inspector que mira cada juguete antes de que salga de la fábrica. Ejemplo concreto: en una app de transferencias pruebas qué pasa si envías S/ 0, S/ 1 o más de lo que tienes, y anotas lo que ves para que otra persona lo repita. Eso se llama reportar un bug (un error en la app). Git es el historial de versiones que guarda cada cambio, como partidas guardadas de un videojuego. No necesitas programar para empezar: solo curiosidad y ojo para los detalles.
Error típico de principiante: reportar "no funciona" sin pasos ni capturas. Si nadie puede repetir el bug, nadie lo puede arreglar.
Week 1 topics
- Qué es probar, QA vs. QC vs. testing, por qué el testing no es "romper cosas al azar"
- Los 7 principios del testing (ISTQB): las pruebas muestran defectos, no su ausencia; testing exhaustivo imposible; probar temprano; agrupación de defectos; paradoja del pesticida; depende del contexto; falacia de ausencia de errores
- Error, defecto y falla
- Niveles de prueba: unitarias, integración, sistema, aceptación
- Tipos: funcional, no funcional (rendimiento, usabilidad, seguridad), caja negra / caja blanca, confirmación (re-test), regresión, smoke, exploratoria
- Dónde entra QA en Scrum: refinamiento, sprint, definición de hecho
- Ciclo de vida del bug (Nuevo → Asignado → En progreso → Resuelto → Verificado → Cerrado / Reabierto), severidad vs. prioridad
- Reporte de bug reproducible: título, ambiente, precondiciones, pasos, resultado esperado vs. obtenido, evidencias
- Git:
clone,branch,switch,add,commit,push,pull, Pull Request, conflicto simple
Cursos: "Software Testing desde 0 : MasterClass todo en 1 con IA" (Esteban Balvin) + curso de Git de MoureDev en YouTube.
9 challenges · 8-question quiz
Week 2 · Diseño de casos de prueba, criterios de aceptación y Gherkin
Planear tus pruebas antes de hacerlas es como escribir una receta: qué ingredientes (datos), qué pasos y cómo debe quedar el plato (resultado esperado). Ejemplo: si un campo acepta edades de 18 a 65, no pruebas las 48 edades; pruebas 17, 18, 65 y 66, porque los errores viven en los bordes (valores límite). Los criterios de aceptación son las reglas que dicen cuándo algo está "terminado", y Gherkin las escribe en frases simples: Dado… Cuando… Entonces…
Error típico de principiante: escribir un caso con "verificar que funcione" como resultado esperado. Debe ser algo comprobable, como "se muestra el mensaje 'Monto inválido'".
Week 2 topics
- Anatomía de un caso de prueba: ID, título, precondiciones, pasos, datos, resultado esperado, prioridad
- Particiones de equivalencia (válidas e inválidas)
- Análisis de valores límite (2 valores por frontera)
- Tablas de decisión
- Transición de estados
- Historias de usuario (formato "Como… quiero… para…") y criterios de aceptación verificables
- Gherkin:
Feature,Scenario,Given/When/Then/And,Scenario Outline+Examples - Gestión de pruebas en Jira/Xray: Test, Test Plan, Test Execution, trazabilidad historia → caso → bug
Cursos: "QA Desde Cero: Aprende Testing y Jira aplicado" (Francisco J. Oliva), secciones de técnicas de diseño y Jira.
9 challenges · 8-question quiz
Week 3 · Pruebas de API con Postman
La API es el mesero que lleva tu pedido a la cocina y te trae la comida. Con Postman le mandas pedidos y revisas la respuesta sin necesitar la pantalla. Ejemplo: GET /usuarios/5 debe devolver código 200 y un JSON con el nombre; si pides un usuario que no existe, debe responder 404, no 200 con un mensaje raro. Los códigos 2xx son éxito, 4xx es culpa de quien pide y 5xx es culpa del servidor.
Error típico de principiante: revisar solo que la API "responde" y no el código, el cuerpo ni el tiempo. Una respuesta 200 con datos equivocados sigue siendo un bug.
Week 3 topics
- HTTP: métodos (
GET,POST,PUT,PATCH,DELETE), URL, query params, headers, body - Códigos de estado: 2xx, 4xx, 5xx y qué significan para un QA
- JSON: objetos, arreglos, tipos
- Postman: workspaces, colecciones, carpetas, entornos, variables (
{{baseUrl}}) - Autenticación: Basic, API Key, Bearer token
- Scripts: Pre-request y Tests (
pm.test,pm.expect,pm.response) - Encadenar requests guardando datos en variables
- Collection Runner con archivo de datos (CSV) y Newman desde la terminal
Cursos: "API Testing con POSTMAN : Masterclass todo en 1 (2026)" (Esteban Balvin), hasta Collection Runner y Newman.
9 challenges · 8-question quiz
Week 4 · SQL para QA + JavaScript básico
SQL es hacerle preguntas a una base de datos, como pedirle al bibliotecario "todos los libros de este autor". Ejemplo de QA: ves en la app un pedido de S/ 85 y compruebas con SELECT total FROM pedidos WHERE id = 7 que lo guardado también sea 85. JavaScript es el lenguaje con el que automatizarás pruebas la próxima semana: guardas valores con const, repites con funciones y filtras listas con filter.
Error típico de principiante: olvidar el WHERE y mirar toda la tabla (o peor, en un UPDATE/DELETE). Primero escribe el SELECT, comprueba qué filas toca y recién entonces actúas.
Week 4 topics
- Bases de datos relacionales: tablas, filas, columnas, clave primaria y foránea
SELECT,WHERE,AND/OR,IN,BETWEEN,LIKE,IS NULL,ORDER BY,LIMIT- Agregaciones:
COUNT,SUM,AVG,MIN,MAX,GROUP BY,HAVING INNER JOINyLEFT JOIN- SQL para QA: validar que lo que muestra la pantalla o la API es lo que se guardó
- JavaScript en Node:
const/let, tipos, funciones y funciones flecha,if, arreglos (filter,map,reduce,find), objetos, módulos - Asincronía: promesas,
async/await,fetch,try/catch
Cursos: "Curso SQL: Desde cero para principiantes" (DataBoosters Academy) + fundamentos de "JavaScript Moderno" (Fernando Herrera).
9 challenges · 8-question quiz
Week 5 · Automatización E2E con Playwright
Automatizar es grabar una receta para que un robot de cocina la repita igual cada vez. Con Playwright escribes qué hacer: abrir la página, escribir en el campo y pulsar el botón, por ejemplo page.getByRole('button', { name: 'Pagar' }).click(). Esa línea no usa la posición del botón, sino su función y su nombre, como decirle a un amigo "toca el botón que dice Pagar". Eso hace la prueba más estable.
Error típico de principiante: usar selectores frágiles (XPath largos) o waitForTimeout de 5 segundos. Los locators por rol y las aserciones de Playwright ya esperan solos.
Week 5 topics
- Qué automatizar y qué no (pirámide de pruebas, costo de mantenimiento)
- Instalación con
npm init playwright@latest, estructura del proyecto yplaywright.config test,expect,test.describe,test.beforeEach- Locators recomendados:
getByRole,getByLabel,getByText,getByPlaceholder,getByTestId; por qué evitar XPath absolutos - Acciones:
goto,click,fill,selectOption - Asserts web que esperan solos:
toHaveText,toBeVisible,toHaveURL,toContainText - Codegen, UI Mode, Trace Viewer, capturas y video al fallar
- Page Object Model
- Datos de prueba y tests independientes
- Proyectos del config: varios navegadores y emulación de móvil
Cursos: "Curso de Playwright con JavaScript" (Miguel Teheran), secciones de fundamentos, locators, asserts, depuración y patrones de diseño.
Recommended free videos
10 challenges · 8-question quiz
Week 6 · CI, regresión, reportes y simulación de trabajo real
CI (integración continua) es una alarma automática: cada vez que alguien sube código, una máquina corre tus pruebas y avisa si algo se rompió. Ejemplo: un dev arregla el modo oscuro y, sin querer, rompe el botón de subir historias; tu regresión automática lo detecta en minutos. Una prueba de regresión revisa que lo que ya funcionaba siga funcionando, como verificar que al arreglar la ventana no rompiste la puerta. Un reporte claro dice qué probaste, qué falló y qué riesgo queda.
Error típico de principiante: "arreglar" un test flaky subiendo los reintentos. Busca la causa (esperas, datos compartidos, ambiente) en vez de taparla.
Week 6 topics
- Smoke vs. regresión, selección de casos de regresión por riesgo
- Etiquetas en Playwright (
@smoke,@regresion) y--grep - Reportes: HTML de Playwright, resumen de Newman, informe de pruebas del sprint
- CI con GitHub Actions: disparadores, jobs, artefactos
- Tests flaky: causas y cómo tratarlos (no se "arreglan" con reintentos)
- Nociones de pruebas de rendimiento: carga vs. estrés, usuarios virtuales, p95, tasa de errores (k6)
- Nociones de pruebas móviles: emulación vs. dispositivo real, interrupciones, red lenta, rotación, permisos
- Trabajo en equipo: refinamiento, dailies, cómo comunicar un bug bloqueante
Cursos: "Curso de Playwright con JavaScript" (Miguel Teheran), secciones de CI/CD y reportes.
11 challenges · 8-question quiz
Portfolio projects
Cuando buscas tu primer trabajo, un proyecto propio en GitHub dice mucho más que "aprendo rápido": demuestra que sabes hacer el trabajo, y le da a quien te entrevista algo concreto de qué conversar contigo.
1. Cazabugs: auditoría de una tienda de demo
- Qué construyes: un plan de pruebas y una lista de bugs reportados para una web pública hecha para practicar (por ejemplo, SauceDemo o Demoblaze), con casos de prueba, pasos para repetir cada error, capturas de pantalla y prioridad.
- Qué practicas: tipos de prueba, reporte de bugs, diseño de casos de prueba, valores límite, criterios de aceptación y Gherkin (semanas 1 a 2).
- Súbele el nivel: graba un GIF corto de cada bug y agrega una tabla resumen con cuántos bugs encontraste por severidad.
2. Tienda en piloto automático
- Qué construyes: una suite de pruebas con Playwright que recorre una tienda de demo de principio a fin: iniciar sesión, buscar un producto, agregarlo al carrito y terminar la compra, y que corre sola en GitHub Actions cada vez que subes un cambio.
- Qué practicas: JavaScript básico, locators, pruebas E2E, pruebas de regresión, CI y reportes (semanas 4 a 6).
- Súbele el nivel: haz que la misma suite corra en Chrome, Firefox y en tamaño de celular, y publica el reporte HTML para que cualquiera lo vea.
3. Pokédex bajo la lupa
- Qué construyes: una colección de Postman que prueba una API pública de videojuegos, como la PokéAPI: pedidos que deben funcionar, pedidos que deben fallar (un Pokémon que no existe) y validaciones de códigos de estado, tiempos de respuesta y datos.
- Qué practicas: pruebas de API, códigos de estado, variables y validaciones con JavaScript en Postman (semanas 3 a 4).
- Súbele el nivel: corre la colección desde la terminal con Newman y agrégala a tu flujo de CI para que se ejecute sola.
QA Engineer Jr glossary in plain words
| Palabra | Qué significa |
|---|---|
| Caso de prueba | Una lista de pasos con el resultado que esperas, como una receta: "pon 2 productos en el carrito y el total debe sumar bien". |
| Bug | Un error en la app que hace que algo no funcione como debería, como un botón de "Pagar" que no hace nada. |
| Reporte de bug | Un mensaje claro que explica el error y cómo repetirlo, como avisar al conserje exactamente qué foco está quemado y en qué piso. |
| QA | Siglas de Quality Assurance (aseguramiento de calidad): el trabajo de asegurar que un producto funcione bien, como un inspector de calidad en una fábrica. |
| Regresión | Cuando algo que ya funcionaba se rompe por un cambio nuevo, como arreglar una ventana y que se trabe la puerta. |
| Prueba de regresión | Volver a probar lo que ya funcionaba después de un cambio, para confirmar que nada se rompió. |
| Valor límite | Probar justo en el borde de lo permitido, como revisar si un formulario acepta exactamente 18 años cuando la edad mínima es 18. |
| Criterio de aceptación | Una regla que dice cuándo algo está terminado, como "el usuario puede cambiar su contraseña y recibe un correo de aviso". |
| Gherkin | Una forma de escribir pruebas con frases simples: "Dado que estoy en el login, Cuando pongo mi clave, Entonces entro a mi cuenta". |
| API | El "mesero" entre programas: recibe un pedido, lo lleva a la cocina (el servidor) y trae la respuesta. |
| Postman | Una herramienta para enviar pedidos a una API y ver qué responde, sin necesitar la pantalla de la app. |
| Código de estado | Un número que la API devuelve para decir cómo le fue al pedido, como 200 (todo bien) o 404 (no encontrado). |
| Base de datos | El lugar donde la app guarda su información ordenada, como el archivo de fichas de una biblioteca. |
| SQL | El lenguaje para hacerle preguntas a una base de datos, como "muéstrame todos los usuarios de Lima". |
| Automatización | Escribir un programa que haga las pruebas por ti, como un robot de cocina que repite la receta igual cada vez. |
| Playwright | Una herramienta que controla el navegador para hacer clics y escribir como una persona, pero de forma automática. |
| Locator | La "dirección" que usa tu prueba para encontrar un botón o campo en la página, como decir "el botón azul que dice Enviar". |
| Git | Un sistema que guarda el historial de cambios de tus archivos, como el historial de versiones de un documento compartido. |
| CI (integración continua) | Un sistema que corre tus pruebas solas cada vez que alguien cambia el código, como una alarma que revisa la casa cada vez que se abre la puerta. |
Ready to start?
Free, no card and no prior experience. Sign in with Google or without an account.
Start QA Engineer Jr for free