Propósito
Las pruebas basadas en especificaciones evalúan la aplicación contra el comportamiento esperado registrado mediante un agente o contexto de verificación separado del contexto de implementación del agente de programación. Proporcionan una comprobación adicional de las suposiciones de implementación y hacen trazables los resultados de verificación hasta las especificaciones.
Participantes responsables: Agente o contexto de verificación independiente, coordinado por el Product Engineer.
Entradas: Conjunto pertinente de especificaciones registradas en el repositorio, acceso autorizado a la aplicación y al entorno de pruebas, restricciones conocidas, datos representativos disponibles.
Resultados: Correspondencia entre requisitos y comprobaciones, resultados observados, fallos reproducibles, casos bloqueados o ambiguos y tratamientos de seguimiento.
Procedimiento
1. Establecer un contexto independiente. Comience la verificación desde las especificaciones registradas en el repositorio y no desde la descripción que el agente de programación hace de su trabajo terminado. El verificador no debe utilizar el comportamiento existente como definición de corrección.
2. Identificar los requisitos pertinentes. Lea las especificaciones de funcionalidades pertinentes y el comportamiento compartido al que hagan referencia. Para una mejora, incluya requisitos que puedan verse afectados por el cambio. Señale los requisitos demasiado ambiguos para permitir una prueba defendible.
3. Derivar comprobaciones. Produzca comprobaciones que cubran comportamientos normales importantes, caminos de validación y rechazo, límites, diferencias de permisos y transiciones de estado cuando corresponda. Vincule las comprobaciones a identificadores estables de especificación o a condiciones claramente identificables.
4. Ejercitar el comportamiento real. Utilice el entorno de pruebas autorizado para operar la interfaz o API pertinente y observar el resultado. Cuando un requisito no pueda ejercitarse, registre el motivo en lugar de inventar un resultado correcto. La inspección estática por sí sola no debe describirse como una verificación completa del comportamiento.
5. Registrar resultados y evidencias. Utilice cuatro tratamientos claros: Correcto, Fallo, Bloqueado o Necesita aclaración. Un fallo útil indica qué requisito se infringió, qué se esperaba, qué ocurrió y cómo reproducirlo. Las evidencias pueden adoptar la forma permitida por las herramientas y las restricciones de privacidad del proyecto.
6. Clasificar con el Product Engineer. Determine si cada problema es un defecto de implementación, una capacidad de prueba ausente, una especificación ambigua o un cambio legítimo de la intención aceptada. Remita las decisiones sobre reglas empresariales a sus responsables. Actualice las especificaciones cuando cambie la intención aceptada.
7. Corregir y volver a ejecutar. Implemente las correcciones aprobadas y repita las comprobaciones afectadas junto con las comprobaciones de regresión pertinentes. Conserve la distinción entre un requisito que ha superado la prueba y uno que aún no se ha ejercitado.
8. Preparar el resumen de verificación. Indique el alcance comprobado, los fallos o bloqueos pendientes, las limitaciones de cobertura y cualquier aclaración sin resolver. Ponga esta información a disposición de la revisión final del arquitecto o de la revisión aplicable del ciclo de mejora y de la preparación de las UAT.
Ejemplo de registro de resultados
| Comprobación de especificación | Comportamiento esperado | Resultado observado | Estado | Siguiente acción |
|---|---|---|---|---|
| SPEC-001 / AC-01 | No puede enviarse una solicitud con campos obligatorios ausentes | Se impidió el envío y se indicó la categoría ausente | Correcto | Ninguna |
| SPEC-001 / AC-03 | Solo los revisores autorizados pueden decidir sobre las solicitudes asignadas | Se rechazó el intento de decisión no autorizado | Correcto | Ninguna |
| SPEC-001 / AC-05 | El rechazo requiere un motivo | La solicitud pasó a Rechazada con un motivo vacío | Fallo | Corregir el comportamiento y volver a probar |
| SPEC-001 / AC-07 | El solicitante no puede ver los datos privados de otro solicitante | No había identidades de prueba representativas disponibles | Bloqueado | Preparar una capacidad de prueba aprobada |
Esta tabla ilustra el tratamiento; sus resultados de ejemplo son ficticios, no evidencias de una implementación real.
Criterios de finalización
Los requisitos significativos tienen tratamientos documentados; los fallos y las ambigüedades se abordan o se trasladan explícitamente conforme a la política de aceptación establecida; las limitaciones de las pruebas son transparentes; y los cambios han recibido las nuevas pruebas adecuadas. El informe no exagera las garantías que proporciona.
Problemas habituales que conviene evitar
Pedir al agente implementador que certifique su propio resultado sin una fuente independiente de intención; aceptar una lista generada de pruebas que nunca se ejecutaron; tratar silenciosamente las comprobaciones bloqueadas como satisfactorias; editar especificaciones para ajustarlas a un comportamiento accidental; y presentar el éxito de las pruebas como sustituto de las UAT o de garantías especializadas sobre el riesgo.