Probar el producto contra su comportamiento previsto
Las pruebas basadas en especificaciones son una etapa de verificación definida en el marco SHAPE. Un agente o contexto de modelo de verificación, separado del contexto de implementación del agente de programación, lee el conjunto de especificaciones registradas en el repositorio y deriva comprobaciones de lo que debe hacer el software. Después ejercita la implementación cuando es práctico y registra el resultado contra los requisitos.
La separación importa porque un agente implementador puede reproducir sus propios malentendidos en las pruebas que escribe a partir del código que acaba de producir. La derivación independiente desde las especificaciones ofrece un punto de referencia diferente. Es una comprobación adicional útil, no una afirmación de que los modelos sean intrínsecamente objetivos o estén libres de errores.
Qué recibe el verificador
El verificador necesita las especificaciones pertinentes, suficiente contexto legítimo para comprender el comportamiento previsto y medios autorizados para inspeccionar o ejercitar la aplicación. No debe tratar el comportamiento actual de la implementación como prueba de lo que significa la especificación. Cuando la especificación sea ambigua, esa ambigüedad debe comunicarse, no resolverse silenciosamente como un requisito nuevo.
Qué hace el verificador
Para cada requisito significativo, derive comprobaciones representativas positivas, negativas, de límites y de permisos, según corresponda. Ejercite las interacciones de usuario, las interfaces de la aplicación u otros comportamientos observables desde el exterior cuando sea viable. Identifique qué requisitos se probaron, qué evidencias se observaron y qué comprobaciones no pudieron completarse. Las pruebas unitarias, de integración y de extremo a extremo existentes siguen siendo valiosas; la verificación independiente basada en especificaciones las complementa.
Comunicar los resultados
Un informe útil distingue entre Correcto, Fallo, Bloqueado y Necesita aclaración. Un resultado correcto identifica el comportamiento observado y su vínculo con un requisito esperado. Un fallo registra la discrepancia y cómo reproducirla. Bloqueado identifica una limitación del entorno, de los datos o del acceso. Necesita aclaración identifica una especificación que no permite emitir un juicio defendible.
El Product Engineer cierra el ciclo
Los hallazgos vuelven al Product Engineer, quien decide si debe cambiar el software, aclararse la especificación o someterse una limitación a la decisión de otro especialista o de una parte interesada. Las correcciones se prueban de nuevo. La especificación sigue siendo la referencia del comportamiento previsto; los cambios aceptados de esa intención deben registrarse en lugar de adaptar silenciosamente las pruebas a una implementación accidental.
Lo que esto no puede demostrar
Un agente de verificación puede no detectar un problema, interpretar mal un requisito o generar una cobertura de pruebas incompleta. Una especificación con todas sus pruebas satisfactorias también puede omitir una necesidad empresarial importante. Las garantías de seguridad, rendimiento, accesibilidad y cumplimiento normativo pueden requerir técnicas especializadas más allá de la verificación por funcionalidades. Las pruebas basadas en especificaciones no sustituyen la revisión del arquitecto, el criterio de UX ni las UAT.
Dónde aprender el procedimiento
La guía para profesionales Ejecutar pruebas basadas en especificaciones proporciona un flujo de trabajo repetible y un ejemplo de registro de resultados. El Proyecto de referencia muestra cómo es una trazabilidad pequeña entre especificaciones y pruebas.