4.

4 DOCUMENTACIN DE RESULTADOS DE LAS

PRUEBAS.

En general se habla mucho de la documentacin, pero no se la hace, no se le asigna

presupuesto, no se la mantiene y casi nunca est al da en los proyectos de desarrollo de
software. Lo importante es la disponibilidad de la documentacin que se necesita en el
momento en que se la necesita.
Muchas veces se hace porque hay que hacerla y se escribe, con pocas ganas, largos
textos, a la vez que se est convencido de estar haciendo un trabajo intil. A veces se
peca por exceso y otras por defecto. Ocurre mucho en la Web y con productos RAD. En
ocasiones se olvida que el mantenimiento tambin debe llegar a la documentacin.
La documentacin se suele clasificar en funcin de las personas o grupos a los cuales
est dirigida:
Documentacin para los desarrolladores
Documentacin para los usuarios
Documentacin para los administradores o soporte tcnico
La documentacin para desarrolladores es aqulla que se utiliza para el propio desarrollo
del producto y, sobre todo, para su mantenimiento futuro. Se documenta para comunicar
estructura y comportamiento del sistema o de sus partes, para visualizar y controlar la
arquitectura del sistema, para comprender mejor el mismo y para controlar el riesgo, entre
otras cosas. Obviamente, cuanto ms complejo es el sistema, ms importante es la
documentacin.
En este sentido, todas las fases de un desarrollo deben documentarse: requerimientos,
anlisis, diseo, programacin, pruebas, etc. Una herramienta muy til en este sentido es
una notacin estndar de modelado, de modo que mediante ciertos diagramas se puedan
comunicar ideas entre grupos de trabajo.
Hay decenas de notaciones, tanto estructuradas como orientadas a objetos. Un caso
particular es el de UML, que analizamos en otra obra. De todas maneras, los diagramas
son muy tiles, pero siempre y cuando se mantengan actualizados, por lo que ms vale
calidad que cantidad.
La documentacin para desarrolladores a menudo es llamada modelo, pues es una
simplificacin de la realidad para comprender mejor el sistema como un todo.
Otro aspecto a tener en cuenta cuando se documenta o modela, es el del nivel de detalle.
As como cuando construimos planos de un edificio podemos hacer planos generales, de
arquitectura, de instalaciones y dems, tambin al documentar el software debemos cuidar
el nivel de detalle y hacer diagramas diferentes en funcin del usuario de la
documentacin, concentrndonos en un aspecto a la vez.
De toda la documentacin para los desarrolladores, nos interesa especialmente en esta
obra aquella que se utiliza para documentar la programacin, y en particular hemos
analizado la que se usa para documentar desarrollos orientados a objetos en el captulo
respectivo.
La documentacin para usuarios es todo aquello que necesita el usuario para la
instalacin, aprendizaje y uso del producto. Puede consistir en guas de instalacin, guas
del usuario, manuales de referencia y guas de mensajes.
En el caso de los usuarios que son programadores, verbigracia los clientes de nuestras
clases, esta documentacin se debe acompaar con ejemplos de uso recomendados o de
muestra y una resea de efectos no evidentes de las bibliotecas.
Ms all de todo esto, debemos tener en cuenta que la estadstica demuestra que los
usuarios no leen los manuales a menos que nos les quede otra opcin. Las razones
pueden ser varias, pero un anlisis de la realidad muestra que se recurre a los manuales
solamente cuando se produce un error o se desconoce cmo lograr algo muy puntual, y
recin cuando la ayuda en lnea no satisface las necesidades del usuario. Por lo tanto,
si bien es cierto que debemos realizar manuales, la existencia de un buen manual nunca
nos libera de hacer un producto amigable para el usuario, que incluso contenga ayuda en
lnea. Es incluso deseable proveer un software tutorial que gue al usuario en el uso del
sistema, con apoyo multimedial, y que puede llegar a ser un curso on- line.
Buena parte de la documentacin para los usuarios puede empezar a generarse desde
que comienza el estudio de requisitos del sistema. Esto est bastante en consonancia con
las ideas de extreme programming y con metodologas basadas en casos de uso.
La documentacin para administradores o soporte tcnico, a veces llamada manual de
operaciones, contiene toda la informacin sobre el sistema terminado que no hace al uso
por un usuario final. Es necesario que tenga una descripcin de los errores posibles del
sistema, as como los procedimientos de recuperacin. Como esto no es algo esttico,
pues la aparicin de nuevos errores, problemas de compatibilidad y dems nunca se
puede descartar, en general el manual de operaciones es un documento que va
engrosndose con el tiempo.

