Qué es la verificación de software: qué comprueba y qué no

La verificación de software es el conjunto de comprobaciones orientadas a determinar si un producto o resultado de ingeniería se ajusta a los requisitos y especificaciones que le corresponden. La pregunta práctica es: «¿se construyó de acuerdo con lo definido?». En el marco de ingeniería de sistemas de la NASA, la verificación compara el producto con sus requisitos o especificaciones; esta distinción también sirve para entender programas, componentes y entregables de software. NASA: verificación de producto

La verificación no es una actividad única que se realiza necesariamente al final. Puede aplicarse a diferentes entregables durante el desarrollo: una especificación puede revisarse frente a necesidades previamente acordadas; un diseño, frente a requisitos; y una implementación, frente al diseño o a criterios técnicos. El referente debe estar explícito: si no hay un requisito identificable, no se puede afirmar con claridad qué condición se comprobó. La secuencia concreta depende del proyecto y no debe confundirse con una receta universal.

Verificar tampoco equivale a declarar que todo el software es correcto, seguro o útil en cualquier situación. Una comprobación aporta evidencia sobre un alcance determinado, con criterios y condiciones determinados. Si se revisó un cálculo concreto, por ejemplo, esa evidencia no demuestra automáticamente que todas las funciones, versiones, datos de entrada o entornos se comporten de forma adecuada.

Los objetos de verificación pueden incluir requisitos, diseño, código ejecutable, componentes integrados y documentación asociada, siempre que haya criterios aplicables para compararlos. La página de la NASA describe la verificación de un producto final como una comprobación de conformidad con requisitos o especificaciones, y subraya la importancia de mantener una configuración de referencia controlada. La misma lógica se aplica por alcance: cada afirmación debe identificar qué elemento y qué versión se examinaron. NASA: verificación de producto

En un ejemplo sencillo, un requisito podría indicar que una aplicación debe calcular un total a partir de cantidades y precios. La verificación puede comprobar que la fórmula implementada concuerda con la regla especificada y que el resultado coincide con el esperado en los casos examinados. Si la propia regla está mal planteada —por ejemplo, omite un descuento necesario para el uso real—, el programa podría ajustarse a ella y aun así no satisfacer la necesidad. Esa diferencia es el motivo para no tratar verificación y validación como sinónimos.

La documentación también importa porque define qué se considera conforme y qué actividad se llevó a cabo. Un plan de verificación y validación puede registrar responsabilidades, documentos aplicables, métodos y matrices que relacionen requisitos con evidencias. El esquema publicado por la NASA incluye secciones diferenciadas para métodos de verificación y validación, implementación y matrices de requisitos. La trazabilidad ayuda a localizar cobertura y vacíos, pero una matriz completa no constituye por sí misma prueba de que cada resultado sea correcto. NASA: esquema de plan de verificación y validación

Una verificación puede reunir distintas formas de examen. Una revisión humana compara documentos o cambios con criterios definidos; un análisis puede buscar propiedades o inconsistencias sin ejecutar el programa; y una prueba observa el comportamiento del software al ejecutarlo bajo condiciones elegidas. La información del NIST sobre sus actividades de formación en verificación y validación destaca la documentación de evidencia y el uso de técnicas de ambos tipos, aunque sus ejemplos se centran en hojas de cálculo de laboratorios y no establecen una lista exhaustiva para todos los proyectos. NIST: formación sobre verificación y validación de software

Un ejemplo de comprobación frente a una especificación

Supongamos que una especificación exige que un sistema rechace una solicitud cuando falte un campo obligatorio. Una revisión podría comprobar que el requisito está definido y que el diseño contempla ese caso; una prueba podría enviar una solicitud incompleta y comparar la respuesta observada con el resultado esperado. Cada método cubre una pregunta distinta: la revisión examina artefactos y razonamientos; la prueba observa un comportamiento bajo entradas y condiciones concretas.

Las pruebas no examinan todas las entradas posibles por el mero hecho de ejecutarse. El resultado depende de qué casos se seleccionaron, qué versión se probó y qué entorno se usó. En consecuencia, «pasó las pruebas» significa que no se detectó una discrepancia en las comprobaciones realizadas, no que se haya demostrado la ausencia de defectos. La evidencia es más interpretable si se conserva la relación entre requisito, criterio de aceptación, caso ejecutado, resultado y versión del producto.

Una práctica útil de registro

Para que otra persona pueda entender qué se verificó, conviene registrar el elemento y la versión examinados, el requisito asociado, el método aplicado, las condiciones relevantes y el resultado. En actividades donde importan controles o auditoría, ese registro permite explicar el alcance y revisar cambios posteriores. El NIST presenta la documentación de evidencia y la evaluación continuada del software como objetivos de sus recursos de formación para laboratorios; el alcance concreto de cada registro debe adecuarse al contexto. NIST: formación sobre verificación y validación de software

