PRUEBAS Y DOCUMENTACIÓN

INTRODUCCION
"Verificación y Validación" es el nombre genérico dado a los procesos de chequeo
que aseguran que el software satisface sus especificaciones y cubre las necesidades del
cliente. El sistema debe ser verificado y validado en cada paso del proceso del
software utilizando la documentación producida durante el paso anterior.
La verificación y validación comienza entonces con la revisión de los
requerimientos y continúa a través de la revisión del diseño y la codificación hasta la
prueba del producto. Aunque la verificación y la validación suelen confundirse,
realmente son actividades diferentes.
La diferencia entre ellas puede describirse brevemente (Boehm, 1979) como:
• La verificación es: ¿Estamos construyendo bien el producto?
• La validación es: ¿Estamos construyendo el producto adecuado?
La verifi cación su pone com prob ar q ue el pro grama satisface sus
especificaciones. La validación supone comprobar que el programa, según se ha
implementado, cumple con las expectativas del cliente.

VERIFICACIÓN Y VALIDACIÓN DEL SOFTWARE

La verificación y validación del software esta formada por un conjunto de
procedimientos, actividades, técnicas y herramientas que se utilizan, en paralelo al
proceso de desarrollo de software, para asegurar que un producto software
resuelve el problema planteado inicialmente. Para mejorar la corrección final del
producto, la verificación y validación actúa sobre los productos intermedios
generados por la metodología utilizada durante el desarrollo, para detectar y
corregir cuanto antes los defectos y desviaciones respecto al objetivo fijado.
La visión del desarrollo de software, formada por un conjunto de fases con
posibles realimentaciones, no solo facilita el desarrollo, sino también el esfuerzo
de la verificación y validación. Se puede dividir el esfuerzo de verificación y
validación indicando las actividades, procedimientos y técnicas a emplear en cada
fase del ciclo de vida. Para ello, es necesario definir un Plan de Verificación y
Validación del Software al inicio del proyecto que determine estas actividades.
La estructura de este plan de verificación y validación, propuesta por el estándar
de IEEE es la siguiente:
1. Propósito.
2. Documentos de referencia.
3. Definiciones.
4. Visión general de la verificación y validación.
4.1. Organización.
4.2. Programa de tiempos.
4.3. Resumen de recursos.
4.4. Responsabilidades.

| PRUEBAS Y DOCUMENTACIÓN 1
 4.5. Herramientas, técnicas y metodologías.
5. Verificación y validación en el ciclo de vida.
5.1. Gestión de la V y V.
5.2. V y V de la fase de concepto.
5.3. V y V de la fase de requisitos.
5.4. V y V de la fase de diseño.
5.5. V y V de la fase de implementación.
5.6. V y V de la fase de pruebas.
5.7. V y V de la fase de instalación.
5.8. V y V de la fase de explotación y mantenimiento.
6. Informes de la V y V del software.
7. Procedimientos administrativos de la V y V.
7.1. Informe y resolución de anomalías
7.2. Política de iteración de ideas
7.3. Política de desviación
7.4. Procedimientos de control
7.5. Estándares, prácticas y convenciones

La verificación y validación persigue fundamentalmente los siguientes objetivos:

Detectar y corregir los defectos tan pronto como sea posible en el ciclo de vida.

Disminuir los riesgos, las desviaciones sobre los presupuestos y sobre el
programa de tiempos del proyecto.

Mejorar la calidad y fiabilidad del software.

Mejorar la visibilidad de la gestión del proceso de desarrollo.

