Respuesta.

Historia de la pregunta

Los criterios de aceptación son un conjunto de requisitos que deben cumplirse para que el trabajo (lanzamiento, tarea, caso de prueba) se considere completo. En las pruebas manuales, las condiciones claramente definidas ayudan a evitar errores, malentendidos y "deficiencias ocultas".

Problema

La falta de criterios transparentes conduce a diferentes interpretaciones de "listo": el desarrollador considera que la tarea está cerrada, el probador no ve todo claro, y el cliente espera conformidad con la lógica del negocio.

Solución

Desarrollar criterios medibles, claros y no contradictorios (por ejemplo, "el botón funciona", "los datos se guardan al actualizar la página", "no surgen errores de validación"). Es importante acordar el DoD entre el cliente, el probador y el desarrollador, reflejar los cambios en los requisitos y registrar el cumplimiento de los criterios para cada historias/issues.

Características clave:

Ayudan a evitar malentendidos y expectativas innecesarias.
Forman listas de verificación para pruebas manuales.
Ayudan a centrar la atención en lo importante.

Preguntas engañosas.

¿Es obligatoria la realización de todos los criterios para cerrar una tarea?

Sí, esa es la esencia del DoD: la tarea se considera completa solo cuando se cumplen todos los criterios.

¿Se puede cambiar el DoD durante el proceso de pruebas o lanzamiento?

Sí, si los requisitos han cambiado o hay nuevos detalles, pero todos los miembros del equipo deben estar al tanto, especialmente el probador.

¿Quién debe definir el DoD?

Todo el equipo en conjunto, incluyendo a los probadores, desarrolladores, analistas de negocio y representantes del cliente.

Errores típicos y anti-patrones

Fórmulas generales y poco claras como "la función funciona".
Cambios no fijados en los criterios sobre la marcha.
Ignorar el DoD durante el lanzamiento o aceptación.

Ejemplo de la vida real

Caso negativo

La tarea fue aceptada sin criterios formalizados: a un colega le parecía que todo funcionaba. El cliente encuentra un "bug oculto" al día siguiente. El probador afirma que el bug no pertenecía a la tarea.

Ventajas:

Cierre rápido de tareas.

Desventajas:

Defectos críticos pasados por alto.
Situaciones conflictivas con el cliente.

Caso positivo

Antes de las pruebas, se forman criterios específicos, y después de ejecutar cada uno se marca manualmente su cumplimiento. Cualquier cambio se registra y se acuerda con el equipo.