La verificación pregunta si el producto concuerda con los requisitos o especificaciones definidos. La validación pregunta si el producto satisface el uso previsto y las necesidades relevantes en su contexto de utilización. La NASA expresa la diferencia mediante dos preguntas: si el producto se realizó correctamente respecto de lo especificado y si cumple lo que el cliente pretendía dentro del entorno de uso. NASA: verificación de producto

La tabla resume la distinción de propósito descrita por la NASA; no implica que cada actividad use un método exclusivo ni que haya una frontera rígida entre técnicas. NASA: verificación de producto

Consideremos una aplicación que calcula el coste de un envío. Si la especificación dice que debe sumar tarifa base y recargo, comprobar ese cálculo es verificación. Preguntar si la aplicación contempla las necesidades reales —por ejemplo, si el flujo permite indicar el destino y el tipo de entrega que el servicio ofrece— pertenece a la validación. El primer control puede resultar satisfactorio mientras el segundo descubre que se definió una solución que no sirve para el uso esperado.

Por eso no basta con decir que un producto «está verificado» sin precisar el referente y el alcance. Tampoco significa que la validación sustituya toda comprobación frente a especificaciones: ambas perspectivas pueden ser necesarias y complementarias. Los procesos descritos por la NASA separan sus objetivos, aunque reconoce que algunas actividades pueden parecerse en la práctica. La etiqueta depende de la pregunta que se intenta responder, no solo de que la actividad se llame prueba o revisión.

La evidencia puede consistir en resultados de pruebas, observaciones de revisiones, análisis documentados o matrices que vinculen requisitos con comprobaciones. No todas estas evidencias prueban lo mismo: un resultado de ejecución respalda una observación para unas entradas y un entorno concretos; una revisión puede documentar que se evaluó un artefacto frente a criterios. La conclusión no debe exceder la evidencia ni extenderse a versiones o condiciones que no se examinaron.

La trazabilidad ayuda a seguir el vínculo entre un requisito y la actividad que pretende comprobarlo. El esquema de planificación de la NASA propone tanto una matriz de verificación de requisitos como una matriz de validación, además de documentar métodos y actividades. Esto ofrece una estructura para ordenar evidencias, no una garantía automática de que los requisitos estén bien formulados, sean completos o reflejen las necesidades de los usuarios. NASA: esquema de plan de verificación y validación

Un ejemplo: si se cambia una regla de cálculo, saber qué requisitos, componentes y casos de comprobación están asociados permite revisar el impacto del cambio. Pero un vínculo documental puede estar desactualizado o no cubrir un comportamiento importante. La gestión de versiones y la revisión de la evidencia siguen siendo necesarias; una lista de casillas marcadas es útil solo si describe actividades reales, resultados interpretables y el artefacto correcto.

Verificar es una práctica acotada, no una prueba matemática de perfección. Los defectos pueden permanecer porque no se examinaron ciertos casos, porque los criterios eran incompletos o porque el entorno real difiere del utilizado. También es posible cumplir literalmente una especificación que no representa bien la necesidad. Por eso, una declaración responsable identifica qué se revisó, con qué referencia y bajo qué condiciones, en lugar de afirmar que el software está libre de errores.

En proyectos de riesgo elevado o sometidos a requisitos de control, la independencia de la revisión puede ser relevante. El glosario del NIST describe la verificación y validación independientes como una revisión, análisis y prueba realizados por una tercera parte objetiva para examinar tanto la definición de requisitos como la implementación de las funciones y requisitos de seguridad. Esa descripción corresponde a IV&V; no significa que todo proyecto necesite necesariamente un equipo externo ni que la independencia elimine los límites de cobertura. NIST: glosario de verificación y validación independientes

Para leer una afirmación de verificación o planear una comprobación, estas preguntas ayudan a concretar su alcance:

• ¿Qué producto, componente, documento y versión se examinó?
• ¿Contra qué requisito, especificación o criterio se comparó?
• ¿Qué método se aplicó y en qué condiciones?
• ¿Qué evidencia quedó registrada y qué casos no cubre?
• ¿La pregunta era de conformidad con lo especificado o de adecuación al uso previsto?

La norma ISO/IEC/IEEE 12207 ofrece un marco de procesos del ciclo de vida del software, pero las fuentes reunidas para esta pieza no incluyen el texto oficial de la norma. Por ello, este glosario no atribuye requisitos concretos a esa norma ni presenta una receta normativa. La orientación aquí expuesta se apoya principalmente en documentación de la NASA sobre verificación y validación de productos y en recursos del NIST sobre evidencia y IV&V; las técnicas específicas deben elegirse según el sistema, sus riesgos y sus obligaciones aplicables. NASA: verificación de producto NIST: IV&V