Pruebas de Software

Qu son las pruebas de software?

Las pruebas, vistas desde el marco de un proceso de desarrollo de software, son los diferentes
procesos que se deben realizar durante un desarrollo, con el objetivo de asegurar que este
completo, correcto, tenga calidad, entre otros factores de gran importancia.
Consisten en llevar a cabo la verificacin dinmica de un componente, programa o sistema,
mediante el uso de mtodos, tcnicas y herramientas especializadas, las cuales permiten detectar
y corregir errores, problemas e inconsistencias durante el proceso de desarrollo.
Estas, al contrario de lo que muchas personas creen, no se deben dejar para el final de la etapa de
construccin del software. Las pruebas se deben empezar a realizar desde la misma etapa de
anlisis de los requerimientos, ya que desde un principio se puede caer en malas interpretaciones
de las "reglas del negocio", lo que finalmente tendr como consecuencia incongruencia entre lo
que el cliente quiere y lo que se ha desarrollado.

Por qu probar el software a desarrollar?

Debido a que los procesos serios de desarrollo de software, en la mayora de los casos tienden a
ser caticos, es necesario involucrar procesos de aseguramiento de la calidad, para que se puedan
cumplir de manera correcta los requerimientos que el cliente necesita. Por otro lado, el costo que
implica reparar un defecto que es descubierto en etapas avanzadas del desarrollo de software, tal
como la implementacin, es muy alto, hablando en trminos del presupuesto del proyecto, como
tambin en el cronograma. Por tal razn, se implementan las pruebas de software desde los
comienzos del desarrollo.
Qu ventajas tiene la creacin de pruebas para el desarrollo de software?
Principalmente, las ventajas que trae la realizacin de pruebas, en un desarrollo de software son
las siguientes:

Reducen la posibilidad de agregar defectos al software. Si hay que realizar

una adicin de caractersticas requeridas por el cliente y se ve que ya no funcionan
bien algunas de las cosas que anteriormente servan, se puede inferir la nueva
funcionalidad es la que contiene defectos, por lo que no hay necesidad realizar
modificaciones a los componentes realizados anteriormente.

Reducen la posibilidad de encontrar defectos en funcionalidades ya implementadas.

Las pruebas son buena documentacin. Es preferible ver unas pequeas lneas de
"Cdigo de prueba", que son concisas y realmente son fciles de entender, a revisar lnea por lnea
de cdigo para poder entender que hace determinado componente de software.
Reducen el costo del cambio. Ya que evitan que se descubran los defectos hasta el final
del desarrollo de software.
Permiten realizar reimplementacin. Se puede llegar a necesitar reimplementar
determinada funcionalidad en un sistema, debido a fallos de seguridad, rendimiento, o simplemente
por que no reuna lo que el cliente esperaba de ste, entonces dada tal situacin, las pruebas que
a realizar a dicha funcionalidad van a permitir que se vuelva a desarrollar de manera segura, ya
que la prueba encierra el criterio de aceptacin sobre la funcionalidad, permitiendo de esta forma
que se vuelva a desarrollar algo acorde con la especificacin.
Restringe las caractersticas a implementar. Muchas veces los programadores pierden
tiempo en detalles que la especificacin no peda. Con las pruebas el programador sabe que tiene
que programar dicha funcionalidad y tambin probarla, por lo que se restringe a lo que los
diseadores de las pruebas hayan realizado.
Hacen que el desarrollo sea ms rpido. Ya que a medida que se agregan
caractersticas al software, las funcionalidades anteriores pueden fallar, pero si se han hecho las
pruebas pertinentes a las funcionalidades anteriores, se puede descartar inmediatamente que
existan defectos en stas, por lo que se puede concentrar tranquilamente en la funcionalidad
nueva.
Quin debe realizar las pruebas?
Las pruebas deben ser diseadas y ejecutadas por personal diferente al que realiz el anlisis de
las reglas del negocio, tambin de las personas que realizaron los diseos y principalmente, deben
ser diferentes a las que realizaron la labor de programacin.
Por qu estas personas?