LAS PRUEBAS EN EL DESARROLLO DE SOFTWARE

Calidad, errores y pruebas
La calidad no es algo que se pueda agregar al software despus de desarrollado si no se
hizo todo el desarrollo con la calidad en mente. Muchas veces parece que el software de
calidad es aqul que brinda lo que se necesita con adecuada velocidad de procesamiento.
En realidad, es mucho ms que eso. Tiene que ver con la correccin, pero tambin con
usabilidad, costo, consistencia, confiabilidad, compatibilidad, utilidad, eficiencia y apego a
los estndares.
Todos estos aspectos de la calidad pueden ser objeto de test o pruebas que determinen
el grado de calidad. Incluso la documentacin para el usuario debe ser probada.
Como en todo proyecto de cualquier ndole, siempre se debe tratar que las fallas sean
mnimas y poco costosas, durante todo el desarrollo. Y, adems, es sabido que cuanto
ms tarde se encuentra una falla, ms caro resulta eliminarla. Es claro que si un error es
descubierto en la mitad del desarrollo de un sistema, el costo de su correccin ser
mucho menor al que se debera enfrentar en caso de descubrirlo con el sistema instalado
y en funcionamiento.
Desde el punto de vista de la programacin, nos interesa la ausencia de errores
(correccin), la confiabilidad y la eficiencia. Dejando de lado las dos ltimas, nos
concentraremos en este captulo en las pruebas que determinen que un programa est
libre de errores.
Un error es un comportamiento distinto del que espera un usuario razonable. Puede haber
errores, aunque se hayan seguido todos los pasos indicados en el anlisis y en el diseo,
y hasta en los requisitos aprobados por el usuario. Por lo tanto, no necesariamente un
apego a los requisitos y un perfecto seguimiento de las etapas nos lleva a un producto
sin errores, porque an en la mente de un usuario pudo haber estado mal concebida la
idea desde el comienzo. De all la importancia del desarrollo incremental, que permite ir
viendo versiones incompletas del sistema.
Por lo tanto, una primera fuente de errores ocurre antes de los requerimientos o en el
propio proceso de anlisis. Pero tambin hay errores que se introducen durante el proceso
de desarrollo posterior. As, puede haber errores de diseo y errores de implementacin.
Finalmente, puede haber incluso errores en la propia etapa de pruebas y depuracin.
Categoras de pruebas
Segn la naturaleza de lo que se est controlando, las pruebas se pueden dividir en dos
categoras:
Pruebas centradas en la verificacin
Pruebas centradas en la validacin

