PRUEBAS

La realizacin de pruebas sistemticas y en profundidad es la nica receta que

permite minimizar los riesgos de un software que controla directamente
procesos peligrosos o complejos en los que un error pueda ocasionar graves
daos o consecuencias. Aun as, los defectos que pasan desapercibidos
durante el desarrollo de un sistema no tan riesgoso como un sistema de
software no tan crticos, implican riesgos de imagen, de responsabilidad legal,
entre otros.
Un riguroso proceso de prueba permite minimizar riesgos y obtener un
producto de software de mayor calidad.
Objetivos:
-

Reconocer y diferenciar los conceptos fundamentales con las pruebas de

software.
Comprender la necesidad de las pruebas como parte esencial del
desarrollo de un sistema de software.
Conocer las actividades que componen los procesos de prueba:
planificacin y evaluacin de resultados.

Introduccin.
La importancia de las pruebas en un proceso de desarrollo es que gracias a ello
podemos alcanzar a determinar parmetros de calidad.
Las pruebas de software son en realidad un elemento diferente a las dems
actividades durante el desarrollo. Su xito radica en la deteccin de errores
tanto en proceso de desarrollo como en el software ya obtenido. Defiendo de
tal manera concluimos que una prueba de software es todo proceso
orientado a comprobar la calidad del software mediante la identificacin de
fallos en el mismo. La prueba necesariamente la ejecucin de software.
Para tener xito en las pruebas se debe contar con una buena actitud de
colaboracin del equipo de desarrollo hacia las actividades de pruebas como
garanta de que el software est siendo producido correctamente. Lo que
implica descubrir fallos, solucionarlos y evitar hacer sentir culpable a algn
miembro del equipo.
Al realizar las pruebas es importante recordar que los usuarios finales
potencialmente ejecutaran todas las funcionalidades del sistema por lo que lo
errores que no sean detectados en las pruebas realizadas aparecern cuando
los usuarios finales prueben el software lo que a su vez afectara la imagen y
reputacin del equipo de desarrollo adems de traer implicaciones legales
debido al mal funcionamiento del software. Uno de los objetivos que debe
lograrse es que el porcentaje de fallos detectados por el usuario final sea el
menor.
Los procesos de software actuales recomiendan disear pruebas de aceptacin
al mismo tiempo que se realizan la especificacin de requisitos. Este enfoque

produce unas especificaciones mucho ms detalladas por la obligacin de

determinar de antemano la manera exacta en que las especificaciones sern
probadas.
Resulta por lo tanto esencial el diseo de un plan de pruebas y la integracin
de las mismas en el proceso de desarrollo, utilizando un enfoque sistemtico y
dinmico. Sistemtico porque la complejidad del software actual fuerza la
planificacin minuciosa de las pruebas y dinmico porque obligatoriamente se
ejecuta el software con entrada de datos preparadas denominadas casos de
pruebas. Estos casos de pruebas son un conjunto de entradas, condiciones y
resultados esperados, que han sido desarrollados para un objetivo particular
como, por ejemplo, ejercitar un camino concreto de un programa o verificar el
cumplimiento de un determinado requisito.
Cubrir todas las posibles causas de fallo se denomina prueba completa o
prueba exhaustiva, es decir, una prueba ideal que proporciona la seguridad de
que han sido comprobado todas y cada una de las posibilidades de fallo.
Conceptos Fundamentales.
Los conceptos fundamentales de esta temtica son: fallo, defecto y error.

Fallo, es un efecto indeseado observado en las funciones o prestaciones

desempeadas por un software.
Error (Defecto), es una imperfeccin en el software que provoca un
funcionamiento incorrecto del mismo.
Adems de estos conceptos existen otros que debemos tener claros y
presentes como lo son:

Probar un software es el proceso de mostrar la presencia de un error en

el mismo.
Depurar un software consiste en descubrir en qu lugar exacto se
encuentra un error y modificar el software para eliminar dicho error.
Orculo, es cualquier agente capaz de decidir si un programa se
comporta correctamente durante una prueba y, por tanto, capaz de
dictaminar si la prueba se ha superado o no.
Trazabilidad, es la capacidad para interrelacionar dos o ms entidades,
inequvocamente identificables, dentro de una cadena de sucesos
cronolgicamente ordenada.
Limitaciones en la realizacin de pruebas
Pruebas la realizacin de pruebas es un proceso importante que resulta crtico
para el xito de un proyecto de desarrollo. Entre los ms importantes podemos
citar los siguientes;
Imposibilidad de hacer pruebas exhaustivas. No es posible
asegurar al 100% con software est libre de errores. Solo una prueba
exhaustiva permitira corroborar que no hay errores.

 Limitaciones derivadas de la naturaleza de las pruebas. Existen