En la labor de desarrollo de software existen varios roles que cumplen los integrantes del proyecto,
entre esos los siguientes:
Analistas, Diseadores y Programadores:
Este grupo de personas poseen un punto de vista
creativo, ya que ellos son los que a partir de una
necesidad del cliente, disean, analizan y
codifican una solucin informtica. Debido a esa
situacin ellos no alcanzan a divisar los posibles
defectos que tiene el software que ellos
realizaron.
Analista de Calidad: Ellos se enfocan en entender las
reglas del negocio, requerimientos, casos de uso y
todas aquellas cosas que ayuden a comprender el
negocio. Este grupo de personas poseen por decirlo de
alguna manera un punto de vista destructivo, ya que
ellos saben que determinada parte del programa tiene
que llevar a cabo ciertas funciones, y ellos en su
quehacer tratan de encontrar defectos a la
funcionalidad realizada por otra persona.
Principios.
1. A todas las pruebas se les debera poder hacer un seguimiento hasta los requerimientos del
cliente/usuario.
2. Las pruebas deberan planificarse antes de que empiecen. La planificacin de las pruebas puede

empezar cuando estn completos los requerimientos.

3. Las pruebas deberan empezar de lo individual a lo general.
A) Mdulos individuales
B) Grupos de mdulos integrados
C) Sistema total.
4. Para ser ms efectiva las pruebas deberan ser conducidas por un equipo independiente.

Planeacin.
En este punto se deben de cubrir ciertos puntos para realizar las pruebas:
Conocer el propsito de la prueba.
Definir el lugar, fecha y duracin de la misma.
Determinar el hardware y software necesarios para llevarse a cabo.
Definir el estado del sistema al iniciar la prueba.
Integrar facilitadores y nivel de participacin.
Definir a los usuarios participantes.
Especificar las tareas a desarrollar por los usuarios.
Establecer criterios de terminacin de tareas.
Crear materiales de apoyo para usuarios.
Especificar mtodos de recoleccin y anlisis de datos resultantes.
Proceso.
Las pruebas de software son una tarea tcnica, y como tal son un proceso que, en primer lugar,
necesita del dominio del lenguaje de programacin en el que el producto que se va a checar fue
creado, tambin del conocimiento indispensable para comprender la arquitectura del sistema
implementado adems de las implicaciones de tipo lgico que el diseo pueda suponer.
Adicionalmente, la persona que lo pruebe deber conocer los lenguajes y herramientas que se han
de usar para llevar a cabo este proceso de pruebas.
Las pruebas de software son elementos bsicos para determinar la calidad del software. La
relevancia de los costos asociados a los errores conllevan a la definicin y aplicacin de un
proceso de pruebas minuciosas y bien planificadas. Las pruebas permiten validar (proceso que
determina si el software satisface los requisitos previamente establecidos) y verificar (proceso para
determinar si los productos de un fase satisfacen las condiciones de sta) el software.
Clasificacin.

Pruebas del camino bsico. Propuesta por Tom McCabe, permite al diseador de casos
de prueba que pueda obtener una medida de la complejidad lgica en un diseo
procedimental y usar sta como gua para llegar a definir un conjunto elemental de
caminos de ejecucin. Los casos de prueba derivados de ste ltimo garantizan que
durante la prueba se ejecuta por lo menos una vez cada sentencia de programa.
Un camino independiente es cualquier camino del programa que introduce por lo menos un
nuevo conjunto de sentencias de procesamiento o una nueva condicin.
Pruebas de Unidad. Las pruebas unitarias tienen como objetivo verificar la funcionalidad y
estructura de cada componente individualmente una vez que ha sido codificado.
1. Caja Negra. Son pruebas que se llevan a cabo directamente en la interfaz del
software. Se comprueba el correcto funcionamiento de los componentes del
sistema de informacin, analizando las entradas y salidas y verificando que el
resultado es el esperado. Se consideran exclusivamente las entradas y salidas del
sistema sin preocuparse por la estructura interna del mismo. Errores que se
pretenden detectar: funciones incorrectas o ausentes, errores de interfaz, errores

en las estructuras de datos, errores de rendimiento, errores de inicializacin y

terminacin. Algunos tipos son:
Particin Equivalente. Es un mtodo que divide el campo de entrada de un
programa en clases de datos de los que se pueden derivar casos de prueba. Un
caso de prueba correcto descubre de manera inmediata una clase de errores.

