El QA: Revision de Calidad

La Linea de Defensa de Calidad

En un equipo agil tradicional, el QA es quien dice “esto no esta listo para produccion”. En BMAD, el QA Agent cumple exactamente ese rol: es la ultima barrera antes de que el codigo se considere completo.

El QA no escribe codigo nuevo. Su trabajo es validar que lo que el Developer implemento cumple con todo lo especificado en las fases anteriores. Es el agente que conecta el final del pipeline con el principio: verifica que la implementacion refleja fielmente lo que el Analyst, PM y Architect definieron.

Cuando entra el QA

El QA Agent se activa cuando el Developer marca una story como “implementada”. No antes. Si el Developer aun esta trabajando, el QA no interviene. Esta secuencia es importante porque:

1. El Developer completa la story segun la spec
2. El Developer ejecuta sus propias validaciones basicas
3. El QA recibe el codigo y lo revisa contra los artefactos de referencia
4. El QA emite un veredicto: Approved o Needs Fixes

Que revisa el QA: El Checklist Completo

El QA Agent no revisa “a ojo”. Tiene un checklist estructurado que cubre seis areas fundamentales.

1. Cumplimiento de estandares de codigo

• Convenciones de naming (camelCase, PascalCase, etc.)
• Estructura de archivos segun lo definido por el Architect
• Imports organizados y sin dependencias circulares
• Codigo formateado segun la configuracion del proyecto (ESLint, Prettier)
• Sin archivos huerfanos o codigo muerto

2. Cobertura de requisitos vs PRD

Esta es la revision mas critica. El QA toma el PRD del Product Manager y verifica punto por punto:

• Cada requisito funcional tiene implementacion correspondiente
• Los criterios de aceptacion de cada story se cumplen
• Los edge cases documentados estan cubiertos
• Las restricciones de negocio se respetan

3. Cobertura de tests

El QA evalua la cobertura de testing en tres niveles:

• Tests unitarios: funciones y componentes individuales
• Tests de integracion: flujos que involucran multiples modulos
• Tests de contrato: API endpoints responden segun el schema definido

No se trata solo del porcentaje de cobertura. El QA verifica que los tests cubran los caminos criticos: el happy path, los errores esperados y los edge cases de las stories.

4. Calidad de codigo

• Complejidad ciclomatica dentro de limites aceptables
• Funciones con responsabilidad unica
• Sin duplicacion de logica (DRY)
• Manejo correcto de errores (no catch vacios)
• Codigo muerto o comentado sin razon
• Archivos ubicados en el directorio correcto segun la arquitectura

5. Vulnerabilidades de seguridad

El QA ejecuta un analisis de seguridad que incluye:

• SQL Injection: parametros sanitizados en queries
• XSS: outputs escapados correctamente en el frontend
• Dependencias inseguras: librerias con CVEs conocidos
• Secretos expuestos: API keys o passwords en el codigo
• Autenticacion: tokens validados en cada endpoint protegido
• Autorizacion: usuarios solo acceden a sus propios recursos

6. Performance y refactoring

• Queries N+1 detectadas
• Operaciones costosas sin cache
• Componentes renderizando innecesariamente
• Oportunidades de memoizacion
• Indices faltantes en base de datos

Ejemplo: Reporte QA del Kanban

Cuando el QA revisa la implementacion del drag & drop de tarjetas en nuestro Kanban, genera un reporte estructurado como este:

Encabezado del reporte

QA Review Report
Story: KAN-007 - Drag and drop de tarjetas entre columnas
Reviewer: QA Agent
Date: 2024-12-17
Status: NEEDS FIXES

Checklist Pass/Fail

Area	Status	Notas
Estandares de codigo	PASS	Naming consistente, estructura correcta
Requisitos vs PRD	PASS	Todos los criterios de aceptacion cubiertos
Cobertura de tests	FAIL	Falta test para drag entre tableros diferentes
Calidad de codigo	PASS	Complejidad aceptable
Seguridad	FAIL	Endpoint PATCH no valida ownership del board
Performance	PASS	Actualizacion optimista implementada

Issues por severidad

Blocker (deben corregirse antes de merge)

• SEC-001: El endpoint PATCH /api/cards/:id/move no verifica que el usuario sea miembro del tablero destino. Un usuario autenticado podria mover tarjetas a tableros ajenos manipulando el request.

