Módulo 2 · Fundamentos técnicos

4 horas — 2 de teoría, 2 de práctica.

Este módulo te da las herramientas técnicas que usa QA todos los días: probar una API, documentar un defecto, consultar la base de datos, versionar tu trabajo y entender qué hace un pipeline.

Objetivos

Al terminar deberías poder:

• Ejecutar y validar peticiones REST, y leer la documentación de una API.
• Documentar un defecto de forma que otra persona lo reproduzca sin preguntarte.
• Escribir consultas SQL para verificar que los datos son los que dice la interfaz.
• Clonar un repositorio, crear una rama y subir un commit.
• Leer un pipeline de CI y decir dónde están los controles de calidad.

Entregable

Al final del módulo entregas:

1. Una colección de API con al menos 4 peticiones guardadas (GET y POST).
2. Una consulta SQL de validación con su resultado.
3. Un defecto documentado en Jira con la plantilla completa.
4. Tu repositorio con una rama nueva y un commit.

---

Parte teórica

APIs y servicios REST (25 min)

Una API es la puerta por la que los programas hablan entre sí. La web de ReservaLab no guarda nada por su cuenta: le pide todo a la API.

Lo mínimo que hay que dominar:

Concepto	Qué significa
Método	Qué quieres hacer: GET leer, POST crear, PATCH modificar, DELETE borrar
Ruta	Sobre qué recurso: /appointments, /services
Cuerpo	Los datos que envías, normalmente en JSON
Cabeceras	Metadatos; la más importante aquí es Authorization con tu token
Código de estado	Cómo salió: 2xx bien, 4xx te equivocaste tú, 5xx se equivocó el servidor

Los códigos que vas a ver en este bootcamp:

Código	Significado	Cuándo aparece
200	OK	La petición salió bien
201	Creado	Reservaste una cita
400	Petición mal formada	Faltan datos o son inválidos
401	No autenticado	No mandaste token, o venció
403	Prohibido	Tienes token, pero eso no es tuyo
404	No encontrado	Ese recurso no existe
409	Conflicto	Choca con una regla de negocio
500	Error del servidor	Algo se rompió por dentro. Casi siempre es un defecto.

La diferencia entre 400 y 500 importa

Un 400 dice "te equivocaste, y el sistema lo manejó bien". Un 500 dice "el sistema no supo qué hacer y se cayó". Si mandas datos inválidos y recibes un 500, eso es un defecto, aunque los datos que mandaste fueran incorrectos.

Gestión de defectos en Jira (20 min)

Un defecto mal escrito se cierra como "no reproducible" y el problema sigue ahí. La regla es simple: quien lea tu reporte debe poder reproducirlo sin hablar contigo.

La plantilla completa está en Reportar un defecto en Jira.

SQL básico para validación (25 min)

QA usa SQL para una cosa concreta: comprobar que lo que muestra la interfaz es lo que de verdad hay guardado. Cuando esas dos cosas no coinciden, has encontrado algo interesante.

Las tres tablas de ReservaLab:

users          quién usa el sistema      (id, email, nombre, rol)
services       qué se puede reservar     (id, nombre, duracion_min, precio, activo)
appointments   las citas                 (id, user_id, service_id, fecha, estado)

Lo que necesitas saber está en Consultar la base de datos.

Conceptos esenciales de Git (20 min)

Git guarda la historia de los cambios. Para QA importa por dos motivos: tus pruebas automatizadas son código que hay que versionar, y necesitas entender en qué versión encontraste un defecto.

El ciclo mínimo:

clone → branch → editar → add → commit → push

Detalle en Flujo de trabajo con Git.

Integración y entrega continua (30 min)

Un pipeline es una lista de comprobaciones que se ejecutan solas cada vez que alguien sube código. Si algo falla, el cambio no avanza.

El pipeline de tu repositorio tiene tres etapas:

Revisar el código  →  Ejecutar las pruebas  →  Publicar el reporte
   (tipos)              (API y web)              (artefacto)

Dónde está el control de calidad: en la segunda etapa. Si una prueba falla, el pipeline se pone rojo y el reporte queda igualmente descargable para poder investigar.

---

Parte práctica

Ejercicio 1 · Peticiones GET y POST (35 min)

Usa Bruno. Crea una colección llamada ReservaLab y guarda estas peticiones:

1. Estado del servicio — GET https://api.theproject.ec/health

Debe responder 200 con "estado": "ok".

2. Catálogo — GET https://api.theproject.ec/services

Anota cuántos servicios devuelve y el id de uno de ellos: lo necesitas después. Fíjate en que todos vienen con "activo": true.