serias limitaciones a la hora de hacer pruebas derivadas de la propia
naturaleza de las pruebas.
Seleccin de los casos de prueba. Un problema importante es decidir
cules son los casos de prueba ms adecuados en cada situacin existen
ciertos crticos de seleccin de pruebas que pueden utilizarse para
seleccionar casos de pruebas o para decidir si pueden darse por buenas
las pruebas realizadas y por tanto se pueden terminar de hacer pruebas.
Seleccin de los equipos de prueba. Las pruebas deberan ser
llevadas a cabo en el caso ideal por personas independientes
completamente imparciales con respecto al software aprobada es decir
personas que no hubieran participado en la realizacin directa del
software si el grupo de casos de pruebas es apropiado para aquello que
se desea probar es una tarea complicada que requiere mucha
experiencia.
Finalizacin de las pruebas. La capacidad para decidir si se puede
terminar de hacer pruebas o no es algo difcil y para lo cual se requiere
experiencia pues en buena medida condiciona la planificacin de las
pruebas.

Las pruebas y el riesgo

La importancia de las pruebas es directamente proporcional los
catastrficos efectos que un software errneo podra provocar. Si bien nunca
debe olvidarse la imposibilidad de producir software completamente libre de
errores, un riguroso y exhaustivo proceso de prueba permite minimizar el
riesgo.
Los principales riesgos a que se enfrenta una organizacin al distribuir
software insuficientemente probado son:
Deterioro de su imagen punto. Es un problema que puede
producir importantes prdidas econmicas y si bien su impacto es
difcilmente medible pueden daar a una compaa ms de lo que
pueden hacerlo otras causas. Es decir, se deteriora la imagen de la
compaa con comentarios desfavorables de parte de sus
consumidores o clientes.
Prdidas econmicas.
Consecuencias legales. En aquellos casos en que la consecuencia
de un mal funcionamiento del Software pueda suponer riesgos graves
para la vida de personas para la seguridad nacional cuantiosas
prdidas materiales las consecuencias legales pueden conllevar
incluso responsabilidades penales.
Tcnicas de prueba

Su objetivo es descubrir el mximo nmero de fallos en el software. Las

pruebas aaden as valor al producto pues parten de un programa con errores
seala cules son y permite subsanarlos.
El objeto primordial de las tcnicas que se realizan son la de sistematizar el
proceso de prueba. Tradicionalmente las tcnicas de pruebas se han clasificado
nicamente en dos categoras: pruebas de caja blanca y pruebas de caja
negra.
Pruebas de caja blanca: Son aquellas que estn basadas en informacin
acerca de cmo se ha diseado o programado el software.
Las principales ventajas de las tcnicas de caja blanca son:
Eficiencia al tratar pruebas automatizadas ya que es posible definir
pruebas unitarias que aslen parte del cdigo y probarlas
independientemente acelerando as el procesamiento de las colecciones
de prueba.
Mayor facilidad a la hora de depurar los programas en bsqueda de
errores.
Fundamentales en el denominado desarrollo guiado por pruebas el cual
depende en gran medida del conocimiento que se tiene de la
implementacin.

Desventajas:
Resulta difcil utilizar pruebas de caja blanca para validar requisitos pues
Esta tcnica se centra en cmo est hecho el software.
No resultan adecuadas para comprobar la robustez del Software ante
comportamientos imprevistos como por ejemplo entradas no esperadas
por parte de los usuarios.
Los encargados de las pruebas deben tener un nivel de formacin y
experiencia ms elevado que sus homlogos de las pruebas de caja
negra.
Pruebas de caja negra: Son los casos de prueba que se basan solamente en
el comportamiento de la entrada y salida de datos.
Existe otro consejo denominado caja gris existe otro concepto denominado caja
gris. Se trata de un tipo especial de pruebas de caja negra en las que resulta
imprescindible conocer parte del cdigo para poder realizar las pruebas. La
idea En qu se basan es que si la persona que realiza las pruebas tiene cierto
conocimiento sobre el funcionamiento interno del mdulo que se prueba podr
probar lo mejor desde el exterior. A diferencia de las pruebas de caja blanca, en
las cajas gris no se intenta alcanzar un alto nivel de cobertura para probar
todos los caminos posibles.

Clasificacin exhaustiva de las tcnicas de prueba.

Tcnicas basadas en la intuicin y experiencia:
Se basan en la habilidad e intuicin de los ingenieros del software y en su
conocimiento de situaciones similares. Entre ellas tenemos las pruebas ad hoc
las pruebas por exploracin.
- Pruebas ad hoc son pruebas a la medida de la aplicacin o del mdulo a
probar y pueden resultar tiles cuando se desean identificar casos de prueba
que no se pueden extraer fcilmente mediante pruebas sistemticas.
- Las pruebas por exploracin no forman parte de un plan de pruebas
preestablecido. Se disean Ejecutan y modifican dinmicamente a partir de la
experiencia del ingeniero de software.

Tcnicas basadas en la especificacin.

Son varias y agrupa un gran nmero de tcnicas:
- La tcnica de particiones de equivalencia consiste en dividir el dominio de los
platos de entrada clases de equivalencia de acuerdo con una determinada
relacin entre sus elementos.
- En el anlisis de valores lmites los casos de prueba se seleccionan cerca de
los lmites del dominio de las variables de la entrada de datos ya que
habitualmente la mayora de los errores se concentran cerca de los valores
extremos.
- Las pruebas de robustez pueden considerarse una variante de Esta tcnica en
que se seleccionan casos de prueba fuera del dominio de los datos entradas
con el objetivo de comprobar la robustez del programa ante entrada de datos
errneos o inesperadas.