El objetivo de esta guía es comparar el resultado esperado con una observación repetible. El caso trabaja con tres unidades: «solicitud vigente», «solicitud duplicada» y «solicitud sin contexto».
Entrada de referencia: solicitudes abiertas con contexto mínimo. Resultado esperado: un backlog depurado con motivo de cada decisión. Antes de asignar trabajo, confirma qué versión de la entrada está vigente y quién revisará el resultado.
Prepara casos que puedan repetirse
Las pruebas de la depuración de un backlog de solicitudes de marketing deben verificar trabajo producido frente a un resultado esperado. Usa solicitudes abiertas con contexto mínimo como referencia y conserva la versión que vas a probar. Para cada caso, describe condición inicial, acción, resultado esperado y evidencia. Incluye un recorrido habitual y un caso que pueda revelar un fallo material. No diseñes una prueba que solo confirme el ejemplo más fácil. Si la persona que la ejecuta necesita preguntar qué significa pasar, mejora la definición antes de interpretar el resultado como evidencia de calidad.
Compara lo esperado con lo observado
Al revisar solicitud vigente, escribe qué esperabas encontrar y qué observaste realmente. Una etiqueta de aprobado sin detalle no permite reconstruir el control. Para solicitud duplicada, conserva el material y el entorno suficientes para repetir la observación. En solicitud sin contexto, confirma el resultado final que recibirá la siguiente persona, en vez de comprobar únicamente la fase de producción. El fallo específico que debes vigilar es mantener prioridades históricas como si siguieran aprobadas. La prueba central consiste en confirmar necesidad, dueño y próxima decisión de cada solicitud. Si la observación no coincide, registra el defecto de forma concreta para que alguien pueda corregirlo sin adivinar qué ocurrió.
Ejemplo aplicado
El backlog ficticio contiene una necesidad vigente, una duplicada y otra que ya no tiene contexto suficiente. La depuración conserva una razón por decisión y un responsable de confirmar dudas. No equivale a borrar peticiones antiguas solo por la fecha en que llegaron.
En el ejemplo participan Nora, Sofia y Valeria. Los nombres, las situaciones y las cifras son ilustrativos; no representan resultados de un cliente. Las tres unidades permiten probar la propuesta antes de extenderla al resto del trabajo.
| Caso de prueba | Esperado | Observado ilustrativo | Decisión |
|---|---|---|---|
| solicitud vigente | Coincide con requisito y versión | Coincidencia verificada | Pasa en la condición probada |
| solicitud duplicada | La referencia es la versión vigente | Se detecta una versión anterior | Corregir y repetir |
| solicitud sin contexto | El receptor puede usar la salida | Verificar después de corregir | No cerrar sin nueva evidencia |
Corrige el fallo y vuelve a ejecutar la prueba
En el ejemplo ilustrativo, el primer caso habitual pasa y un segundo caso detecta una diferencia de versión. El responsable corrige el material, identifica la nueva versión y ejecuta de nuevo el caso que falló. Después comprueba si la corrección afecta al caso que ya había pasado. No marques como superado el control solamente porque se realizó una modificación. La evidencia de cierre debe proceder de una nueva observación del resultado corregido. Este pequeño ciclo separa la intención de arreglar un problema de la verificación de que el problema dejó de aparecer en las condiciones probadas.
Cierra con evidencia suficiente y límites claros
El objetivo es entregar un backlog depurado con motivo de cada decisión con pruebas trazables. Conserva qué se probó, sobre qué versión, cuándo y con qué resultado. Si un caso no pudo ejecutarse, déjalo pendiente y explica su efecto sobre la aceptación. No conviertas una prueba omitida en una aprobación tácita. Cuando una limitación no impida entregar, pide una decisión explícita sobre el riesgo restante. La cobertura de pruebas describe las condiciones observadas; no demuestra que todos los casos posibles sean correctos. Esa precisión permite reutilizar la evidencia sin atribuirle un alcance mayor del que realmente tiene.
Qué comprobar antes de cerrar
El riesgo que debes controlar en este caso es mantener prioridades históricas como si siguieran aprobadas. Una etiqueta de terminado necesita una observación que la respalde. Conserva estos elementos junto a la decisión para que el receptor pueda comprobar qué se revisó:
- Entrada y versión utilizadas: solicitudes abiertas con contexto mínimo.
- Control del caso: confirmar necesidad, dueño y próxima decisión de cada solicitud.
- Resultado que se revisa: un backlog depurado con motivo de cada decisión.