Major (deben corregirse, no bloquean merge si hay plan)

• TEST-001: No existe test de integracion para el caso donde un usuario intenta mover una tarjeta a una columna de un tablero donde no tiene acceso.
• TEST-002: Falta test unitario para el handler de reordenamiento cuando la columna destino esta vacia.

Minor (mejoras sugeridas)

• STYLE-001: El archivo useDragAndDrop.ts tiene 87 lineas. Considerar extraer la logica de calculo de posicion a un helper separado.
• PERF-001: El estado de las columnas se recalcula completamente en cada drop. Podria optimizarse actualizando solo las columnas afectadas.

Veredicto

Status: NEEDS FIXES
Blocking issues: 1 (SEC-001)
Recommendation: Corregir SEC-001 antes de merge.
                TEST-001 y TEST-002 pueden resolverse en
                la siguiente iteracion si se crea ticket.

El Flujo de Feedback

El proceso de QA no es un evento unico. Es un ciclo:

Developer completa story
    → QA revisa
        → Si APPROVED: merge
        → Si NEEDS FIXES:
            → QA detalla issues
                → Developer corrige
                    → QA re-valida (solo lo corregido)
                        → Si APPROVED: merge
                        → Si NEEDS FIXES: otro ciclo

Lo clave es que en la re-validacion, el QA solo revisa los puntos que fallaron. No repite todo el checklist desde cero. Esto mantiene el flujo eficiente.

Comunicacion entre QA y Developer

En BMAD, esta comunicacion ocurre a traves de artefactos. El QA genera su reporte en _bmad/reviews/ y el Developer consulta ese archivo para saber que corregir. No hay ambiguedad ni conversaciones informales que se pierdan.

_bmad/reviews/
  KAN-007-review-v1.md    ← Primera revision (NEEDS FIXES)
  KAN-007-review-v2.md    ← Re-validacion (APPROVED)

Testing Manual vs Testing Automatizado

En BMAD, el QA trabaja en dos modos complementarios.

Testing automatizado

El QA Agent verifica que los tests escritos por el Developer:

• Cubran los criterios de aceptacion de la story
• Pasen exitosamente
• No tengan falsos positivos (tests que siempre pasan)
• Manejen setup y teardown correctamente

Tambien puede sugerir tests adicionales que el Developer deberia agregar.

Revision manual (analisis estatico)

El QA lee el codigo y los artefactos para detectar problemas que los tests automatizados no capturan:

• Logica de negocio incorrecta que pasa tests por coincidencia
• Problemas de arquitectura (dependencias en direccion incorrecta)
• Codigo que funciona pero viola los patrones definidos por el Architect
• Problemas de UX que no estan cubiertos por tests funcionales

La combinacion de ambos enfoques es lo que hace al QA Agent efectivo. No reemplaza al testing automatizado ni se limita a el.

Verificacion contra Criterios de Aceptacion

Esta es la tarea central del QA. Cada story tiene criterios de aceptacion definidos por el PM y refinados por el Scrum Master. El QA verifica cada uno.

Ejemplo para la story “Drag & drop de tarjetas”:

Criterio de aceptacion	Verificado	Metodo
Usuario puede arrastrar tarjeta entre columnas	Si	Test E2E + revision manual
Posicion de tarjeta persiste tras refresh	Si	Test de integracion
Otros usuarios ven el cambio en tiempo real	Si	Test de WebSocket
No se puede mover tarjeta a tablero sin acceso	No	Falta validacion en endpoint
Columna vacia muestra zona de drop visible	Si	Test de componente

Cuando un criterio falla, el QA lo reporta como issue con la severidad correspondiente. Un criterio de aceptacion no cumplido es siempre al menos Major.

Resumen del capitulo

El QA Agent es la ultima fase del pipeline de BMAD. Su responsabilidad es garantizar que el codigo entregado cumple con los estandares de calidad, seguridad y funcionalidad definidos en las fases anteriores. No escribe codigo: valida, reporta y re-valida.

Lo mas importante del QA en BMAD no es el checklist en si, sino que conecta la implementacion con los requisitos originales. Cierra el ciclo que empezo con el Analyst y asegura que nada se perdio en el camino.

---

← Capitulo 7: El Developer | Capitulo 9: Party Mode y Workflows →