Ejemplos reales de QA:
historia de usuario, casos de prueba y bug report.
El QA no se aprende leyendo definiciones. Se aprende viendo cómo se hace. Aquí tienes un ejemplo completo y real: desde la historia de usuario hasta el bug report, pasando por los criterios de aceptación y los casos de prueba.
La funcionalidad de ejemplo es un sistema de cupones de descuento: algo que cualquier persona conoce y que tiene más casuística de la que parece a primera vista.
Historia de usuario
Todo empieza aquí. Antes de testear nada, el QA necesita entender qué se está construyendo y para quién. La historia de usuario es la forma en que los equipos ágiles definen una funcionalidad desde el punto de vista del usuario.
Una historia de usuario describe una funcionalidad desde el punto de vista de quien la va a usar, no desde el punto de vista técnico. El formato estándar es: "Como [tipo de usuario], quiero [hacer algo], para [conseguir un beneficio]". Este formato obliga a pensar en el por qué, no solo en el qué.
Contexto y alcance
Queremos dar la posibilidad a los usuarios de aplicar códigos de descuento antes de pagar. Los códigos pueden ser de porcentaje (ej: 10% de descuento) o de importe fijo (ej: 5€ menos). El precio debe actualizarse en tiempo real en cuanto el código se valide correctamente.
La validación debe ocurrir siempre en el backend, nunca en el frontend, para evitar manipulaciones. Un código puede estar caducado, ya haber sido usado por ese usuario, haber agotado su límite global de usos o no ser aplicable al curso que se está comprando. Cada caso tiene su propio mensaje de error.
El descuento debe persistir si el usuario recarga la página o navega atrás, pero se invalida automáticamente si el usuario lleva más de 30 minutos en el checkout sin completar la compra.
Criterios de aceptación principales
Junto a la historia, el equipo de diseño entrega el diseño en Figma: la referencia visual de cómo tiene que verse la funcionalidad. El QA lo usa para verificar que lo implementado coincide con lo diseñado.
Los tres estados que el QA tiene que verificar: sin cupón, cupón válido aplicado y error. El diseño define exactamente qué debe verse en cada caso: colores, textos, disposición de elementos.
Cuando el QA recibe la historia y el diseño, su primer trabajo no es testear: es hacer preguntas. ¿Qué pasa si el código caduca mientras el usuario está en el checkout? ¿Dónde se valida el descuento, en el frontend o en el backend? ¿El precio del botón de pago también se actualiza? Las preguntas que el QA hace antes de empezar a desarrollar son las que evitan bugs después. Muchos de los criterios de aceptación de esta historia surgieron exactamente así, de preguntas que alguien hizo a tiempo.
Criterios de aceptación
Los criterios de aceptación son las condiciones concretas que la funcionalidad tiene que cumplir para considerarse correctamente implementada. Son el puente entre la historia de usuario y los casos de prueba.
Sin criterios de aceptación, cada persona del equipo entiende la funcionalidad a su manera. El desarrollador puede implementar algo que técnicamente funciona pero que no es lo que el usuario espera. Los criterios eliminan esa ambigüedad. Un criterio bien escrito es específico, verificable y sin interpretación posible.
BIENVENIDO10 y bienvenido10 funcionan igualLa diferencia entre un criterio útil y uno inútil es la especificidad.
Casos de prueba
Los casos de prueba son el plan de trabajo del QA. Definen exactamente qué hay que probar, cómo y cuál es el resultado correcto. Un buen conjunto de casos de prueba cubre el happy path, los casos negativos y los edge cases.
Happy path: el flujo ideal donde todo funciona correctamente. Es lo primero que hay que validar, pero solo cubrirlo no es suficiente. Casos negativos: qué pasa cuando algo falla: código inválido, caducado, ya usado... Edge cases: los límites del sistema: descuento mayor que el precio, código con espacios, precio de 0€. Los bugs más frecuentes aparecen aquí.
| ID | Descripción | Pasos | Resultado esperado | Tipo |
|---|---|---|---|---|
| CP-001 | Código válido de porcentaje |
| Precio original tachado, descuento del 10% aplicado, mensaje de confirmación | Happy path |
| CP-002 | Código válido de importe fijo |
| Precio resultante 14,00€ | Happy path |
| CP-003 | Código en minúsculas |
| Descuento aplicado correctamente, no distingue mayúsculas | Edge case |
| CP-004 | Botón deshabilitado con campo vacío |
| Botón deshabilitado, no se puede pulsar | Negativo |
| CP-005 | Código inexistente |
| Mensaje de error. Precio sin cambios | Negativo |
| CP-006 | Código caducado |
| "Este código ha expirado." Precio sin cambios | Negativo |
| CP-007 | Código ya usado por el usuario |
| "Este código ya ha sido utilizado." Precio sin cambios | Negativo |
| CP-008 | Límite global de usos agotado |
| "Este código ya no está disponible." | Negativo |
| CP-009 | Código no válido para ese curso |
| "Este código no es válido para este curso." | Negativo |
| CP-010 | Eliminar código aplicado |
| Precio vuelve al original, campo vacío y habilitado | Happy path |
| CP-011 | Descuento mayor que el precio |
| Precio resultante 0,00€, nunca negativo | Edge case |
| CP-012 | Estado de carga al pulsar "Aplicar" |
| Botón en estado de carga, no se puede pulsar dos veces | UX |
| CP-013 | Persistencia al recargar |
| Código y descuento se mantienen | Persistencia |
| CP-014 | Persistencia al navegar atrás |
| Código y descuento se mantienen | Persistencia |
| CP-015 | Caducidad por inactividad |
| Aviso de código expirado por inactividad | Edge case |
| CP-016 | Intentar aplicar segundo código |
| "Ya tienes un código aplicado. Elimínalo antes de introducir uno nuevo." | Negativo |
| CP-017 | Corregir código inválido y reaplicar |
| Error desaparece al editar, segundo intento aplica correctamente | UX |
| CP-018 | Código con espacios en blanco |
| Sistema elimina espacios automáticamente y aplica el descuento | Edge case |
| CP-019 | Validación en backend |
| Precio cobrado = precio calculado en servidor. La manipulación del DOM no afecta | Seguridad |
| CP-020 | Precio cobrado = precio mostrado |
| Importe cobrado = 44,10€ en checkout, recibo y email de confirmación | Happy path |
| CP-021 | Formato del precio |
| Se muestra 14,00€: con coma, dos decimales y € al final. Nunca 14€ ni 14.00€ | UX |
Puede parecer un tema de seguridad que le corresponde al desarrollador. Pero el QA es quien verifica que el sistema es seguro de principio a fin. Manipular el DOM para alterar precios es una de las técnicas más básicas de fraude en ecommerce: si el backend no valida el precio, cualquiera puede pagar 0€ por cualquier cosa. El QA tiene que probarlo.
Bug report
Ejecutando los casos de prueba anteriores, el CP-021 ha fallado. El botón de pago muestra el precio original en lugar del precio con descuento. Así se documenta correctamente.
Severidad: el impacto técnico del bug. ¿Cómo de grave es el fallo en sí mismo? Prioridad: la urgencia para corregirlo. ¿Cómo de rápido hay que solucionarlo? Un bug puede tener severidad alta pero prioridad media si afecta a algo que no está en producción todavía. O severidad baja pero prioridad alta si está bloqueando el trabajo del equipo.
- 1. Iniciar sesión en 17lab.pro
- 2. Ir al checkout del curso "Consigue tu primer empleo como QA" (19€)
- 3. Introducir el código
BIENVENIDO10en el campo de cupón - 4. Pulsar "Aplicar"
- 5. Observar el resumen de la compra y el botón de pago
Un bug report no es solo documentar lo que falla. Es comunicar el impacto real al desarrollador que lo va a corregir. Las notas finales explican el contexto, sugieren dónde puede estar el problema y dan al dev toda la información que necesita sin tener que preguntar. Un buen bug report ahorra tiempo a todo el equipo.
¿Quieres aprender a hacer esto desde cero?
Todo lo que has visto aquí (historias de usuario, criterios de aceptación, casos de prueba, bug reports) es el trabajo real de un QA Junior. Si quieres aprender a hacerlo bien y conseguir tu primer empleo en el sector, estás en el sitio correcto.
Sigue aprendiendo
Otros recursos gratuitos y cursos que te pueden interesar:
- Glosario QA → Todos los términos del testing organizados por nivel.
- Cómo conseguir tu primer empleo QA → Curso práctico: CV, LinkedIn, entrevistas. 25€.
- Aprender QA desde cero → Curso completo paso a paso hasta tu primer empleo. 49€.
- QA en chatbots con IA → Cómo probar chatbots con IA: prompt injection, alucinaciones y metodología de evals. 49€.