Ely QA

---
name: ely-frontend-qa
description: "Verifica cambios de frontend con recorridos reales de navegador y pruebas proporcionales al riesgo: desktop, móvil, teclado, navegación y estados relevantes. Úsala antes de entregar una interfaz o investigar regresiones; documenta evidencia y límites sin sustituirla por una suite extensa de tests frágiles."
---

# Ely QA

Comprueba que una persona puede terminar los recorridos afectados y que la interfaz conserva su calidad con contenido y estados reales. La profundidad de la verificación depende del riesgo del cambio, no del número de componentes.

## Elegir qué puede fallar

Inspecciona el cambio, las rutas y las convenciones del repositorio antes de añadir pruebas. Identifica el recorrido principal y las consecuencias de romperlo. Selecciona los casos que discriminan ese riesgo: un cambio tipográfico puede requerir inspección de reflujo; una nueva validación necesita error y recuperación; una navegación asíncrona necesita volver y recibir respuestas tardías.

Usa el navegador y las herramientas de test disponibles. El build, lint o una lectura del código no sustituyen ejecutar la interfaz. Si no puedes abrirla, aprovecha las verificaciones posibles y declara esa limitación; no marques como aprobado el comportamiento que no observaste.

Lee [references/journey-matrix.md](references/journey-matrix.md) cuando necesites elegir casos para formularios, navegación, contenido dinámico, motion o descargas. No ejecutes la matriz completa por rutina.

## Recorrer la interfaz de verdad

- Abre la ruta como la abriría una persona, incluidos enlaces directos cuando correspondan. Completa acciones con sus controles visibles; para verificar comportamiento, evita reemplazar la interacción por llamadas internas de JavaScript.
- Prueba un viewport de escritorio y uno estrecho representativos del producto. Inspecciona scroll horizontal, clipping, densidad, controles alcanzables y elementos fixed/sticky. Cambia orientación o tamaño cuando pueda invalidar medidas calculadas.
- Utiliza contenido largo, vacío o numeroso cuando ponga a prueba el diseño afectado. Los estados sintéticos deben estar identificados y utilizar la infraestructura de fixtures o mocks existente, sin contaminar datos reales.
- Recorre controles clave con teclado y verifica destino del foco tras abrir, cerrar, fallar o navegar. Confirma que se puede salir del componente y continuar la tarea.
- Comprueba enlaces, anclas, navegación atrás/adelante y recarga de la ruta cuando el cambio afecta estado o routing. Revisa errores de consola y solicitudes fallidas atribuibles al trabajo, separándolos de problemas previos.
- En acciones asíncronas, verifica espera, fallo y recuperación cuando el riesgo lo justifique. No fuerces operaciones reales irreversibles ni envíes mensajes a terceros para obtener cobertura: usa un entorno de prueba autorizado o documenta ese límite.

## Automatizar donde evita una regresión real

Prefiere un pequeño test sobre el resultado observable de un recorrido importante a comprobaciones que copian la implementación. Reutiliza el runner y las convenciones del proyecto; no añadas otra infraestructura para un ajuste visual reversible.

Busca controles por rol y nombre accesible o contratos estables del producto. Espera una condición observable, no pausas fijas. Aísla datos y restaura fixtures. Las capturas visuales sirven para geometría y composición; no prueban que un botón funcione ni la fluidez de una animación.

Para scroll sostenido, inspecciona inicio, desarrollo, final y vuelta de cada secuencia afectada; prueba movimiento reducido y acceso a su contenido. Para microinteracciones, comprueba interrupción y repetición rápida. No cuentes capturas en distintas posiciones como una medición de rendimiento.

## Cerrar con evidencia proporcional

Corrige los fallos dentro del alcance y repite el caso fallido junto con sus dependencias afectadas. Amplía pruebas cuando aparezca un riesgo nuevo; no repitas toda la suite después de una corrección menor sin motivo.

Informa el resultado, entorno, recorridos ejecutados y cualquier límite material. Para un fallo pendiente, da pasos reproducibles, esperado, observado e impacto. Diferencia “comprobado”, “no comprobado” y “bloqueado”; no confundas ausencia de errores automáticos con aprobación completa. Evita datos sensibles en capturas y logs compartidos.

La verificación deja un resultado revisable; no concede por sí sola permiso para desplegar, publicar o realizar cambios externos.