Checklist de criterios de aceptación de software

Empieza mientras la ambigüedad puede cambiar el plan

Redacta criterios al refinar el brief y antes de comprometer implementación. Incluye producto, diseño, ingeniería, calidad y especialistas necesarios. Pregunta qué logra el usuario, qué estado existe antes y qué observación muestra éxito. Si el equipo no acuerda el resultado, el elemento no está listo para estimación o construcción fiable.

Detén y divide criterios que combinan resultados, usan adjetivos vagos o prescriben una técnica sin motivo. Intuitivo, rápido, seguro y fluido requieren límites observables. Dos revisores autorizados deben alcanzar la misma conclusión, dejando decisiones de implementación a quienes responden por la solución.

Inventaría conducta, datos y dimensiones de fallo

Por recorrido lista actor y rol, estado inicial, acción, resultado de interfaz, mutación de datos, mensajes, efectos y eventos de auditoría o analítica relevantes. Añade vacío, carga, inválido, duplicado, no autorizado, expirado, sin conexión y dependencia fallida. Incluye idioma, dispositivo y tecnología de asistencia requerida.

Separa reglas de negocio de detalle visual e identifica la fuente de verdad. Registra dependencias y conducta ante respuesta tardía, parcial o rechazada. No copies datos sensibles en ejemplos. Usa fixtures representativas y nombra quién aprueba conducta excepcional si un juicio no puede automatizarse.

Escribe ejemplos y asigna verificación

Usa frases claras o Dado, Cuando, Entonces si reduce interpretaciones. Cada ejemplo ejercita una regla. Añade casos negativos y límites, no solo camino feliz. Enlaza criterio con story, diseño, contrato API o política para resolver conflictos desde una autoridad explícita.

Nombra nivel y evidencia: unidad o integración automatizada, recorrido en navegador o dispositivo, accesibilidad, seguridad, rendimiento o aprobación manual. Indica entorno y datos. Automatizar ayuda pero no es obligatorio para cada juicio. Un control manual necesita pasos, resultado y registro.

Acepta con las puertas de calidad del producto

Revisa criterios y definición de terminado, que puede incluir revisión, pruebas, accesibilidad, seguridad, despliegue, monitorización y documentación. Registra versión y criterios fallidos o exceptuados. Una excepción tiene responsable, razón, impacto, vencimiento o revisión y mitigación. No conviertas un fallo en limitación conocida sin decisión.

Define la aceptación con evidencia observable, por ejemplo un recorrido probado, una compilación aprobada, controles reproducibles, un runbook de incidentes y un traspaso verificado. Nada de eso demuestra retención, ingresos o encaje de mercado. Separa evidencia de entrega, aprobación de proveedores externos y resultado comercial.

Conserva criterios hasta release y transferencia

Mantén checks, guiones manuales, fixtures, informes y decisiones con los sistemas del producto. Actualiza si cambia una decisión y conserva historia útil. En la transferencia, otra persona ejecuta caminos críticos y localiza reglas fuente. Los criterios se convierten en conocimiento operativo y no en una firma de una sola vez.

Mantén repositorios, dominios, tiendas, analítica, organizaciones cloud y credenciales de producción bajo propiedad explícita de la empresa. Concede acceso limitado y revocable y ensaya el traspaso antes de la factura final. La etiqueta del proveedor importa menos que la capacidad de otra persona autorizada para inspeccionar, desplegar, recuperar y continuar el producto.

Criterios de decisión

Aplica las mismas preguntas a cada opción antes de elegir.