Las primeras sirven para determinar la consistencia entre los requerimientos y el programa
terminado. Soporta metodologas formales de testeo, de mucho componente matemtico.
De todas maneras, hay que ser cuidadoso, porque no suele ser fcil encontrar qu es lo
que hay que demostrar. La verificacin consiste en determinar si estamos construyendo
el sistema correctamente, a partir de los requisitos.
En general a los informticos no les gustan las pruebas formales, en parte porque no las
entienden y en parte porque requieren un proceso matemtico relativamente complejo.
La validacin consiste en saber si estamos construyendo el sistema correcto. Las tareas
de validacin son ms informales. Las pruebas suelen mostrar la presencia de errores,
pero nunca demuestran su ausencia.
Las pruebas y el desarrollo de software
La etapa de pruebas es una de las fases del ciclo de vida de los proyectos. Se la podra
ubicar despus del anlisis, el diseo y la programacin, pero dependiendo del proyecto
en cuestin y del modelo de proceso elegido, su realizacin podra ser en forma paralela
a las fases citadas o inclusive repetirse varias veces durante la duracin del proyecto.
La importancia de esta fase ser mayor o menor segn las caractersticas del sistema
desarrollado, llegando a ser vital en sistemas de tiempo real u otros en los que los errores
sean irrecuperables.
Las pruebas no tienen el objeto de prevenir errores sino de detectarlos. Se efectan sobre
el trabajo realizado y se deben encarar con la intencin de descubrir la mayor cantidad de
errores posible.
Para realizar las pruebas se requiere gente que disfrute encontrando errores, por eso no
es bueno que sea el mismo equipo de desarrollo el que lleve a cabo este trabajo. Adems,
es un principio fundamental de las auditoras. Por otro lado, es bastante comn que a
quien le guste programar no le guste probar, y viceversa.
A veces se dan por terminadas las pruebas antes de tiempo. En las pruebas de caja blanca
(ver ms adelante) no es mala idea probar un 85% de las ramas y dar por terminado luego
de esto. Otra posibilidad es la siembra de errores y seguir las pruebas hasta que se
encuentren un 85% de los errores sembrados, lo que presumiblemente implica que se
encontr un 85% de los no sembrados. Otros mtodos se basan en la estadstica y las
comparaciones, ya sea por similitud con otro sistema en cantidad de errores o por el
tiempo de prueba usado en otro sistema.
En un proyecto ideal, podramos generar casos de prueba para cubrir todas las posibles
entradas y todas las posibles situaciones por las que podra atravesar el sistema.
Examinaramos as exhaustivamente el sistema para asegurar que su comportamiento
sea perfecto. Pero hay un problema con esto: el nmero de casos de prueba para un
sistema complejo es tan grande que no alcanzara una vida para terminar con las pruebas.
Como consecuencia, nadie realiza una prueba exhaustiva de nada salvo en sistemas
triviales.
En un sistema real, los casos de prueba se deben hacer sobre las partes del sistema en
los cuales una buena prueba brinde un mayor retorno de la inversin o en las cuales un
error represente un riesgo mayor.
Las pruebas cuestan mucho dinero. Pero para ello existe una mxima: pague por la
prueba ahora o pague el doble por el mantenimiento despus.
Todo esto lleva a que se deban planificar bien las pruebas, con suficiente anticipacin, y
determinar desde el comienzo los resultados que se deben obtener.
La idea de extreme programming es ms radical: propone primero escribir los programas
de prueba y despus la aplicacin, obligando a correr las pruebas siempre antes de una
integracin. Se basa en la idea bastante acertada de que los programas de prueba son la
mejor descripcin de los requerimientos. Esto lo analizamos en un tem especial.
Tipos de pruebas
Analizaremos 5 tipos de pruebas:
Revisiones de cdigo
Pruebas unitarias
Pruebas de integracin
Pruebas de sistema
Pruebas de aceptacin
Revisiones de cdigo
Las revisiones de cdigo son las nicas que se podran omitir de todos los tipos de
pruebas, pero tal vez sea buena idea por lo menos hacer alguna de ellas:
Pruebas de escritorio
Recorridos de cdigo
Inspecciones de cdigo
La prueba de escritorio rinde muy poco, tal vez menos de lo que cuesta, pero es una
costumbre difcil de desterrar. Es bueno concentrarse en buscar anomalas tpicas, como
variables u objetos no inicializados o que no se usan, ciclos infinitos y dems.
Los recorridos rinden mucho ms. Son exposiciones del cdigo escrito frente a pares. El
programador, exponiendo su cdigo, encuentra muchos errores. Adems, da ideas
avanzadas a programadores nuevos que se lleva a recorrer.
Las llamadas inspecciones de cdigo consisten en reuniones en conjunto entre los
responsables de la programacin y los responsables de la revisin. Tienen como objetivo
revisar el cdigo escrito por los programadores para chequear que cumpla con las normas
que se hayan fijado y para verificar la eficiencia del mismo. Se realizan siguiendo el
cdigo de un pequeo porcentaje de mdulos seleccionados al azar o segn su grado de
complejidad. Las inspecciones se pueden usar en sistemas grandes, pero con cuidado
para no dar idea de estar evaluando al programador. Suelen servir porque los revisores
estn ms acostumbrados a ver determinados tipos de errores comunes a todos los
programadores. Adems, despus de una inspeccin a un programador, de la que surge
un tipo de error, pueden volver a inspeccionar a otro para ver si no cay en el mismo
error.
Pruebas unitarias
Las pruebas unitarias se realizan para controlar el funcionamiento de pequeas porciones
de cdigo como ser subprogramas (en la programacin estructurada) o mtodos (en
POO). Generalmente son realizadas por los mismos programadores puesto que al
conocer con mayor detalle el cdigo, se les simplifica la tarea de elaborar conjuntos de
datos de prueba para testearlo.
Si bien una prueba exhaustiva sera impensada teniendo en cuenta recursos, plazos, etc.,
es posible y necesario elegir cuidadosamente los casos de prueba para recorrer tantos
caminos lgicos como sea posible. Inclusive procediendo de esta manera, deberemos
estar preparados para manejar un gran volumen de datos de prueba.
Los mtodos de cobertura de caja blanca tratan de recorrer todos los caminos posibles
por lo menos una vez, lo que no garantiza que no haya errores, pero pretende encontrar
la mayor parte.
El tipo de prueba a la cual se someter a cada uno de los mdulos depender de su
complejidad. Recordemos que nuestro objetivo aqu es encontrar la mayor cantidad de
errores posible. Si se pretende realizar una prueba estructurada, se puede confeccionar
un grafo de flujo con la lgica del cdigo a probar. De esta manera se podrn determinar
todos los caminos por los que el hilo de ejecucin pueda llegar a pasar, y por consecuente
elaborar los juegos de valores de pruebas para aplicar al mdulo, con mayor facilidad y
seguridad.
Un grafo de flujo se compone de:
Nodos (crculos), que representan una o ms acciones del mdulo.
Aristas (flechas), que representan el flujo de control entre los distintos nodos.
Los nodos predicados son aquellos que contienen una condicin, por lo que de ellos
emergen dos o ms aristas.

