Lista de verificación de pruebas QA para bugs y stories de Jira

¿Qué es una lista de verificación de pruebas QA?

Una lista de verificación de pruebas QA convierte el pase de pruebas en pasos marcables en el elemento de trabajo: entorno listo, cobertura funcional, casos límite, navegadores, comprobaciones de seguridad y sign-off. La forma de la lista es la misma para cada bug o story; solo cambian las marcas y la evidencia.

El pase va junto a los acceptance criteria: esas filas describen el comportamiento prometido, y la lista de pruebas QA registra cómo lo demostraste. Definition of Done puede exigir que esta lista esté completa antes de que la story se envíe.

Por qué los equipos dejan las pruebas QA en la incidencia

Un pase de pruebas que vive en una hoja, una página de Confluence o un hilo de Slack se pierde fácil cuando la siguiente persona abre el ticket. Una lista de verificación en el elemento de trabajo deja setup, cobertura y evidencia donde ya está el trabajo: los testers ponen estados de elemento como In Progress y Blocked, hacen @mention a un owner en una fila atascada y el tablero muestra lo que queda.

El mismo pase sirve para verificar un bugfix o una story: abres la incidencia, ves lo que falta, adjuntas capturas o logs en los fallos y escribes el resultado en el ticket. Los cambios de bajo riesgo pueden recortar las filas de seguridad y plataforma; los de alto riesgo las conservan.

Cuándo aplicarla

Usa una lista de verificación de pruebas QA en bugs, en stories que necesitan un pase estructurado antes de Done, o cuando el estado pasa a Ready for test. Aplícala automáticamente por tipo de incidencia para Bugs, o en ese cambio de estado, para que los testers siempre reciban el mismo andamiaje. Recorta filas en cambios de bajo riesgo; conserva cobertura de seguridad y regresión cuando el cambio toca auth, payments o un camino compartido.

Pruebas QA vs. Acceptance criteria vs. Definition of Done

Los acceptance criteria describen qué debe entregar esta story: los ejemplos que vas a demostrar. La lista de verificación de pruebas QA es cómo pruebas esos ejemplos: datos, navegadores, regresiones y notas. Definition of Done es el listón de salida compartido que cada story debe al final: tests, review y preparación de release. Deja las tres como listas de verificación separadas en el elemento de trabajo para que el comportamiento, el pase de pruebas y la calidad de envío se vean distintos.

Pruebas QA: un ejemplo para empezar

Para armar tu primera lista de verificación de pruebas QA, empieza con el ejemplo de abajo. Copia la lista y pégala en el campo de Checklist for Jira en un bug o una story. Lo ideal es guardarla como plantilla y aplicarla automáticamente al crear Bugs o cuando el trabajo pasa a Ready for test: los testers tienen un andamiaje consistente y reutilizan los mismos encabezados cada vez. Recorta filas que tu equipo se salta; añade las que tu proceso necesita.

Pase de pruebas QA

Preparación
El entorno de pruebas, el build y los feature flags coinciden con el elemento de trabajo
Los datos y cuentas de prueba están listos, incluidos los casos límite de permisos
Los bugs conocidos que quedan fuera de este pase están vinculados en la incidencia
Cobertura funcional
El camino feliz coincide con los acceptance criteria de este elemento de trabajo
Se ejercitan validación, estados vacíos y rutas de error evidentes
Se comprueban permisos y diferencias de rol cuando el acceso importa
Casos límite
Valores frontera, colecciones vacías y ediciones concurrentes están cubiertos cuando aplican
Los flujos interrumpidos reanudan o fallan con claridad: timeouts, reintentos y peticiones canceladas
Regresión y plataformas
Los flujos adyacentes que comparten este camino de código siguen funcionando
Están cubiertos los navegadores o dispositivos primarios acordados por el equipo
Smoke de accesibilidad: recorrido por teclado y foco visible en controles nuevos
Seguridad
La autorización se sostiene: un usuario no ve ni cambia datos de otro tenant
Los valores sensibles no aparecen en URLs, logs ni mensajes de error
Evidencia y sign-off
Capturas, grabaciones o enlaces de log están adjuntos para los fallos
Los defectos nuevos están creados y vinculados, con la severidad rellenada
El resultado de QA está escrito en el elemento de trabajo: pass, fail o blocked con owner

Ese andamiaje va en cada bug y en las stories que necesitan un pase estructurado. En Checklist for Jira añades o marcas puntos en el panel de la incidencia, guardas los encabezados como plantilla de proyecto o global, y la aplicas automáticamente al crear Bugs o cuando el estado pasa a Ready for test — o a mano desde Add → Add from template cuando la necesites.

Deje la checklist en el elemento de trabajo, no en la descripción

Checklist for Jira aporta plantillas, automatización, validadores de flujo y un agente Rovo. Gratis para equipos de hasta 10 usuarios.

Pruébalo gratis en Atlassian Marketplace

Guarda un starter, automatiza el pase

Checklist for Jira añade un panel de checklist en la vista de la incidencia. Pega el ejemplo de arriba en un bug o una story, ajusta las filas a tu proceso y guarda la forma como plantilla de proyecto o global en Checklist settings.
Marca la plantilla como Protected si quieres la lista de pasos bloqueada mientras los testers marcan puntos y ponen estados como In Progress y Blocked.
Usa la automatización por plantilla para adjuntar el andamiaje de pruebas QA cuando se crea un Bug, o cuando el estado pasa a Ready for test. Estas automatizaciones vienen en Checklist for Jira y corren sin créditos de Jira Automation.
Si tu equipo quiere un recordatorio antes de Done, añade un validador de finalización en esa transición, limitado a esta plantilla, para que el elemento de trabajo siga abierto hasta que el pase termine.
Combínalo con acceptance criteria para los ejemplos que el pase está demostrando, Definition of Done al final y la lista de verificación de release cuando el cambio está listo para enviarse — ver la guía de automatización.

Una lista de verificación de pruebas QA en un bug de Jira con estados de elemento y una barra de progreso.

Combínala con el resto del set de delivery

Deja acceptance criteria en la misma incidencia para el comportamiento prometido. Adjunta Definition of Done cuando el trabajo entra al sprint para que el listón de envío se vea desde el día uno. Usa Definition of Ready durante el refinement si la calidad del intake ayuda a tu equipo. Continúa con la lista de verificación de release cuando el cambio está listo para enviarse. Recorre el hub de plantillas para el conjunto completo.

Preguntas frecuentes

¿Cada caso de prueba debería ser una subtarea?

Abre una subtarea cuando un caso necesita asignatario, estimación y workflow propios. Una lista de verificación de pruebas QA estructurada en el padre es la forma más ligera de ejecutar un pase estándar.

¿En qué se diferencian las pruebas QA de los acceptance criteria?

Los acceptance criteria son los ejemplos que vas a demostrar: cómo se ve “correcto”. La lista de verificación de pruebas QA es cómo los demostraste: entorno, casos, evidencia y sign-off en el mismo elemento de trabajo.

¿Podemos informar sobre listas de QA incompletas?

Checklist for Jira expone el progreso en la incidencia, en tableros y en JQL, así que el trabajo de QA incompleto es filtrable.

¿Bugs y stories deben usar la misma lista de QA?

Empieza con una plantilla y recorta. Los bugs suelen conservar el pase completo. Las stories pueden soltar filas de seguridad o plataforma cuando el cambio es de bajo riesgo. Guarda una segunda plantilla por tipo de incidencia cuando las dos listas se quedan distintas.