Anda di halaman 1dari 13

Desarrollo de Software

Introduccin al desarrollo de software


Evidencia de aprendizaje
Tipos de pruebas y el proceso de
mantenimiento

Instrucciones:
1. De manera individual, analiza el caso de estudio dado por tu facilitador y describe los tipos de prueba que
estn utilizando. Justifica cada respuesta.
2. Adems analiza el proceso de mantenimiento que se sugiere en el caso de estudio y describe a que tipo
pertenece. Justifica tu respuesta.

CASO DE ESTUDIO
Formamos parte de una empresa de desarrollo de software y somos parte del equipo responsable de generar las
pruebas a todos los productos que nuestra empresa genere. La semana pasada fue una de las ms complicadas debido
a que el trabajo de varios proyectos se nos junt, no estaba planeado que esto ocurriera, pero las circunstancias que se
explican en cada caso nos obligaron a cumplir profesionalmente nuestra labor. A continuacin se explican uno de los
casos de los proyectos que atendimos.
El cliente de este proyecto, ha pedido que se le adelante la demostracin del cdigo, ya que estar ausente por un viaje
no previsto de 15 das. El equipo de desarrollo ha invertido ms horas para lograr codificar la iteracin planeada, algunas
pruebas los programadores las aplicaron y en otras se nos ha pedido que les apoyemos, para de esta manera entregar la
aplicacin lo ms confiable posible. Estas son todas las pruebas que se lograron realizar entre el equipo de desarrollo y
el equipo de pruebas.
1. Se probaron todos los componentes de los programas: clases, mtodos, objetos, atributos. Esto fue realizado por
cada programador que adems correga el cdigo inmediatamente.
2. Se prob que cada interfaz funcionara de acuerdo a los requerimientos del cliente, mismos que se cotejaron para
poder establecer los casos de prueba vlidos. Se registraron los errores que ocurrieron fueron de este tipo:
Algunas interfaces no funcionaron adecuadamente.
Inconsistencias en la presentacin de datos con respecto a las opciones del men.
3. Se prob el mdulo que sera entregado en esta interaccin para que se integrara correctamente a la estructura del
sistema y se probaron los mdulos, liberados anteriormente, para verificar que la insercin del nuevo no causara conflicto
a los existentes.
4. Por ltimo, el da de la presentacin, un representante del equipo de pruebas y el analista entregaron el avance al
cliente, quien se hizo acompaar de uno de los usuarios del sistema. Ambos evaluaron el nuevo mdulo en una

computadora, que se prepar previamente para tal fin por el equipo de pruebas. El resultado de esta revisin fueron
nicamente 3 defectos de interfaz, los cuales fueron oportunamente solucionados.
5. La ltima prueba se realiz en la empresa del cliente, en esta ocasin fueron los principales usuarios quienes probaron
el software. Ya no se encontraron ms defectos, lo cual nos permiti liberar el mdulo.
6. Despus de haber liberado este mdulo se concluy con el sistema. La empresa ha sido contratada, por este ao,
para dar mantenimiento al software; pues est proyectado que en este periodo, se renovarn las licencias del sistema
operativo y del manejador de base de datos y posiblemente se tengan que hacer ajustes al software liberado.

Punto nmero 1
los programadores que intervinieron en el caso, se apoyaron en:
Pruebas de unidad: para probar programas o clases. Sirven para comprobar la funcionalidad de objetos o
mtodos.
o
o

Pruebas del componente: se prueban las interfaces de los componentes.


Pruebas del sistema: se prueba la integracin de todos los componentes.

Adems:
Pruebas de unidad: se encarga de probar componentes del programa, como mtodos o clases de objetos. Se
tienen que disear pruebas para revisar todas las operaciones asociadas, establecer y verificar el valor de
todos los atributos y poner el objeto en todos los estados posibles.
Tambin cada programador deber tener en cuenta:
Objetivo de la Prueba:
Se focaliza en ejecutar cada mdulo (o unidad mnima a ser probada, ej. = una clase) lo que provee un mejor modo
de manejar la integracin de las unidades en componentes mayores.
Busca asegurar que el cdigo funciona de acuerdo con las especificaciones y que el mdulo lgico es vlido.
Descripcin de la Prueba:

Particionar los mdulos en pruebas en unidades lgicas fciles de probar.


Por cada unidad hay que definir los casos de prueba (pruebas de caja blanca).
Para esto los casos de prueba deben disearse de forma tal que se recorran todos los caminos de ejecucin
posibles dentro del cdigo bajo prueba; por lo tanto el diseador debe construirlos con acceso al cdigo
fuente de la unidad a probar.
Los aspectos a considerar son los siguientes: Rutinas de excepcin, Rutinas de error, Manejo de parmetros,
Validaciones, Valores vlidos, Valores lmites, Rangos, Mensajes posibles.

Tcnica:

Comparar el resultado esperado con el resultado obtenido.


Si existen errores, reportarlos y desde luego corregirlos.

Criterio de Completitud:

Todas las pruebas planeadas han sido ejecutadas.


Todos los defectos que se identificaron han sido tenidos en cuenta.

Consideraciones Especiales:
Para la elaboracin de pruebas unitarias en java se puede utilizar el JUNIT y CACTUS.

Punto nmero 2
los programadores que intervinieron en el caso, se apoyaron en:
Pruebas de componentes: se enfoca en demostrar que la interfaz de componente se comporte segn la
especificacin. Existen diferentes tipos de interfaz entre componentes de programa y, en consecuencia, distintos
tipos de error de interfaz. Por ejemplo:

Uso incorrecto de la interfaz.


Mala interpretacin de la interfaz.

Errores de temporizacin.

Para tal efecto, cada programador deber tener en cuenta:


Objetivo de la Prueba:

Identificar errores introducidos por la combinacin de programas probados unitariamente.

Determina cmo la base de datos de prueba ser cargada.

Verificar que las interfaces entre las entidades externas (usuarios) y las aplicaciones funcionan
correctamente.

Verificar que las especificaciones de diseo sean alcanzadas.

Determina el enfoque para avanzar desde un nivel de integracin de las componentes al siguiente.

Descripcin de la Prueba:

Describe cmo verificar que las interfaces entre las componentes de software funcionan correctamente.

Determina cmo la base de datos de prueba ser cargada.

Determina el enfoque para avanzar desde un nivel de integracin de las componentes al siguiente.

Decide qu acciones tomar cuando se descubren problemas.

Por cada Caso de Prueba ejecutado:


Comparar el resultado esperado con el resultado obtenido.
Tcnica:

Utilizar la tcnica top-down. Se empieza con los mdulos de nivel superior, y se verifica que los mdulos de nivel
superior llaman a los de nivel inferior de manera correcta, con los parmetros correctos.
Utilizar la tcnica down-top. Se empieza con los mdulos de nivel inferior, y se verifica que los mdulos de nivel
inferior llaman a los de nivel superior de manera correcta, con los parmetros correctos.

Criterio de Completitud:

Todas las pruebas planeadas han sido ejecutadas.


Todos los defectos que se identificaron han sido tenidos en cuenta.

Consideraciones Especiales:
Ninguna

Punto nmero 3

los programadores que intervinieron en el caso, se apoyaron en:

Pruebas de rendimiento: Se aplican cuando el sistema ha sido integrado completamente, con ellas es posible
probar el rendimiento y confiabilidad. Generalmente consisten en aumentar la carga hasta que el sistema se
vuelve inaceptable. Una manera de descubrir defectos es disear pruebas sobre los lmites del sistema. En las
pruebas de rendimiento, significa estresar el sistema al hacer demandas que estn fuera de los lmites del diseo
del software. Esto se conoce como prueba de esfuerzo.
Para tal efecto, cada programador deber tener en cuenta:
Objetivo de la Prueba:
Verificar que el sistema funciona apropiadamente y sin errores, bajo estas condiciones de stress:

Memoria baja o no disponible en el servidor.


Mximo nmero de clientes conectados o simulados (actuales o fsicamente posibles)
Mltiples usuarios desempeando la misma transaccin con los mismos datos.
El peor caso de volumen de transacciones (ver pruebas de desempeo).

NOTAS: La meta de las pruebas de stress tambin es identificar y documentar las condiciones bajo las cuales el sistema
FALLA.
Descripcin de la Prueba:
Las pruebas de stress se proponen encontrar errores debidos a recursos bajos o completitud de recursos. Poca memoria
o espacio en disco puede revelar defectos en el sistema que no son aparentes bajo condiciones normales. Otros
defectos pueden resultar de incluir recursos compartidos, como bloqueos de base de datos o ancho de banda de la red.
Las pruebas de stress identifican la carga mxima que el sistema puede manejar.
El objetivo de esta prueba es investigar el comportamiento del sistema bajo condiciones que sobrecargan sus recursos.
No debe confundirse con las pruebas de volumen: un esfuerzo grande es un pico de volumen de datos que se presenta
en un corto perodo de tiempo.
Puesto que la prueba de esfuerzo involucra un elemento de tiempo, no resulta aplicable a muchos programas, por
ejemplo a un compilador o a una rutina de pagos.
Es aplicable, sin embargo, a programas que trabajan bajo cargas variables, interactivos, de tiempo real y de control de
proceso.

Aunque muchas pruebas de esfuerzo representan condiciones que el programa encontrar realmente durante su
utilizacin, muchas otras sern en verdad situaciones que nunca ocurrirn en la realidad. Esto no implica, sin embargo,
que estas pruebas no sean tiles.
Si se detectan errores durante estas condiciones imposibles, la prueba es valiosa porque es de esperar que los mismos
errores puedan presentarse en situaciones reales, algo menos exigentes.
Tcnica:

Usar los scripts utilizados en las pruebas de desempeo.


Para probar recursos limitados, las pruebas se deben correr en un servidor con configuracin reducida (o
limitada).
Para las pruebas de stress restantes, deben utilizarse mltiples clientes, ya sea corriendo los mismos scripts o
scripts complementarios para producir el peor caso de volumen de transacciones.

Criterio de Completitud:
Todas las pruebas planeadas han sido ejecutadas y excedidas sin que el sistema falle. ( O si las condiciones en que el
sistema falle ocurren por fuera de las condiciones especificadas).
Consideraciones Especiales:

Producir stress en la red puede requerir herramientas de red para sobrecargarla de trfico.
El espacio en disco utilizado para el sistema debe ser reducido temporalmente para limitar el espacio disponible
para el crecimiento de la Base de datos.
Sincronizacin de varios clientes accediendo simultneamente los mismos registros.

Puntos nmero 4 y 5,
los programadores que intervinieron en el caso, se apoyaron en:
Pruebas de usuario: Este tipo de pruebas son necesarias por la influencia del entorno de trabajo que tiene gran
efecto sobre la fiabilidad, el rendimiento, el uso y la robustez de un sistema. En la prctica existen tres tipos de
pruebas de usuario:

Pruebas alfa: las realiza el usuario en presencia de personal de desarrollo del proyecto haciendo uso de una
mquina preparada para tal fin.
Pruebas beta: las realiza el usuario despus de que el equipo de desarrollo les entregue una versin casi
definitiva del producto.
Pruebas de aceptacin: son las nicas pruebas que son realizadas por los usuarios, deciden si est o no listo
para ser aceptado.

Para tales efectos, cada programador deber tener en cuenta:


Pruebas Alfa
Objetivo de la Prueba:
Prueba de aceptacin para detectar errores en el sistema bajo un ambiente controlado.

Descripcin de la Prueba:
La verificacin involucra la ejecucin de partes o todo del sistema en ambientes simulados, con el fin de encontrar
errores.
La retroalimentacin de esta fase produce cambios en el software para resolver los errores y fallas que se descubren.
Tcnica:
Realizar las pruebas de sistema bajo las siguientes caractersticas:

Se llevan a cabo en el lugar en donde fue desarrollado el SW,


En un ambiente controlado, en el cual el desarrollador est presente.

Se selecciona un grupo de usuarios para el alpha test y se les pide trabajen con el sistema como parte de las pruebas.
Criterio de Completitud:

Todas las pruebas planeadas han sido ejecutadas.


Todos los defectos que se identificaron han sido tenidos en cuenta.

Consideraciones Especiales:
Ninguna

Pruebas Beta
Objetivo de la Prueba:
Realizar la validacin del sistema por parte del usuario.
Descripcin de la Prueba:
Prueba de aceptacin donde La validacin (o pruebas beta) involucra el uso del software en un ambiente real.
Tcnica:

Se selecciona un grupo de usuarios que ponen a trabajar el sistema en un ambiente real. Usan el sistema en sus
actividades cotidianas, procesan transacciones y producen salidas normales del sistema.

Las transacciones y personas que usan el sistema son reales y trabajan en su rea de trabajo real.

El desarrollador no est presente.

Los usuarios estn advertidos de que estn usando un sistema que puede fallar.

Los usuarios realizan pruebas a su antojo realizando uso de la aplicacin.

Criterio de Completitud:

Se establece un periodo de pruebas beta en el que los errores detectados no sean de carcter crtico para el sistema.
Consideraciones Especiales:
Se deben considerar mecanismos de comunicacin entre los desarrolladores y los usuarios de manera que los errores
detectados puedan ser corregidos.
Prueba de Aceptacin
Objetivo de la Prueba:
Determinacin por parte del cliente de la aceptacin o rechazo del sistema desarrollado.
Descripcin de la Prueba:
La prueba de aceptacin es ejecutada antes de que la aplicacin sea instalada dentro de un ambiente de produccin. La
prueba de aceptacin es generalmente desarrollada y ejecutada por el cliente o un especialista de la aplicacin y es
conducida a determinar como el sistema satisface sus criterios de aceptacin validando los requisitos que han sido
levantados para el desarrollo, incluyendo a documentacin y procesos de negocio.
Basado en esta prueba el cliente determina si acepta o rechaza el sistema
Estas pruebas estn destinadas a probar que el producto est listo para el uso operativo. Suelen ser un subconjunto de
las Pruebas de Sistema.
Sirve para que el usuario pueda validar si el producto final se ajusta a los requisitos fijados, es decir, si el producto est
listo para ser implantado para el uso operativo en el entorno del usuario.
Esta prueba es complementada por la prueba de estilo.
Tcnica:
Realizacin de los documentos de planes de prueba de aceptacin y especificacin de los mismos, basados en los
criterios de aceptacin del cliente.
Los casos prueba de aceptacin han de ser planificados, organizados y formalizados de manera que se determine el
cumplimiento de los requisitos del sistema. Para la realizacin de estas pruebas se necesita disponer de los siguientes
documentos:

Especificacin de requisitos del sistema.


Manual de usuario.
Manual de administrador.

Realizar Pruebas de estilo

Criterio de Completitud:

Todas las pruebas planeadas han sido ejecutadas.

Todos los defectos que se identificaron han sido tenidos en cuenta.

Consideraciones Especiales:
Las Pruebas de Aceptacin se suelen realizar en un entorno de pre-produccin.
Adems de estas pruebas siempre se realizan por el equipo de trabajo de la empresa en desarrollo de SW, otra
serie de pruebas, que a consideracin de los involucrados (Cliente y programador), el tiempo de desarrollo para
el SW; pueden llevarse a cabo para una TOTAL satisfaccin de los involucrados (Cliente y programador), estas
son:

Pruebas de Sistema: Las pruebas del sistema deben enfocarse en requisitos que puedan ser tomados
directamente de casos de uso y reglas y funciones de negocios. El objetivo de estas pruebas es verificar el
ingreso, procesamiento y recuperacin apropiado de datos, y la implementacin apropiada de las reglas de
negocios. Este tipo de pruebas se basan en tcnicas de caja negra, esto es, verificar el sistema (y sus procesos
internos), la interaccin con las aplicaciones que lo usan va GUI y analizar las salidas o resultados.
Prueba de integracin:
o

Describe cmo verificar que las interfaces entre las componentes de software funcionan correctamente.

Determina cmo la base de datos de prueba ser cargada.

Determina el enfoque para avanzar desde un nivel de integracin de las componentes al siguiente.

Decide qu acciones tomar cuando se descubren problemas.

Por cada Caso de Prueba ejecutado:


o

Comparar el resultado esperado con el resultado obtenido.

Prueba de regresin: En esta prueba se vuelve a probar el sistema a la luz de los cambios realizados durante el
debugging, mantenimiento o desarrollo de la nueva versin del sistema buscando efectos adversos en otras
partes.

Pruebas de Humo (Smoke Testing o Ad Hoc): Toma ste nombre debido a que su objetivo es probar el sistema
constantemente buscando que saque humo o falle. En algunos proyectos este tipo de prueba va junto con las
pruebas funcionales. Permite detectar problemas que por lo regular no son detectados en las pruebas normales.
Algunas veces, si las Pruebas ocurren tarde en el ciclo de desarrollo est ser una forma de garantizar el buen
desarrollo.
Las pruebas de humo NO SON exhaustivas, pero van de extremo a extremo de la aplicacin.

Pruebas de Desempeo: Las pruebas de desempeo miden tiempos de respuesta, ndices de procesamiento
de transacciones y otros requisitos sensibles al tiempo. El objetivo de las pruebas de desempeo es verificar y
validar los requisitos de desempeo que se han especificado (en este caso, el desempeo ofrecido por el
proponente). Las pruebas de desempeo usualmente se ejecutan varias veces, utilizando en cada una, carga
diferente en el sistema. La prueba inicial debe ser ejecutada con una carga similar a la esperada en el sistema.
Una segunda prueba debe hacerse utilizando una carga mxima. Adicionalmente, las pruebas de desempeo
pueden ser utilizadas para perfilar y refinar el desempeo del sistema como una funcin de condiciones tales
como carga o configuraciones de hardware.

Las principales actividades son:


o

Comparar el desempeo del sistema actual con los requisitos,

Poner a punto el sistema para mejorar las mtricas de desempeo y proyectar la capacidad futura de carga
del sistema.

Los objetivos de nivel de servicio definidos deben guiar la prueba de performance. Algunas caractersticas que
afectan el desempeo son:
o

Errores lgicos

Procesamiento ineficiente

Diseo pobre: muchas interfaces, instrucciones y entradas/salidas.

Cuellos de botella en discos, CPU o canales de entrada/salida

Salidas del sistema

Tiempos de respuesta

Capacidad de almacenamiento

Tasa de entrada/salida de datos

Nmero de transacciones que pueden ser manejadas simultneamente.

Las pruebas de desempeo utilizan las tcnicas de caja blanca y caja negra.

Pruebas de Carga: Las pruebas de carga miden la capacidad del sistema para continuar funcionando
apropiadamente bajo diferentes condiciones de carga. La meta de las pruebas de carga es determinar y asegurar
que el sistema funciona apropiadamente an ms all de la carga de trabajo mxima esperada. Adicionalmente,
las pruebas de carga evalan las caractersticas de desempeo (tiempos de respuesta, tasas de transacciones y
otros aspectos sensibles al tiempo).
Pruebas de Volumen: Las pruebas de volumen hacen referencia a grandes cantidades de datos para determinar
los lmites en que se causa que el Sistema falle. Tambin identifican la carga mxima o volumen que el sistema
puede manejar en un perodo dado. Por ejemplo, si el sistema est procesando un conjunto de registros de Base
de datos para generar un reporte, una prueba de volumen podra usar una Base de datos de prueba grande y
verificar que el sistema se comporta normalmente y produce el reporte correctamente. El objetivo de esta prueba
es someter al sistema a grandes volmenes de datos para determinar si el mismo puede manejar el volumen de
datos especificado en sus requisitos.
Algunos ejemplos de escenarios de prueba de volmenes:

Un compilador puede ser alimentado por un programa para compilar que sea absurdamente grande.

Un editor de nexos puede recibir un programa que contenga miles de mdulos.

Un simulador de circuito electrnico puede recibir un circuito diseado con miles de componentes.

Puesto que obviamente, la prueba de volumen es una prueba costosa, tanto en tiempo de mquina como en
personal, se debe tratar de no exceder los lmites. Sin embargo, todo programa debera ser expuesto, al menos,
a algunas pruebas de volumen
Pruebas de Recuperacin y Tolerancia a fallas: Estas pruebas aseguran que una aplicacin o sistema se
recupere de una variedad de anomalas de hardware, software o red con prdidas de datos o fallas de integridad.

Las pruebas de tolerancia a fallas aseguran que, para aquellos sistemas que deben mantenerse corriendo,
cuando una condicin de falla ocurre, los sistemas alternos o de respaldo pueden tomar control del sistema sin
prdida de datos o transacciones.
Las pruebas de recuperacin son contrarias a las pruebas en que la aplicacin o sistema es expuesto a
condiciones extremas (o condiciones simuladas), tales como fallas en dispositivos en entrada/salida o llaves o
apuntadores invlidos de base de datos. Los procesos de recuperacin se invocan y la aplicacin es monitoreada
y/o inspeccionada para verificar que stos mecanismos se han ejecutado en forma apropiada.

El objetivo de esta prueba es determinar la habilidad del sistema para recuperarse de una falla de hardware o
software. Esta prueba evala las caractersticas de contingencia construidas en el sistema para procesar
interrupciones y para volver a puntos especficos en el ciclo de procesamiento del sistema. La recuperacin debe
ser considerada en el proceso de diseo. Errores de programacin o de datos pueden ser incorporados ex
profeso en un sistema para determinar si se puede recuperar de ellos. Las fallas de equipo (por ejemplo errores
de paridad en memoria, errores en dispositivos de entrada/salida) pueden ser simuladas
Prueba de Mltiples Sitios: El propsito de esta prueba es evaluar el correcto funcionamiento del sistema o
subsistema en mltiples instalaciones.
Prueba de Compatibilidad y Conversin: El propsito es demostrar que los objetivos de compatibilidad no han
sido logrados y que los procedimientos de conversin no funcionan.
La mayora de los programas que se desarrollan no son completamente nuevos; con frecuencia son reemplazos
de partes deficientes, ya sea de sistemas de procesamiento de datos, o sistemas manuales.
Como tales, los programas tienen a menudo objetivos especficos con respecto a su compatibilidad y a sus
procedimientos de conversin con el sistema existente.
Pruebas de Integridad de Datos y Base de Datos: La Base de datos y los procesos de Base de datos deben
ser probados como sistemas separados del proyecto. Estos sistemas deberan ser probados sin usar interfaces
de usuario (como las interfaces de datos). Se necesita realizar investigacin adicional en el DBMS para identificar
las herramientas y tcnicas que podran existir para soportar las pruebas identificadas ms adelante.
Pruebas de Seguridad y Control de Acceso: Las pruebas de seguridad y control de acceso se centran en dos
reas claves de seguridad:
o
o

Seguridad del sistema, incluyendo acceso a datos o Funciones de negocios y


Seguridad del sistema, incluyendo ingresos y accesos remotos al sistema.