El paso de un diseo detallado o un pseudocdigo que representa una porcin de

programa a un grafo de flujo, requiere de las siguientes etapas:
Sealar cada condicin, tanto en sentencias if y case como en bucles while y
repeat.
Agrupar todas las sentencias en secuencias siguiendo los esquemas de
representacin de construcciones.
Numerar cada uno de los nodos resultantes de manera que consten de un
identificador nico. Las ramas de cada bifurcacin pueden identificarse por el mismo
nmero seguido de distintas letras.
Dibujar en forma ordenada los nodos y sus aristas.

Pruebas de integracin
En el caso de las pruebas de integracin y de sistema, dado que ya se han realizado las
pruebas unitarias, se tomar a cada uno de los mdulos unitarios como una caja negra.
Las pruebas de integracin tienen como base las pruebas unitarias y consisten en una
progresin ordenada de testeos para los cuales los distintos mdulos van siendo
ensamblados y probados hasta haber integrado el sistema completo. Si bien se realizan
sobre mdulos ya probados en forma individual, no es necesario que se terminen todas
las pruebas unitarias para comenzar con las de integracin. Dependiendo de la forma en
que se organicen, se pueden realizar en paralelo a las unitarias.
El orden de integracin de los mdulos influye en:
La forma de preparar los casos de prueba
Las herramientas a utilizar (mdulos ficticios, muones, impulsores o stubs)
El orden para codificar y probar los mdulos
El costo de preparar los casos
El costo de la depuracin
Tanto es as que se le debe prestar especial atencin al proceso de eleccin del orden de
integracin que se emplee.
Existen principalmente dos tipos de integracin: La integracin incremental y la no
incremental. La integracin incremental consiste en combinar el conjunto de mdulos ya
probados (al principio ser un conjunto vaco) con los siguientes mdulos a probar. Luego
se va incrementando progresivamente el nmero de mdulos unidos hasta que se forma
el sistema completo. En la integracin no incremental o Big Bang se combinan todos los
mdulos de una vez.

