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
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
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:
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:
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:
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:
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
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 :
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.
4.
5.
6.
LAWRENCE Pfleeger, Ingeniera de Software Teora y Prctica, 1a. ed, Brasil 2002, Prentice
Hall.
http://clases3gingsof.wikifoundry.com/page/Pruebas+de+los+programas