Se dirige a la definicin de casos de prueba que descubran clases de errores,

reduciendo as el nmero de casos de prueba que hay que desarrollar. El diseo
de estos casos se basa en una evaluacin de las clases de equivalencia para una
condicin de entrada. Una clase de equivalencia representa un conjunto de
estados vlidos o invlidos para condiciones de entrada.
Anlisis de valores lmite (AVL). Esta tcnica es un complemento para la
anterior. En lugar de seleccionar cualquier elemento de una clase de equivalencia,
se lleva a la eleccin de casos de prueba a los extremos de la clase. En lugar de
centrarse nicamente en las condiciones de entrada, tambin se derivan casos de
prueba para el campo de salida.
2. Caja Blanca. Se prueban procedimientos del software. Se verifica la
estructura interna del componente con independencia de la
funcionalidad establecida para el mismo. Por tanto, no se comprueba la
correccin de los resultados, slo si stos se producen. Algunas clases de
pruebas:
Pruebas de cubrimiento.
Pruebas de condiciones. Es un mtodo de diseo de casos de prueba
que ejercita las condiciones lgicas contenidas en un mdulo de un
programa. Se basa en el criterio de que si un conjunto de pruebas de un
programa es efectivo para detectar errores en las condiciones que se
encuentran en el programa, es probable que el conjunto de pruebas sea
tambin efectivo para detectar otros errores en el programa.
Pruebas de bucles. Los bucles son la parte ms importante de la
mayora de los algoritmos implementados en software. Es una tcnica
que se centra principalmente en la validez de las construcciones de
bucles y existen estos tipos de ellos:
1. Bucles simples
2. Bucles anidados
3. Bucles concatenados
4. Bucles no estructurados
3. Trayectoria.

Pruebas de Integracin. El objetivo de las pruebas de integracin es verificar el correcto

ensamblaje entre los distintos componentes una vez que han sido probados unitariamente

con el fin de comprobar que interactan correctamente a travs de sus interfaces, tanto
internas como externas, cubren la funcionalidad establecida y se ajustan a los requisitos no
funcionales. En las pruebas de integracin se examinan las interfaces entre grupos de
componentes o subsistemas para asegurar que son llamados cuando es necesario y que
los datos que se transmiten son los requeridos.
1. Ascendente. Es la estrategia tradicional empleada para integrar los componentes
de un sistema de software en un todo funcionando. Consiste en pruebas de
unidad, seguidas por pruebas de subsistemas y luego por pruebas del sistema
completo. Las primeras tienen el objetivo de descubrir errores en los mdulos
individuales del sistema. Las pruebas de unidad deben ser tan exhaustivas como
sea posible para garantizar que se ha probado cada caso representativo manejado
por cada mdulo. dichas pruebas se facilitan por una estructura que se componga
de mdulos pequeos y dbilmente acoplados.
2. Descendente. Empieza con la rutina principal y una o dos rutinas inmediatamente
subordinadas en la estructura del sistema. despus de que el esqueleto de alto
nivel ha sido probado con detenimiento, se convierte en el arreo de prueba para
sus subrutinas inmediatamente subordinadas. La integracin de alto nivel requiere
el uso de troncos de programa para simular el efecto de rutinas de ms bajo nivel
que son llamadas rutinas en prueba.
3. Regresin. Son una estrategia de prueba en la cual las pruebas que se han
ejecutado anteriormente se vuelven a realizar en la nueva versin modificada, para
asegurar la calidad despus de aadir la nueva funcionalidad. El propsito de
estas pruebas es asegurar que:

Los defectos identificados en la ejecucin anterior de la prueba se ha corregido.