Pruebas de sistema
Las pruebas de sistema se realizan una vez integrados todos los componentes. Su
objetivo es ver la respuesta del sistema en su conjunto, frente a distintas situaciones. Se
simulan varias alternativas que podran darse con el sistema implantado y en base a ellas
se prueba la eficacia y eficiencia de la respuesta que se obtiene. Se pueden distinguir
varios tipos de prueba distintos, por ejemplo:
Pruebas negativas: se trata de que el sistema falle para ver sus debilidades.
Pruebas de recuperacin: se simulan fallas de software y/o hardware para verificar
la eficacia del proceso de recuperacin.
Pruebas de rendimiento: tiene como objeto evaluar el rendimiento del sistema
integrado en condiciones de uso habitual.
Pruebas de resistencia o de estrs: comprueban el comportamiento del sistema
ante situaciones donde se demanden cantidades extremas de recursos (nmero de
transacciones simultneas anormal, excesivo uso de las memorias, etc.).
Pruebas de seguridad: se utilizan para testear el esquema de seguridad intentando
vulnerar los mtodos utilizados para el control de accesos no autorizados al sistema.
Pruebas de instalacin: verifican que el sistema puede ser instalado
satisfactoriamente en el equipo del cliente, incluyendo todas las plataformas y
configuraciones de hardware necesarias.
Pruebas de compatibilidad: se prueba al sistema en las diferentes configuraciones
de hardware o de red y de plataformas de software que debe soportar.
Pruebas de aceptacin
Las pruebas de aceptacin, al igual que las de sistema, se realizan sobre el producto
terminado e integrado; pero a diferencia de aquellas, estn concebidas para que sea un
usuario final quien detecte los posibles errores.
Se clasifican en dos tipos: pruebas Alfa y pruebas Beta.
Las pruebas Alfa se realizan por un cliente en un entorno controlado por el equipo de
desarrollo. Para que tengan validez, se debe primero crear un ambiente con las mismas
condiciones que se encontrarn en las instalaciones del cliente. Una vez logrado esto, se
procede a realizar las pruebas y a documentar los resultados.
Cuando el software sea la adaptacin de una versin previa, debern probarse tambin
los procesos de transformacin de datos y actualizacin de archivos de todo tipo.
Por otro lado, las pruebas Beta se realizan en las instalaciones propias de los clientes.
Para que tengan lugar, en primer trmino, se deben distribuir copias del sistema para que
cada cliente lo instale en sus oficinas, dependencias y/o sucursales, segn sea el caso.
Si se tratase de un nmero reducido de clientes, el tema de la distribucin de las copias
no representa grandes dificultades, pero en el caso de productos de venta masiva, la
eleccin de la beta testers debe realizarse con sumo cuidado. En el caso de las pruebas
Beta, cada usuario realizar sus propias pruebas y documentar los errores que
encuentre, as como las sugerencias que crea conveniente realizar, para que el equipo de
desarrollo tenga en cuenta al momento de analizar las posibles modificaciones.
Cuando el sistema tenga un cliente individual, las pruebas de aceptacin se hacen de
comn acuerdo con ste, y los usuarios se determinan en forma programada, as como
tambin se definen los aspectos a probar y la forma de informar resultados. Cuando, en
cambio, se est desarrollando un producto masivo, los usuarios para pruebas se
determinan de formas menos estrictas, y hay que ser muy cuidadoso en la evaluacin del
feedback que proveen. Por lo tanto, en este segundo caso hay que dedicar un esfuerzo
considerable a la planificacin de las pruebas de aceptacin.
Herramientas a usar por los propios programadores
A menudo los programadores pueden insertar lneas de cdigo que faciliten las pruebas y
la depuracin.
Un ejemplo de esto son los invariantes. Por ejemplo, si sabemos que a lo largo de un
programa la variable A debe tener un valor mayor que la B, podemos introducir el
invariante A>B, de modo tal que la implementacin nos avise cuando algn error provoque
la alteracin de ese invariante.
Algunos lenguajes de programacin permiten la definicin de invariantes, pero en la
mayora deben implementarse especialmente.
Otra herramienta prctica son las afirmaciones. Por ejemplo, si en determinado lugar del
cdigo debe cumplirse que A>0, puede declararse esto como un aserto o afirmacin, de
modo que la computadora lo verifique y avise al programador en caso de que no se
cumpla.
Sirven adicionalmente como precondiciones y postcondiciones de mdulos.