Las pruebas de seguridad de la aplicacin garantizan que, con base en la seguridad deseada, los usuarios estn
restringidos a funciones especficas o su acceso est limitado nicamente a los datos que est autorizado a
acceder. Por ejemplo, cada usuario puede estar autorizado a crear nuevas cuentas, pero slo los administradores
pueden borrarlas. Si existe seguridad a nivel de datos, la prueba garantiza que un usuario tpico 1 puede ver
toda la informacin de clientes, incluyendo datos financieros; sin embargo, el usuario 2 solamente puede ver los
datos institucionales del mismo cliente.
Las pruebas de seguridad del sistema garantizan que solamente aquellos usuarios autorizados a acceder al
sistema son capaces de ejecutar las funciones del sistema a travs de los mecanismos apropiados.
Debido a la creciente preocupacin de la sociedad por la privacidad de la informacin, muchos programas tienen
objetivos especficos de seguridad.
El objetivo de esta prueba es evaluar el funcionamiento correcto de los controles de seguridad del sistema para
asegurar la integridad y confidencialidad de los datos. El foco principal es probar la vulnerabilidad del sistema
frente a accesos o manipulaciones no autorizadas. Una manera de encontrar esos casos de prueba es estudiar
problemas conocidos de seguridad en sistemas similares y tratar de mostrar la existencia de problemas
parecidos en el sistema que se examina.

Algunas consideraciones de prueba son:


Controles de acceso fsico
o Acceso a estructuras de datos especficas a travs de los programas de aplicacin.
o Seguridad en sitios remotos
o Existencia de datos confidenciales en reportes y pantallas
o Controles manuales, incluyendo aquellos para autorizacin y aprobacin, formularios, documentacin
numerada, transmisin de datos, balances y conversin de datos.
o Controles automticos, incluyendo aquellos para edicin de datos, chequeo de mquinas, errores del
operador, acceso a datos elementales y archivos, acceso a funciones, auditora, entre otros.
Pruebas del Ciclo del Negocio: Las pruebas del ciclo de negocio deberan emular las actividades ejecutadas en
el a travs del tiempo. Debera identificarse un periodo, como por ejemplo un ao, y las transacciones y

actividades que podran ocurrir durante un periodo de un ao deberan ejecutarse. Incluyendo todos los ciclos y
eventos diarios, semanales y mensuales que sean datos sensitivos, como las agendas.
Pruebas de GUI: La prueba de interfaz de usuario verifica la interaccin del usuario con el software. El objetivo
es asegurar que la interfaz tiene apropiada navegacin a travs de las diferentes funcionalidades.
Adicionalmente, las pruebas de interfaz aseguran que los objetos de la interfaz a ser probada se encuentra
dentro de los estndares de la industria.
Pruebas de Configuracin: Estas pruebas verifican la operacin del sistema en diferentes configuraciones de
hardware y software. En la mayora de los ambientes de produccin, las especificaciones para las estaciones de
trabajo, equipos de red y servidores pueden variar. Las estaciones pueden tener diferentes versiones de software
instaladas (Sistemas Operativos, Drivers, etc) y en cualquier momento, pueden llegar a utilizarse diferentes
combinaciones.
Con frecuencia, el nmero de configuraciones posibles es demasiado grande para intentar una prueba de cada
una de ellas, pero el programa debe probarse al menos con cada tipo de dispositivo y con las configuraciones
mnima y mxima posibles.
Prueba de Estilo: Se entienden como tales el formato de las ventanas, colores corporativos, tipos de letra etc.
Prueba de Instalacin: Las pruebas de instalacin tienen dos propsitos. El primero es asegurar que el sistema
puede ser instalado en todas las configuraciones posibles, tales como nuevas instalaciones, actualizaciones,
instalaciones completas o personalizadas, y bajo condiciones normales o anormales; estas ltimas incluyen
insuficiente espacio en disco, falta de privilegios para algunas tareas, etc.
El segundo propsito es verificar que, una vez instalado, el sistema opera correctamente. Esto usualmente
implica correr un nmero significativo de pruebas de Funcionalidad.
Pruebas Funcionales: Las pruebas Funcionales deben enfocarse en los requisitos funcionales, las pruebas
pueden estar basadas directamente en los Casos de Uso (o funciones de negocio), y las reglas del negocio. Las
metas de estas pruebas son:
o
o