Los cambios realizados no han introducido nuevos defectos o reintroducido
defectos anteriores.
La prueba de regresin puede implicar la re-ejecucin de cualquier tipo de prueba. Normalmente,
las pruebas de regresin se llevan a cabo durante cada iteracin, ejecutando otra vez las pruebas
de la iteracin anterior.
Pruebas de Validacin. La validacin se logra cuando se logran cumplir las expectativas
que tiene el cliente al cual se esta desarrollando el producto y se lleva a cabo mediante
algunas pruebas como:
1. Alfa. Es una prueba que es llevada a cabo por un cliente en el mismo lugar en el
que se desarrollo el producto. Se usa el software de manera normal pero con algn
encargado del desarrollo checando el uso que le da el usuario y registrando
errores y problemas con su uso. Este tipo de pruebas se llevan a cabo en un
entrono controlado.
2. Beta. Esta prueba se lleva a cabo, en uno o ms lugares, por los que sern los
usuarios finales del software. A diferencia de la anterior prueba, el encargado del
desarrollo, regularmente, no se encuentra presente. La prueba es una aplicacin
del software en un entorno que no puede ser controlado por el equipo de
desarrollo, para poder darle ms realismo al funcionamiento del software o
sistema. El cliente registra todos los fallos y/o problemas (reales o imaginarios) que
llegue a encontrar y los informa regularmente. Con base en stos, el equipo de
desarrollo lleva a cabo modificaciones y as prepara una versin mejorada del
producto.
Pruebas del Sistema. Las pruebas del sistema implican dos clases de actividades:
pruebas de integracin y pruebas de aceptacin. Las estrategias para integrar los
componentes del software en un producto que funcione incluyen las estrategias
ascendente, descendente y de emparedado. Se requiere de una cuidadosa planeacin y
programacin a tiempo para asegurar que los mdulos estarn disponibles para su
integracin dentro del producto de software en desarrollo, cuando se necesiten. La
estrategia de integracin dicta el orden en que los mdulos deben estar disponibles, por lo

que ejerce gran influencia en el orden en que se escriben, depuran y hacen las pruebas de
unidad de los mdulos.
Las pruebas de aceptacin implican la planeacin y ejecucin de pruebas funcionales, de
desempeo y de tensin para verificar que el sistema realizado satisfaga sus requisitos. Las
pruebas de aceptacin suelen realizarlas las organizaciones de control de calidad, los clientes o
ambos. Dependiendo de las circunstancias, locales, el grupo de desarrollo puede o no estar
relacionado con las pruebas de aceptacin. Algunas son:

Prueba de validacin: Proporciona una seguridad final de que el software

satisface todos los requerimientos funcionales y de rendimiento. Adems, valida
los requerimientos establecidos comparndolos con el sistema que ha sido
construido. Durante la validacin se usan exclusivamente tcnicas de prueba de
caja negra.
Prueba de recuperacin: Fuerza un fallo del software y verifica que la
recuperacin se lleva a cabo apropiadamente.
Prueba de seguridad: Verificar los mecanismos de proteccin y es una
herramienta tcnica al anlisis de riesgos que proporciona una clara visin
referente al nivel de vulnerabilidad y exposicin de la plataforma tecnolgica.
Prueba de resistencia: Enfrenta a los programas a situaciones anormales.
Prueba de rendimiento: Prueba el rendimiento del software en tiempo de
ejecucin.
Prueba de instalacin: Se centra en asegurar que el sistema software
desarrollado se puede instalar en diferentes configuraciones hardware y software y
bajo condiciones excepciones, por ejemplo con espacio de disco insuficiente o
continuas interrupciones.

Pruebas de los programas

Una vez que se ha concluido la codificacin de los programas, es momento de probarlos. La
etapa de prueba no es la primera instancia en la cual se encuentran defectos; ya que durante
la revisin de los requerimientos y del diseo tambin se pueden descubrir problemas en las
etapas tempranas del desarrollo. Pero la prueba se concentra en la bsqueda de defectos y
hay diversas formas de hacer que los esfuerzos de la prueba sean ms eficientes y efectivos.

Defectos y Fallas del Software

En una situacin ideal, cada programa que produce un programador trabajara de manera
correcta cada vez que se pone en ejecucin, lamentablemente este ideal no es la realidad. La
diferencia entre el ideal y la situacin real es el resultado de una variedad de factores. En
primer lugar, podemos encontrar que la mayora de los sistemas de software operan con
grandes cantidades de estados y con frmulas, actividades y algoritmos complejos. Adems
que se utilizan las herramientas disponibles para implementar una concepcin del cliente para
un sistema, cuando el cliente a veces no est seguro de lo que realmente necesita. Y como
ltimo factor esta el tamao de un proyecto y el nmero de personas involucradas, lo cual
agrega complejidad. Por tanto la presencia de defectos no slo en una funcin del software
sino tambin en las expectativas de clientes y usuarios.