4.4 DOCUMENTACIN DE RESULTADOS DE LAS PRUEBAS.

Las pruebas intentan demostrar que un programa hace lo que se intenta que haga, as
como descubrir defectos en el programa antes de usarlo. Al probar el software, se ejecuta
un programa con datos artificiales. Hay que verificar los resultados de la prueba que se
opera para buscar errores, anomalas o informacin de atributos no funcionales del
programa.
El proceso de prueba tiene dos metas distintas:
1. Demostrar al desarrollador y al cliente que el software cumple con los
requerimientos. Para el software personalizado, esto significa que en el
 documento de requerimientos debe haber, por lo menos, una prueba por
cada requerimiento. Para los productos de software genrico, esto
quiere decir que tiene que haber pruebas para todas las caractersticas
del sistema, junto con combinaciones de dichas caractersticas que se
incorporarn en la liberacin del producto.
2. Encontrar situaciones donde el comportamiento del software sea
incorrecto, indeseable o no est de acuerdo con su especificacin. Tales
situaciones son consecuencia de defectos del software. La prueba de
defectos tiene la finalidad de erradicar el comportamiento indeseable del
sistema, como cadas del sistema, interacciones indeseadas con otros
sistemas, clculos incorrectos y corrupcin de datos.
La primera meta conduce a la prueba de validacin; en ella, se espera que el sistema se
desempee de manera correcta mediante un conjunto dado de casos de prueba, que
refleje el uso previsto del sistema. La segunda meta se orienta a pruebas de defectos,
donde los casos de prueba se disean para presentar los defectos. Los casos de prueba
en las pruebas de defecto pueden ser deliberadamente confusos y no necesitan expresar
cmo se usa normalmente el sistema. Desde luego, no hay frontera definida entre estos
dos enfoques de pruebas. Durante las pruebas de validacin, usted descubrir defectos
en el sistema; en tanto que durante las pruebas de defecto algunas de las pruebas
demostrarn que el programa cumple con sus requerimientos.
El diagrama de la figura 8.1 ayuda a explicar las diferencias entre las pruebas de validacin
y de defecto. Piense en el sistema que va a probar como si fuera una caja negra. El
sistema acepta entradas desde algn conjunto de entradas I y genera salidas en un
conjunto de salidas O. Algunas de las salidas sern errneas. Son las salidas en el
conjunto Oe que el sistema genera en respuesta a las entradas en el conjunto Ie. La
prioridad en las pruebas de defecto es encontrar dichas entradas en el conjunto Ie porque
ellas revelan problemas con el sistema. Las pruebas de validacin involucran pruebas con
entradas correctas que estn fuera de Ie y estimulan al sistema para generar las salidas
correctas previstas.
Las pruebas no pueden demostrar que el software est exento de defectos o que se
comportar como se especifica en cualquier circunstancia. Siempre es posible que una
prueba que usted pase por alto descubra ms problemas con el sistema. Como afirma de
forma elocuente Edsger Dijkstra, uno de los primeros contribuyentes al desarrollo de la
ingeniera de software (Dijkstra et al., 1972):
Las pruebas pueden mostrar slo la presencia de errores, mas no su ausencia.
Las pruebas se consideran parte de un proceso ms amplio de verificacin y validacin
(V&V) del software. Aunque ambas no son lo mismo, se confunden con frecuencia. Barry
8.1 MODELO DE ENTRADA Y SALIDA DE UNA PRUEBA DE PROGRAMA
Boehm, pionero de la ingeniera de software, expres de manera breve la diferencia entre
las dos (Boehm, 1979):
Validacin: construimos el producto correcto?.
Verificacin: construimos bien el producto?.
Los procesos de verificacin y validacin buscan comprobar que el software por
desarrollar cumpla con sus especificaciones, y brinde la funcionalidad deseada por las
personas que pagan por el software. Dichos procesos de comprobacin comienzan tan
pronto como estn disponibles los requerimientos y continan a travs de todas las etapas
del proceso de desarrollo.
La finalidad de la verificacin es comprobar que el software cumpla con su funcionalidad
y con los requerimientos no funcionales establecidos. Sin embargo, la validacin es un
proceso ms general. La meta de la validacin es garantizar que el software cumpla con
las expectativas del cliente. Va ms all del simple hecho de comprobar la conformidad
con la especificacin, para demostrar que el software hace lo que el cliente espera que
haga. La validacin es esencial pues, como se estudi en el captulo 4, las
especificaciones de requerimientos no siempre reflejan los deseos o las necesidades
reales de los clientes y usuarios del sistema.
El objetivo final de los procesos de verificacin y validacin es establecer confianza de
que el sistema de software es adecuado. Esto significa que el sistema tiene que ser lo
bastante eficaz para su uso esperado. El nivel de confianza adquirido depende tanto del
pro psit o del sistema y las expectativas de los usuarios del sistema, como del entorno
del mercado actual para el sistema:
1. Propsito del software Cuanto ms crtico sea el software, ms importante debe
ser su confiabilidad. Por ejemplo, el nivel de confianza requerido para que se use
el software en el control de un sistema crtico de seguridad es mucho mayor que el
requerido para un prototipo desarrollado para demostrar nuevas ideas del producto.
2. Expectativas del usuario Debido a su experiencia con software no confiable y
plagado de errores, muchos usuarios tienen pocas expectativas de la calidad del
 software, por lo que no se sorprenden cuando ste falla. Al instalar un sistema, los