Verificar la apropiada aceptacin de datos,


Verificar el procesamiento y recuperacin y la implementacin adecuada de las reglas del negocio.

Este tipo de pruebas estn basadas en tcnicas de caja negra, que es, verificar la aplicacin (y sus procesos
internos) mediante la interaccin con la aplicacin va GUI y analizar la salida (resultados). Lo que se identifica a
continuacin es un diseo preliminar de las pruebas recomendadas para cada aplicacin.

Prueba de Documentacin Y Procedimiento: Evaluar la exactitud y claridad de la documentacin del usuario y


para determinar si el manual de procedimientos trabajar correctamente como una parte integral del sistema.
Muchos defectos son identificados cuando un probador competente chequea totalmente los manuales y
documentacin del usuario.
Muchos programas son parte de sistemas mayores, no completamente automatizados, que contienen
procedimientos realizados por operadores. Cualquier procedimiento humano, tal como los que llevan a cabo el
operador, el administrador de la base de datos, o el usuario de terminal, debe ser probado durante la prueba de
sistemas.
Prueba de Usabilidad: Determina cun bien el usuario podr usar y entender la aplicacin. Identifica las reas
de diseo que hacen al sistema de difcil uso para el usuario.
La prueba de usabilidad detecta problemas relacionados con la conveniencia y practicidad del sistema desde el
punto de vista del usuario.
Prueba de Campo: Realizar un subconjunto vlido de pruebas de sistema.

Punto nmero 6
los programadores que intervengan en el caso, se apoyarn en:
El proceso de mantenimiento consiste en cambiar un sistema despus de que ste se entreg; generalmente se
aplica a software hecho a la medida y los cambios consisten desde la simple correccin de errores, hasta
mejoras significativas para corregir errores de especificacin o bien, agregar nuevos requerimientos. Existen
tres tipos de mantenimiento de software:

1. Reparacin de fallas. Errores de codificacin, diseo o requerimientos, siendo estos ltimos los ms
costosos de corregir.
2. Adaptacin ambiental. Es necesario cuando algn aspecto del entorno del sistema como hardware,
plataforma operativa o algn otro elemento hacer cambiar al software. El sistema debe modificarse para
que se adapte a dichos cambios.
3. Adicin de funcionalidad. Este tipo de mantenimiento es necesario cuando los requerimientos
funcionales cambian por algn factor organizacional o empresarial. Generalmente este tipo de cambios
es ms grande que los anteriores.
Como podemos darnos cuenta, la adaptacin es una palabra clave en el proceso del mantenimiento al software;
ya que lo que se busca es hacer que ste se adapte cada vez ms a la solucin de las necesidades del ser
humano, por ello desde la reparacin de fallas, los ajustes al contexto ambiental en el que se encuentra o
simplemente agregarle mayor funcionalidad, son actividades que convertirn al software en una verdadera
herramienta de trabajo para la humanidad.
Para el mantenimiento, el programador deber tener en cuenta:
Fase de mantenimiento
Se centra en el cambio:

Correccin de errores
Adaptaciones requeridas a medida que evoluciona el entorno del software
Cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente
Se encuentran cuatro tipos de cambio:

o Correccin
o Adaptacin
o Mejora
o Prevencin
El software sufrir cambios a lo largo de su vida til. Estos cambios pueden ser debidos a tres causas:

Que, durante la utilizacin, el cliente detecte errores en el software: los errores latentes.
Que se produzcan cambios en alguno de los componentes del sistema.
Que el cliente requiera modificaciones funcionales no contempladas en el proyecto.

FUENTES DE CONSULTA:
http://ing-sw.blogspot.mx/2005/04/tipos-de-pruebas-de-software.html
http://www.ctr.unican.es/asignaturas/Ingenieria_Software_4_F/Doc/M7_09_VerificacionVali