Qu significa que el software ha fallado?

En general se interpreta que el software no hace lo que especifican los requerimientos. Por

ejemplo la especificacin puede establecer que el sistema debe responder a una consulta
particular unicamente a los usuarios que estn autorizados a ver los datos. Si el programa
responde a un asurio que no autorizado, significa que el sistema ha fallado. La falla puede ser
el resultado de alguna o varias de las siguientes razones:

La especificacin puede ser rronea o puede haberse omitido algn

requerimiento. Es decir que no enuncie exactamente lo que el cliente necesita o
desea.
La especificacin puede contener un requerimiento que es imposible de
implementar con el hardware y el software que se tiene.
El diseo del sistema puede contener uno varios defectos.
Que el diseo del programa no sea el adecuado.
El cdigo del programa puede estar errado.
Por lo tanto una falla es el resultado de uno o ms defectos en algn aspecto del sistema. Y
en el caso de los programas, a partir de la cantidad que se tenga de posibles defectos, se
deben de verificar los componentes para asegurar que estn correctamente codificados.
El objetivo de probar un programa, es demostrar la existencia de un defecto. La prueba es
destructiva, ya que la meta es descubrir defectos, una prueba se considera exitosa solamente
cuando se descubre un defecto o cuando se produce una falla como resultado de los
procedimientos de prueba.
La identificacin de defectos es el proceso de determinar cul o cules son los defectos que
originan las fallas, y la correcin de defectos o remocin es el proceso de efectuar cambios
al sistema de manera que se eliminen los defectos. En el momento de llevar a cabo la
codificacin y la prueba de componentes se tiene la gran esperanza de que las
especificaciones sean correctas. Y esto se puede lograr si se pusieron en prctica las tcnicas
de la Ingeniera de Software, para as asegurar que el diseo, tanto del sistema como de sus
componentes, refleja los requermientos y conforma una base para una slida implementacin.
Es totalmente posible que un defecto en el software sea el resultado de un descuido durante
la etapa o actividad de desarrollo muy temprana.

Tipos de defectos
Despus de codificar los componentes del programa, por lo general se procede a examinar el
cdigo para detectar los defectos y elimimarlos lo ms pronto posible. Cuando estos defectos
no son obvios , se prueban los programas para ver si pueden contener ms defectos, creando
condiciones especiales donde el cdigo no responda como est planeado. Un defecto
algortmico se produce cuando el algoritmo o la lgica de un componente de programa no
producen la salida apropiada para una entrada dada, debido a que algo est mal en los pasos
del procesamiento. La deteccin de defectos a veces es fcil, como cuando unicamente se lee
el programa (la denominada prueba de escritorio) o al enviar datos de la entrada de cada una
de las diferentes clases de datos que se espera el programa reciba durante su operacin
normal. Los defectos ms comunes son:

Bifurcar antes o despus de tiempo.

Probar para una condicin errona.
Olvidar inicializar una variable o fijar las constantes de un bucle.
Comparar variables de tipos de datos inapropiados.

Olvidar la prueba para una condicin particular (Por ejemplo considerar una
divisin entre cero).
Mientras que se hace la bsqueda de defectos algortmicos se puede hacer tambin la
revisin de la sintaxis. Los defectos de computacin y los de precisin ocurren cuando la
implementacin de una frmula es errnea o no calcula el resultado con el grado requerido de
exactitud. Cuando la documentacin no concuerda con lo que el programa realmente hace, se
dice que el programa tiene defectos de documentacin.
Los defectos por estrs o sobrecarga se producen cuando las estructuras del programa se
llenan hasta sobrepasar su capacidad especfica. De manera simillar, existen los defectos de
capacidad o de lmites que ocurren cuando el desempeo del sistema se vuelve inaceptable
a medida que la actividad del sistema alcanza su lmite especficado.
Otro tipo de defectos son lo de sincronizacin o de coordinacin, los cuales se producen
cuando el cdigo que coordina dichos eventos es inadecuado. Los defectos de rendimiento
o de desempeo ocurren cuando el sistema no opera a la velocidad prescrita por los
requerimientos. Estos son los problemas de tiempo de diversa naturaleza; las restricciones de
tiempo estn puestas sobre le rendimiento del sistema, debido a los requerimientos del cliente
ms que por una necesidad de coordinacin.
Es en las etapas de diseo y codificacin donde se pone gran cuidado para asegurar que el
sistema pueda recuperarse ante una variedad de fallas. Los defectos de recuperacin
pueden presentarse cuando se encuentra una falla y el sistema no se comporta comolo
diseadores desean que lo haga o como requiere el cliente.
Tambin pueden producirse defectos del hardware y del software de sistemas, cuando el
hardware suministrado y el software de sistemas no trabaja de acuerdo con las condiciones
operativas y procedimientos documentados.
Los defectos de estndares y procedimientos no siempre afectan la corrida de los
programas pero pueden fomentar un ambiente donde los defectos se creen a medida que el
sistema es probado y modificado.