usuarios podran soportar fallas, porque los beneficios del uso exceden los costos
de la recuperacin de fallas. Ante tales situaciones, no es necesario dedicar mucho
tiempo en la puesta a prueba del software. Sin embargo, conforme el software se
completa, los usuarios esperan que se torne ms confiable, de modo que pueden
requerirse pruebas exhaustivas en versiones posteriores.
3. Entorno de mercado Cuando un sistema se comercializa, los vendedores del
sistema deben considerar los productos competitivos, el precio que los clientes
estn dispuestos a pagar por un sistema y la fecha requerida para entregar
dicho sistema. En un ambiente competitivo, una compaa de software puede
decidir lanzar al mercado un programa antes de estar plenamente probado y
depurado, pues quiere que sus productos sean los primeros en ubicarse. Si un
producto de software es muy econmico, los usuarios tal vez toleren un nivel
menor de fiabilidad.
Al igual que las pruebas de software, el proceso de verificacin y validacin implicara
inspecciones y revisiones de software. Estas ltimas analizan y comprueban los
requerimientos del sistema, los modelos de diseo, el cdigo fuente del programa, e
incluso las pruebas propuestas para el sistema. stas son las llamadas tcnicas V&V
estticas donde no es necesario ejecutar el software para verificarlo. La figura 8.2
indica que las inspecciones y las pruebas del software soportan V&V en diferentes
etapas del proceso del software. Las flechas sealan las etapas del proceso en que
pueden usarse las tcnicas.
Las inspecciones se enfocan principalmente en el cdigo fuente de un sistema, aun
cuando cualquier representacin legible del software, como sus requerimientos o
modelo de diseo, logre inspeccionarse. Cuando un sistema se inspecciona, se utiliza
el conocimiento del sistema, su dominio de aplicacin y el lenguaje de programacin o
modelado para descubrir errores.
 BIBLIOGRAFIA

AUTOR 1:
http://materias.fi.uba.ar/7507/content/20101/lecturas/documentacion_pruebas.pdf
AUTOR 2:
Sommerville, Ian
Ingeniera de Software
Pgina: 205 CAPITULO 8
PEARSON EDUCACIN, Mxico, 2011 ISBN: 978-607-32-0603-7