Valorar rápidamente los cambios propuestos y sus consecuencias.
Las actividades de verificación y validación son iterativas. Al realizar cambios durante
el desarrollo, se deben volver a realizar ciertas tareas seleccionadas de verificación y
validación de la fase previa del ciclo de vida o actividades adicionales de verificación
y validación para ocuparse de los cambios. Podemos además distinguir las
actividades propias de la verificación y de la validación:
• Validación: el objetivo es determinar la corrección del producto final
respecto a las necesidades del usuario. Quizá la principal técnica de
validación consiste en las pruebas de software.
• Verificación: el objetivo es demostrar que el software es
consistente, completo y correcto entre las fases del ciclo de desarrollo de
un proyecto. Los procedimientos principales para llevar a cabo las
actividades de verificación son las revisiones de software (aunque
también sirven para la validación, puesto que comprueban que lo que
se está haciendo se ajusta a las necesidades de los usuarios.
Para satisfacer los objetivos del proceso de verificación y validación, se deben utilizar
técnicas tanto estáticas como dinámicas de chequeo y análisis del sistema. Las técnicas
estáticas se refieren al análisis y comprobación de representaciones del sistema
como los documentos de requerimientos, diagramas de diseño y el código fuente

| PRUEBAS Y DOCUMENTACIÓN 2
del programa. Deben aplicarse en todas las etapas del proceso a través de revisiones
estructuradas.
Las técnicas dinámicas o pruebas incluyen ejercitar la implementación. Las técnicas
estáticas se pueden utilizar en todas las etapas del proceso del software. Sin embargo,
las técnicas dinámicas sólo se pueden aplicar cuanto está disponible un prototipo o
un programa ejecutable. Las técnicas estáticas incluyen inspecciones de
programa, análisis y verificación formal.
Algunos puristas han sugerido que estas técnicas deberían reemplazar
completamente a las técnicas dinámicas en el proceso de verificación y validación,
y que la prueba es innecesaria. Esto no tiene mucho sentido puesto que las técnicas
estáticas sólo pueden probar la correspondencia entre un programa y sus
especificaciones (verificación); no pueden demostrar que el software es
operacionalmente útil.
Aunque las técnicas de verificación estática se están comenzando a utilizar más
ampliamente, la prueba de programas sigue siendo la técnica de verificación y
validación predominante. La prueba incluye ejercitar el programa utilizando datos de
los que realmente procesará el programa. La existencia de defectos del programa o
elementos inadecuados se infiere a partir de las salidas no esperadas del sistema.

EL PROCESO DE PRUEBA
Excepto para programas pequeños, los sistemas no deberían probarse como un único
elemento indivisible. Los sistemas grandes se construyen a partir de subsistemas
que se construyen a partir de módulos, compuestos de funciones y procedimientos. Por
lo tanto, el proceso de prueba debería trabajar por etapas, llevando a cabo la
prueba de forma incremental a la vez que se realiza la implementación del
sistema.
El proceso de ingeniería del software se puede ver come una espiral.
Inicialmente, la ingeniería del sistema define el papel del software y conduce al
análisis de los requisitos del software, donde se establece el campo de información, la
función, el comportamiento, el rendimiento, las restricciones y los criterios de
validación del software. Al movernos hacia el interior de la espiral, llegamos al
diseño y, por último, a la codificación. Para desarrollar software de computadora,
damos vueltas en espiral a través de una serie de flujos o líneas que disminuyen el
nivel de abstracción en cada vuelta.
Análogamente, podemos imaginar el proceso de prueba del software si nos movemos hacia
afuera de la espiral de la figura anterior. La prueba de unidad comienza en el vértice de
la espiral y se centra en cada unidad del software, tal como esta implementada en código
fuente. La prueba avanza, al movernos hacia afuera de la espiral, hasta llegar a la prueba de
donde el foco de atención es el diseño y la construcción de la arquitectura del software.
Dando otra vuelta por la espiral hacia afuera, encontramos la prueba de donde se validan
los requisitos establecidos como parte del análisis de requisitos del software, comparándolos
con el sistema que ha sido construido. Finalmente, llegamos a la prueba en la que se
prueban como un todo el software y otros elementos del sistema. Para probar software
de computadora nos movemos hacia fuera por una espiral que, a cada vuelta, aumenta el
alcance de la prueba.

| PRUEBAS Y DOCUMENTACIÓN 3
Si consideramos el proceso desde el punto de vista del procedimiento la prueba, en el
contexto de la ingeniería del software, realmente es una serie de tres pasos que se llevan a cabo
secuencialmente. Inicialmente, la prueba de unidad se centra en cada módulo individual,
asegurando que funcionan adecuadamente como una unidad. A continuación se deben
ensamblar o integrar los módulos para formar el paquete de software completo. Después de
que el software se ha integrado, se dirigen un conjunto de pruebas para comprobar los criterios
de validación.
El último paso de prueba queda fuera de los límites de la ingeniería del software, entrando en
el más amplio contexto de la ingeniería de sistemas de computadora. El software, una vez
validado, se debe combinar con otros elementos del sistema (hardware, gente, bases de datos).
Por lo tanto, las etapas a seguir durante el proceso de prueba son:
• Pruebas de unidad: La prueba de unidad se centra en cada módulo
individual, asegurando que funcionan adecuadamente como una unidad.
Cada componente se prueba de forma independiente, sin otros componentes
del sistema.
• Prueba de integración: Una vez desarrollados los módulos, éstos se deben
ensamblar o integrar para formar el paquete de software completo. La
prueba de se dirige a todos los aspectos asociados con el doble problema de
verificación y de construcción del programa. El problema más común que
ocurre en sistemas software grandes es la no concordancia entre las interfaces
de los subsistemas. El proceso de prueba debe por tanto concentrarse en la
detección de errores de interfaz ejercitándolas de forma rigurosa.
Durante la integración, las técnicas que más prevalecen son las de diseño
de casos de prueba de la caja negra aunque se pueden llevar a cabo unas
pocas pruebas de la caja blanca con el fin de asegurar que se cubren
los principales caminos de control.

PRUEBA DE VALIDACIÓN
Después de que el software se ha integrado (construido), se dirigen un conjunto
de pruebas para comprobar los criterios de validación (establecidos durante el
análisis de requisitos). La prueba de validación proporciona una seguridad
final de que el software satisface todos los requisitos funcionales, de
comportamiento y de rendimiento. Se prueba el sistema con datos aportados por el
sistema real en lugar de con datos simulados. La prueba de aceptación puede revelar
errores y omisiones en la definición de requisitos del sistema debido a que los datos
reales ejercitan el sistema de forma diferente a los datos de prueba. Puede revelar
problemas de requerimientos donde las facilidades del sistema no cumplen
realmente con las necesidades del usuario o el rendimiento del sistema es
inaceptable. Durante la validación se usan exclusivamente técnicas de prueba de la
caja negra.
La prueba de aceptación se denomina a veces prueba alpha. Este proceso continua
hasta que el desarrollador y el cliente están de acuerdo en que el sistema es una
implementación aceptable de los requerimientos.
También se utiliza a menudo la prueba beta, consistente en dar el sistema a varios
clientes potenciales para que lo utilicen e informen de posibles errores. Esto
expone el sistema al use real y puede revelar errores no detectados por los
constructores del sistema.
| PRUEBAS Y DOCUMENTACIÓN 4
PRUEBA DEL SISTEMA
El último paso de prueba queda fuera de los límites de la ingeniería del software,
entrando en el más amplio contexto de la ingeniería de sistemas de computadora. El
software, una vez validado, se debe combinar con otros elementos del sistema
(hardware, gente, bases de datos). La prueba del sistema verifica que cada elemento
en caja de forma adecuada y que se alcanza la funcionalidad y el rendimiento del
sistema total. Esta constituida por una serie de pruebas diferentes, entre las que destacan
la prueba de recuperación, la prueba de seguridad, la prueba de resistencia y la prueba
de rendimiento.

| PRUEBAS Y DOCUMENTACIÓN 5