Aspectos de la Prueba
Existen muchos tipos de prueba que se hacen antes de poder entrgerale el sistema al cliente
con la seguridad de que operar correctamente. Algunas de ellas dependen de qu es lo que
se est probando: componentes, grupo de componentes, subsistemas o todo el sistema. Otras
pruebas dependen de lo que se desea conocer el sistema trabaja de acuerdo con el
diseo?, y con las expectativas de los usuarios?.
Organizacin de la Prueba
Cuando se desarrolla un sistema grande, la pruba por lo general involucra varios estadios, En
primer lugar, cada componente de programa verifica en s mismo, aislado de los dems
componentes del sistema. Esta prueba conocida como prueba de mdulo, prueba de
componente o prueba unitaria, verifica que el componente funciona correctamente con lo
tipos de entrada esperados a partir del estudio del diseo del componente.
La prueba unitaria se hace siempre que sea posible en un ambiente controlado, de modo que
el equipo de prueba pueda ingresarle al componente que se est probando un conjunto

predeterminado de datos, y observar que acciones y datos de salida se producen.

Una vez que le conjunto de componentes del sistema (o subsistema) ha superado la prueba
unitaria, el paso siguiente es asegurar que las interfaces entre los componentes estn
definidas y se manejan correctamente. La prueba de integracin es el proceso de verificar
que los componentes del sistema trabajan conforme a lo descrito en las especificaciones de
diseo del programa y del sistema.
Despues de asegurar que la informacin pasa entre los componentes de acuerdo eon el
diseo, se prueba el sistema para asegurar que tiene la funcionalidad deseada. Una prueba
funcional evala el sistema para determinar si las funciones descritas por la especificacin de
requerimientos son ejecutadas correctamente por el sistema integrado. El resultado es un
sistema en funcionamiento.
Cabe recordar que lo requerimientos estn documentados de dos formas distintas: una es en
trminos del cliente, y otra como un conjunto de requerimientos de hardware y software que
pueden utilizar los desarrolladores. La prueba funcional compara el sistema en construccin,
con las funciones descritas en la especificacin de requerimientos de los desarrolladores. Ms
adelante una prueba de rendimiento compara el sistema con el resto de los requerimientos
de software y de hardware. Cuando la prueba se lleva a cabo exitosamente en el ambiente
real de trabajo del cliente, produce un sistema validado.
Cuando la prueba de rendimiento se concluye, los desarrolladores tienen la certeza de que el
sistema funciona de acuerdo con su comprensin de la descripcin del sistema. El siguiente
paso es conferenciar con el cliente para tener la certeza de que le sistema trabaja de acuerdo
con sus expectativas. La prueba de aceptacin se hace en conjunto con el cliente; el sistema
se comprueba contra la especificacin de requerimientos del cliente. Al terminar la prueba de
aceptacin el sistema aceptado se instala en el ambiente en el que ser utilizado y se ejecuta
una ltima prueba de instalacin para garantizar que funciona como debe hacerlo.
Actitudes frente al proceso de prueba
Es importante tener en cuenta que cuando se est desarrollando un sistema para clientes, a
stos no les interesa saber que el sistema funciona correctamente bajo ciertas condiciones,
sino que les interesa estar seguros del funcionamiento correcto del sistema bajo todas las
condiciones. De este modo, la meta del desarrollador debe ser la eliminacin de tantos
defectos como sea posible, sin importar dnde se han producido o quin los ha originado. El
sentirse mal o herido el ego no tiene algn lugar en el descubrimiento de defectos en el
proceso de desarrollo. De aqu que muchos ingenieros de software adopten un actitud
conocida como programacin no egosta, donde los programas se consideran como
componentes de un sistema mayor, no una propiedad de aquellos que los han escrito. Cuando
se descubre un defecto o se produce una falla, al equipo de desarrollo no egosta le concierne
corregir el defecto y no reprocharle a un desrrollador en particular.

