¿Qué Es User Story Testing?
En desarrollo Agile, los requerimientos se capturan como user stories — descripciones cortas de funcionalidad desde la perspectiva del usuario. User story testing deriva test cases de estas historias y sus criterios de aceptación.
Formato de User Story
Como [rol],
Quiero [acción],
Para que [beneficio].
Ejemplo:
Como cliente registrado,
Quiero filtrar productos por rango de precio,
Para poder encontrar rápidamente productos dentro de mi presupuesto.
Las 3 C’s de User Stories
| C | Significado | Impacto en Testing |
|---|---|---|
| Card | La historia escrita | Proporciona el alcance del test |
| Conversation | Discusión con stakeholders | Revela requerimientos ocultos y edge cases |
| Confirmation | Criterios de aceptación | Fuente directa de test cases |
Criterios de Aceptación en Given/When/Then
Given que estoy en la página de listado de productos
And hay productos con precios de $5 a $500
When configuro el filtro de precio a $20 - $100
Then debo ver solo productos con precio entre $20 y $100
And el conteo de productos debe actualizarse
And la URL debe incluir los parámetros del filtro
Given = Precondición (setup del test) When = Acción (paso del test) Then = Resultado esperado (aserción del test)
Ejemplo Completo: Story con Criterios de Aceptación
Story: Como cliente registrado, quiero agregar items a una lista de deseos para guardar productos para compra futura.
Criterios de Aceptación:
AC1: Given que estoy logueado, When hago click en “Agregar a Lista de Deseos” en un producto, Then el producto aparece en mi lista de deseos.
AC2: Given que no estoy logueado, When hago click en “Agregar a Lista de Deseos,” Then soy redirigido a la página de login.
AC3: Given que un producto ya está en mi lista de deseos, When hago click en “Agregar a Lista de Deseos,” Then veo “Ya está en la lista de deseos.”
AC4: Given que tengo items en mi lista, When veo la lista, Then veo todos los items ordenados por fecha (más recientes primero).
AC5: Given que tengo items en mi lista, When hago click en “Eliminar” en un item, Then el item se elimina y la lista se actualiza.
Derivando Test Cases de ACs
| TC | AC | Tipo | Test |
|---|---|---|---|
| TC1 | AC1 | Positivo | Usuario logueado agrega producto → aparece en lista |
| TC2 | AC2 | Positivo | No logueado → redirigir a login |
| TC3 | AC3 | Positivo | Producto ya en lista → mensaje mostrado |
| TC4 | AC4 | Positivo | Ver lista → ordenada por fecha |
| TC5 | AC5 | Positivo | Eliminar item → eliminado de la lista |
| TC6 | AC1 | Negativo | Agregar producto sin stock → ¿debería permitirse? |
| TC7 | AC4 | Edge | Lista vacía → mostrar estado vacío |
| TC8 | AC1 | Edge | Agregar mismo producto desde diferentes páginas → solo una entrada |
| TC9 | AC5 | Edge | Eliminar último item → estado vacío mostrado |
Criterios INVEST para Stories Testeables
| Letra | Criterio | Impacto en Testing |
|---|---|---|
| I | Independiente | Se puede probar de forma aislada |
| N | Negociable | Los ACs pueden evolucionar |
| V | Valiosa | El valor guía la prioridad de tests |
| E | Estimable | Alcance claro para estimar esfuerzo |
| S | Pequeña | Cabe en un sprint — alcance manejable |
| T | Testeable | Existen criterios de aceptación claros |
Si una story no es Testeable, escala antes de que comience el desarrollo.
User Story Testing Avanzado
Más Allá de los Criterios de Aceptación
Los ACs cubren el “qué,” pero los testers también deben considerar:
| Aspecto | Preguntas |
|---|---|
| Performance | ¿Qué tan rápido debe cargar la lista con 100 items? |
| Seguridad | ¿Puede el usuario A ver la lista del usuario B? |
| Accesibilidad | ¿Pueden los screen readers navegar la lista? |
| Compatibilidad | ¿Funciona en browsers móviles? |
| Datos | ¿Cuál es el tamaño máximo de la lista? |
| Concurrencia | ¿Qué si el usuario agrega un item desde dos dispositivos? |
BDD: Automatizando Tests de Stories
Los criterios de aceptación en Given/When/Then pueden automatizarse con frameworks BDD:
Feature: Lista de Deseos de Productos
Scenario: Agregar producto a lista de deseos
Given estoy logueado como "cliente@test.com"
And estoy viendo el producto "Widget Azul"
When hago click en "Agregar a Lista de Deseos"
Then "Widget Azul" debería aparecer en mi lista
And debería ver un mensaje "Agregado a lista de deseos"
Scenario: Intentar agregar producto duplicado
Given estoy logueado como "cliente@test.com"
And "Widget Azul" ya está en mi lista
When hago click en "Agregar a Lista de Deseos" en "Widget Azul"
Then debería ver "Ya está en la lista de deseos"
And el conteo de mi lista no debería cambiar
Ejercicio: Escribe Tests para una User Story
Story:
Como gerente de equipo,
Quiero asignar tareas a miembros del equipo,
Para que el trabajo se distribuya y rastree.
Criterios de Aceptación:
- AC1: Puedo seleccionar un miembro del equipo y asignarlo a una tarea
- AC2: El miembro asignado recibe notificación por email
- AC3: Puedo reasignar una tarea a un miembro diferente
- AC4: Puedo ver todas las tareas asignadas a cada miembro en un dashboard
- AC5: Solo los gerentes pueden asignar tareas (miembros regulares no pueden)
Tarea: Escribe test cases cubriendo todos los ACs, más agrega al menos 3 tests negativos/edge cases no cubiertos por los ACs.
Pista
Piensa en: asignarse a ti mismo, asignar a un miembro desactivado, asignar cuando no hay miembros, asignación masiva, notificaciones cuando el email está deshabilitado.
Solución
Desde ACs: 7 test cases (positivos + variantes de AC3 y AC5)
Tests adicionales:
| TC | Tipo | Test |
|---|---|---|
| TC8 | Edge | Asignar tarea a ti mismo |
| TC9 | Edge | Asignar a miembro desactivado |
| TC10 | Edge | Asignar cuando no hay miembros en el dropdown |
| TC11 | Negativo | Asignar tarea ya completada |
| TC12 | Concurrencia | Dos gerentes asignan la misma tarea simultáneamente |
| TC13 | Performance | Dashboard con 500+ tareas carga en menos de 3 segundos |
Total: 13 test cases.
Tips de Profesional
- Asiste a las sesiones de refinamiento. La “Conversation” es donde descubrirás la mayoría de los edge cases y requerimientos implícitos.
- Escribe tests antes del desarrollo. Esto es shift-left testing — encontrar ambigüedades en los ACs antes de escribir código ahorra retrabajo enorme.
- No pruebes solo lo que está escrito. Los ACs son un punto de partida, no el alcance completo. Siempre agrega tests negativos, edge cases y no funcionales.
- Vincula test cases a ACs. La trazabilidad ayuda a probar cobertura e identificar vacíos durante el sprint review.
- Usa story testing para mejorar las stories. Si no puedes escribir tests claros de una story, la story necesita refinamiento.