En el entorno acelerado del desarrollo de software, la brecha entre lo que un interesado imagina y lo que un desarrollador construye puede ser enorme. Esta brecha a menudo se cierra mediante el Criterios de aceptación de historias de usuario. Para los equipos de garantía de calidad (QA), estos criterios no son solo una lista de verificación; son el contrato de calidad. Cuando se redactan claramente, transforman la ambigüedad en escenarios de prueba accionables.
Muchos equipos tienen dificultades con requisitos ambiguos. Frases como «amigable para el usuario» o «carga rápida» aparecen con frecuencia en borradores iniciales, pero no resisten el escrutinio de pruebas rigurosas. Esta guía proporciona un enfoque estructurado para elaborar criterios de aceptación comprobables que empoderan a los ingenieros de QA, reducen la fuga de defectos y garantizan la alineación entre las funciones de Producto, Desarrollo y Pruebas.
🎯 Por qué importan los criterios de aceptación comprobables
Los Criterios de Aceptación (CA) definen los límites de una historia de usuario. Especifican las condiciones que deben cumplirse para considerar que la historia está completa. Para los profesionales de QA, estas declaraciones sirven como fundamento para la creación de casos de prueba. Sin ellas, las pruebas se convierten en un juego de adivinanzas.
- Claridad en las expectativas: Los criterios claros eliminan los errores de interpretación entre los roles.
- Pruebas eficientes: Las condiciones específicas permiten a los probadores redactar casos de prueba precisos de inmediato.
- Reducción de rehacer: La ambigüedad con frecuencia lleva a construir la característica incorrecta. Una buena AC evita este desperdicio.
- Soporte para pruebas automatizadas: Las declaraciones comprobables son requisitos previos para los scripts de automatización.
Cuando los CA son ambiguos, el equipo de QA debe dedicar tiempo a aclarar los requisitos durante la iteración, ralentizando la entrega. Cuando los CA son precisos, la atención se centra completamente en la validación y la garantía de calidad.
🔍 Características de una declaración comprobable
No todo requisito es comprobable. Una declaración solo es válida si puede verificarse objetivamente. Para garantizar la comprobabilidad, los criterios deben seguir los siguientes principios:
- No ambiguo: Solo existe una interpretación de la declaración.
- Verificable: Es posible confirmar el paso o el fracaso mediante observación o datos.
- Atómico: Cada criterio aborda una sola condición, no un requisito compuesto.
- Relevante: Está directamente relacionado con el objetivo de la historia de usuario.
- Consistente: No contradice otros criterios ni las restricciones del sistema.
Considere la diferencia entre el lenguaje subjetivo y el objetivo. Los términos subjetivos dependen de la opinión, mientras que los términos objetivos dependen de los datos.
📉 Ejemplos de subjetivo frente a objetivo
| Subjetivo (evitar) | Objetivo (objetivo) |
|---|---|
| La página debe cargarse rápidamente. | La página debe cargarse en menos de 2 segundos en una conexión 3G. |
| El sistema debe ser seguro. | Las contraseñas deben estar cifradas utilizando el cifrado SHA-256. |
| Los usuarios deben encontrar fácil navegar. | Los usuarios pueden acceder a la página de pago en menos de 3 clics desde la página de inicio. |
| El informe debe verse bien. | El informe debe mostrar un total de 5 columnas con encabezados alineados. |
Observe cómo las versiones objetivas proporcionan métricas, métodos o conteos específicos. Estos permiten a un probador realizar una decisión de aprobación o rechazo sin consultar al propietario del producto.
🛠 Técnicas para redactar criterios de aceptación
Existen varios formatos para documentar los criterios de aceptación. La elección depende de la madurez del equipo y de la complejidad de la funcionalidad. A continuación se presentan los métodos más efectivos.
1. Enunciados en lenguaje claro
Las oraciones simples y declarativas funcionan bien para funcionalidades sencillas. Este enfoque es accesible para los interesados no técnicos.
- Cuando el usuario hace clic en el botón de enviar, aparece un mensaje de éxito.
- Cuando el usuario ingresa un correo electrónico inválido, se muestra un mensaje de error debajo del campo.
- El sistema no debe permitir la creación de cuentas duplicadas con la misma dirección de correo electrónico.
2. Sintaxis Gherkin (Dado/Cuando/Entonces)
Este formato se alinea estrechamente con el Desarrollo Dirigido por el Comportamiento (BDD). Estructura los criterios en Contexto, Acción y Resultado. Es altamente preferido para flujos de trabajo complejos.
- Dado: El usuario está en la página de inicio de sesión.
- Cuando: El usuario ingresa un nombre de usuario y contraseña válidos.
- Entonces: El sistema redirige al usuario al panel de control.
Esta estructura obliga al redactor a considerar explícitamente las condiciones previas y los resultados esperados.
3. Formato de lista de verificación
A veces una lista de condiciones es suficiente, especialmente para actualizaciones de la interfaz de usuario o cambios de configuración. Cada elemento representa una condición comprobable.
- El encabezado muestra el logotipo de la empresa.
- La barra de navegación permanece fija en la parte superior durante el desplazamiento.
- El pie de página contiene el año de derechos de autor y enlaces legales.
- El formulario de contacto requiere nombre y apellido.
🤝 Estrategias de colaboración
Escribir los criterios de aceptación rara vez es una tarea solitaria. Requiere aportes del Propietario del Producto, Desarrolladores y Ingenieros de QA. La sesión de los «Tres Amigos» es una práctica común en la que estas tres funciones se reúnen para definir los criterios juntos.
Objetivos clave de colaboración
- Comprensión compartida:Asegúrese de que todos interpreten los requisitos de la misma manera.
- Verificación de viabilidad:Los desarrolladores confirman si los criterios son técnicamente alcanzables.
- Revisión de comprobabilidad:QA asegura que los criterios puedan verificarse sin ambigüedad.
- Identificación de casos límite:El grupo discute qué sucede cuando las cosas salen mal.
Al involucrar a QA desde una etapa temprana de redacción, se identifican bloqueos potenciales antes de comenzar la codificación. Esto reduce el riesgo de encontrar defectos críticos al final del ciclo.
⚠️ Trampas comunes y patrones negativos
Incluso equipos experimentados caen en trampas al escribir criterios. Reconocer estos patrones ayuda a mantener una alta calidad.
1. Incluir detalles de implementación técnica
Los criterios de aceptación deben describirquéhace el sistema, nocómolo hace. Los detalles de implementación pertenecen a los documentos de diseño técnico.
- Malo:La base de datos debe usar una tabla MySQL llamada usuarios.
- Bueno:El sistema debe almacenar las credenciales del usuario de forma segura y recuperarlas para la autenticación.
2. Sobrecarga de múltiples características
Cada criterio debe abordar un comportamiento específico. Combinar múltiples comportamientos crea una condición compleja que es difícil de probar.
- Mal: El usuario puede iniciar sesión y ver su foto de perfil.
- Bueno: El usuario puede iniciar sesión. El perfil del usuario muestra la imagen cargada.
3. Usar frases negativas en exceso
Aunque las pruebas negativas son importantes, demasiadas afirmaciones de tipo «no debe» pueden oscurecer el flujo principal.
- Mal: El sistema no debe permitir valores nulos. El sistema no debe permitir cadenas vacías. El sistema no debe permitir caracteres especiales.
- Bueno: El sistema valida los campos de entrada para asegurarse de que contengan únicamente caracteres alfanuméricos y no estén vacíos.
4. Ignorar los requisitos no funcionales
Los criterios funcionales son vitales, pero también importan el rendimiento, la seguridad y la accesibilidad. Estos deben incluirse si afectan la experiencia del usuario.
- El tiempo de respuesta no debe exceder los 200 ms para las búsquedas.
- La interfaz debe admitir la navegación con teclado para todos los elementos interactivos.
- La transmisión de datos debe estar cifrada mediante HTTPS.
🧩 Casos límite y condiciones de borde
Las rutas normales de éxito son fáciles de escribir. El verdadero valor de la garantía de calidad reside en explorar los límites. Los criterios de aceptación deben mencionar explícitamente cómo el sistema maneja entradas extremas o inusuales.
Categorías de casos límite
- Valores cero: ¿Qué sucede si una cantidad es 0?
- Límites máximos: ¿Cuál es el recuento máximo de caracteres para un campo de texto?
- Estados nulos: ¿Cómo se representa la interfaz de usuario cuando faltan datos?
- Acciones concurrentes: ¿Qué sucede si dos usuarios editan el mismo registro al mismo tiempo?
- Fallos de red: ¿Cómo se comporta el sistema cuando se desconecta la internet?
Ejemplo de un criterio de caso límite:
- Si un usuario intenta subir un archivo mayor a 50 MB, el sistema muestra un mensaje de error y rechaza el archivo.
🔄 Mantenimiento y Evolución
Los criterios de aceptación no son documentos estáticos. A medida que el producto evoluciona, también deben evolucionar los criterios. Refactorizar el código a menudo requiere actualizar los criterios para que coincidan con los nuevos comportamientos.
Mejores prácticas de mantenimiento
- Revisión durante la planificación del sprint:Revise historias antiguas para asegurarse de que los criterios aún coincidan con el comportamiento actual.
- Actualización tras corregir un error:Si un error revela una condición faltante, agréguela a los criterios de aceptación de inmediato.
- Archivar criterios obsoletos:Elimine los criterios que ya no aplican para evitar confusiones.
- Control de versiones:Mantenga un historial de los cambios en los criterios para fines de auditoría.
Mantener los criterios actualizados asegura que las pruebas de regresión sigan siendo efectivas. Los criterios desactualizados generan falsos positivos, donde las pruebas pasan aunque la funcionalidad haya cambiado.
📊 Medición de la calidad de los criterios de aceptación
¿Cómo sabe si sus criterios de aceptación están funcionando? Utilice métricas para evaluar su efectividad con el tiempo.
- Cobertura de casos de prueba:Una alta cobertura indica criterios claros. Una baja cobertura sugiere ambigüedad.
- Fuga de defectos:Si los errores escapan a producción y contradicen los criterios de aceptación, es probable que estos últimos hayan sido insuficientes.
- Tiempo de aclaración:Monitoree cuánto tiempo pasa QA haciendo preguntas sobre los requisitos. Un tiempo alto indica criterios de aceptación deficientes.
- Tasa de automatización:Las altas tasas de automatización se correlacionan con criterios comprobables y sin ambigüedades.
Las revisiones regulares pueden ayudar a los equipos a discutir estas métricas y ajustar su proceso de redacción en consecuencia.
🔗 Integración con la Definición de Listo
Los criterios de aceptación son específicos de una historia de usuario. La Definición de Listo (DoD) se aplica a toda la liberación o sprint. Trabajan juntos pero cumplen propósitos diferentes.
- DoD: “Todo el código revisado”, “Todas las pruebas unitarias pasaron”, “Documentación actualizada.” (Estándares globales)
- AC: “El usuario puede restablecer la contraseña mediante correo electrónico.” (Específico de la funcionalidad)
Una historia solo está completa cuando se cumplen ambos criterios de aceptación y se satisface el criterio de finalización. Los equipos de QA deben verificar ambas capas para dar su aprobación a una funcionalidad.
💡 Ejemplos prácticos
Para consolidar la comprensión, veamos un ejemplo completo de una historia de usuario con criterios deficientes y mejorados.
Historia: Funcionalidad de restablecimiento de contraseña
❌ Criterios de aceptación deficientes
- El usuario puede restablecer la contraseña.
- El sistema envía un correo electrónico.
- El enlace expira después de un tiempo.
- La seguridad es importante.
✅ Criterios de aceptación mejorados
- Dado que el usuario está en la página de inicio de sesión, cuando hace clic en «¿Olvidó la contraseña?», se redirige al formulario de restablecimiento.
- Cuando el usuario ingresa una dirección de correo electrónico registrada y envía el formulario, aparece un mensaje de confirmación en pantalla.
- Se envía un correo electrónico que contiene un enlace único de restablecimiento dentro de los 5 minutos.
- El enlace de restablecimiento expira 24 horas después de su generación.
- Si el usuario ingresa un código incorrecto, el sistema muestra un error y permite un nuevo intento.
- Las nuevas contraseñas deben cumplir con los requisitos de complejidad (8 caracteres, 1 número, 1 símbolo).
La versión mejorada permite a QA redactar casos de prueba específicos para el tiempo de envío de correos, la caducidad del enlace y las reglas de complejidad de contraseñas.
🚀 Avanzando
Escribir criterios de aceptación verificables es una habilidad que mejora con la práctica. Requiere disciplina para evitar un lenguaje vago y un compromiso con la claridad. Al centrarse en enunciados objetivos y verificables, los equipos de QA pueden reducir la ambigüedad y entregar software de mayor calidad.
Comience auditando sus historias actuales. Identifique criterios que dependan de opiniones o métricas ambiguas. Reescriba estos criterios para incluir condiciones específicas. Fomente la colaboración entre roles para asegurar una comprensión compartida. Con el tiempo, la reducción de defectos y el retraso en el trabajo repetido validarán el esfuerzo.
Recuerde, el objetivo no es solo escribir texto. El objetivo es definir la calidad. Cuando los criterios son precisos, las pruebas son eficientes y el producto es confiable.