Quin realiza las pruebas?

Aun cuando el sistema est desarrollado con un enfoque no egosta, muchas veces se
manifiestan dificultades para separar los sentimientos personales del proceso de prueba. Po lo
tanto a menudo se utiliza un equipo de prueba independiente par aprobar el sistema. De esta

forma se evita el conflicto entre la responsabilidad personal por los defectos y la necesidad de
descubrir tantos defectos como sea posible.
Adicionalmente varios factores justofican en equipo independiente de prueba. Un equipo de
prueba inependiente puede participar en la revisin de los componentes a travs del
desarrollo. El euipo puede ser parte de las revisiones de los requerimientos y del diseo, pude
probar los componentes individuales y puede probar el sistema a medida que se integra y se
presenta a los clientes.
Las visiones de los objetos de prueba
Al probar un componente, un grupo de componetes , un subsistema o un sistema, la propia
visin del objeto de prueba; puede afectar la forma en que se lleve a cabo la prueba.
Si el objeto de prueba se ve desdes afuera, como una caja cerrada o una caja negra, cuyo
contenido se desconoce, las pruebas consisten en alimentar la caja negra con entradas y
anotar cules son las salidas que se producen. En este caso el objetivo de la prueba es
asegurar qu e se ha ingresado toda clase de entrada y que la salida en cada caso se
corresponde con la salida esperada.
Esta tipo de pruebas tien ventajas y desventajas, La ventaja ms evidente es que una caja
cerrada est libre de las restricciones impuestas por la estructura interna o la lgica del objeto
de prueba, sin embargo de esta manera no siempre es posible ejecutar una prueba completa.
Pero para superar esto el objeto de prueba puede verse en cambio como una caja abierta o
tambin denominada caja de cristal o caja blanca o transparente; luego, se puede utilizar la
estrucutura del objeto de prueba para probar las diferentes maneras. Por ejemplo, se pueden
inventar casos de prueba que ejecuten todas las instrucciones o todos los caminos que
existen en el interior del componente o de los componentes, para asegurar que el objeto de
prueba est trabajando correctamente; pero en ocasiones resulta poco prctico adoptar este
tipo de enfoque.
En general la seleccin de una filosofa depende de muchos factores como son :

el nmero de caminos lgicos posibles

la naturaleza de los datos de entrada
la cantidad de cmputo involucrado
la complejidad de los algoritmos

Planificacin de la Prueba
Un cuidadoso plan de prueba ayuda a disear y organizar las pruebas con el fin de asegurar
que se pruebe en forma apropiada y directa. Cada paso del proceso de prueba debe ser
planeado. De hecho el proceso de prueba tiene su propio ciclo de vida dentro del ciclo de
desarrollo, y se puede llevar a cabo en paralelo con muchas de losa otras actividades del
desarrollo. Se deben de planear en particular, los siguientes casos de prueba:
1.
2.
3.

Determinacin de los objetivos.

Diseo de los casos de prueba.
Preparacin escrita de los casos de prueba.

4.
5.
6.

Verificacin de los casos de prueba.

Ejecucin de las pruebas.
Evaluacin de los resultados.

El objetivo de la prueba indica qu clases de casos de prueba se deben

generar. Es ms, el diseo de caso de prueba es clave para la prueba
exitosa. Por consiguiente, la ejecucin de una prueba comienza con la
revisin de los casos de prueba para verificar que son correctos,
factibles, que proporcionan el grado de cobertura deseado y demuestran
la funcionalidad deseada. Una vez realizados estos controles se pueden
efectuar las pruebas.

LAWRENCE Pfleeger, Ingeniera de Software Teora y Prctica, 1a. ed, Brasil 2002, Prentice
Hall.

http://clases3gingsof.wikifoundry.com/page/Pruebas+de+los+programas