3. Iniciar sesión — POST https://api.theproject.ec/auth/login

{
  "email": "studentNN@theproject.ec",
  "password": "tu-contraseña"
}

Copia el token de la respuesta. Es tu credencial para el resto de las peticiones: va en la cabecera Authorization: Bearer <token>.

4. Tus citas — GET https://api.theproject.ec/appointments

Con la cabecera de autorización. Anota el número que devuelve en total.

5. Reservar una cita — POST https://api.theproject.ec/appointments

{
  "service_id": 1,
  "fecha": "2026-12-15T10:00:00Z"
}

Cambia service_id por uno real del paso 2 y pon una fecha futura.

Preguntas para el informe

• ¿Qué pasa si repites la petición 5 con la misma fecha y el mismo servicio?
• ¿Qué pasa si pones una fecha del año pasado?
• ¿Qué pasa si envías {} como cuerpo? Mira con atención el código de estado. ¿Es el que corresponde?
• ¿Qué pasa si quitas la cabecera Authorization?

Ejercicio 2 · Documentar un defecto en Jira (20 min)

De todo lo que encontraste en el ejercicio 1, elige el hallazgo más grave y repórtalo en Jira siguiendo la plantilla.

Tu reporte tiene que incluir el curl o los pasos exactos, el resultado esperado, el obtenido y la severidad con su justificación.

Ejercicio 3 · Consultas SQL de validación (30 min)

Entra a db.theproject.ec con el usuario de solo lectura.

3.1 ¿Cuántas citas tienes en total?

SELECT COUNT(*)
FROM appointments a
JOIN users u ON u.id = a.user_id
WHERE u.email = 'studentNN@theproject.ec';

3.2 Compara ese número con el total que te devolvió GET /appointments.

¿No cuadran?

No es un error tuyo. Sigue investigando: ese desajuste es un defecto real y es uno de los hallazgos importantes del módulo.

3.3 Si no cuadran, averigua cuál es la cita que falta. Pista: mira a qué servicio pertenece cada una de tus citas y compáralo con el catálogo.

SELECT a.id, a.fecha::date, a.estado, s.nombre AS servicio, s.activo
FROM appointments a
JOIN services s ON s.id = a.service_id
JOIN users u ON u.id = a.user_id
WHERE u.email = 'studentNN@theproject.ec'
ORDER BY a.id;

3.4 Cuenta cuántas citas hay por estado:

SELECT estado, COUNT(*)
FROM appointments a
JOIN users u ON u.id = a.user_id
WHERE u.email = 'studentNN@theproject.ec'
GROUP BY estado;

3.5 Comprueba que es de solo lectura. Intenta borrar algo:

DELETE FROM appointments WHERE id = 1;

Anota el mensaje de error. Entender por qué falla es parte del ejercicio.

Ejercicio 4 · Clonar, ramificar y commitear (20 min)

git clone https://gitea.theproject.ec/studentNN/studentNN-qa.git
cd studentNN-qa

git checkout -b feat/mis-hallazgos-modulo2

Crea un archivo hallazgos-modulo-2.md con lo que encontraste en los ejercicios 1 y 3, y súbelo:

git add hallazgos-modulo-2.md
git commit -m "docs: hallazgos del modulo 2"
git push -u origin feat/mis-hallazgos-modulo2

Detalle y solución de problemas en Flujo de trabajo con Git.

Ejercicio 5 · Leer el pipeline (15 min)

Abre tu repositorio en Gitea → pestaña Actions. Verás la ejecución que disparó tu push.

Contesta:

1. ¿Cuántas etapas tiene el pipeline y cómo se llaman?
2. ¿Cuál de ellas es el control de calidad propiamente dicho?
3. El paso que publica el reporte tiene if: always(). ¿Por qué es importante que se ejecute incluso cuando las pruebas fallan?
4. Descarga el artefacto reporte-playwright y ábrelo.
5. Tu ejecución tardó en arrancar aunque el pipeline estaba libre. ¿Por qué? (Pista: el ejecutor procesa un trabajo a la vez.)

El archivo del pipeline está en tu repositorio, en .gitea/workflows/qa.yml. Léelo: está comentado.

---

Cierre

Antes de terminar, comprueba que tienes:

• [ ] La colección de Bruno con 5 peticiones guardadas
• [ ] Al menos un defecto reportado en Jira con la plantilla completa
• [ ] Las consultas SQL con sus resultados anotados
• [ ] Tu rama subida con el commit
• [ ] Las respuestas a las cinco preguntas del pipeline