Ingeniera en Desarrollo de

Software

Felipe de Jess Gutirrez Garca
(Al12535104)
5to. Cuatrimestre
Gloria Ziga Chvez
Facilitadora
Introduccin a la Ingeniera de Software
Unidad 3
Diseo, codificacin, pruebas y
mantenimiento
Evidencia de Aprendizaje
Tipos de pruebas y el proceso de
mantenimiento


Como se habr notado, existen muchos tipos de pruebas que pueden aplicarse al software y estas
dependen de lo que se quiera probar. Tambin el proceso del mantenimiento puede ser variado y
principalmente depende de la situacin de cada software en particular. Por lo cual podemos decir que no
existe una receta que pueda adaptarse a todos los proyectos. A continuacin completa lo que se te indica
para que de esta manera puedas experimentar esto que se comenta.
Esta actividad tiene como propsito seleccionar criterios de pruebas y mantenimiento para un caso de
estudio.
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.


TIPOS DE PRUEBA

Para el 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 Pruebas del componente: se prueban las interfaces de los componentes.
o 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.


Para el 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


Para el 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.

Para los 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.
o Determina cmo la base de datos de prueba ser cargada.
o Determina el enfoque para avanzar desde un nivel de integracin de las componentes al siguiente.
o 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,
o 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
o Procesamiento ineficiente
o Diseo pobre: muchas interfaces, instrucciones y entradas/salidas.
o Cuellos de botella en discos, CPU o canales de entrada/salida
o Salidas del sistema
o Tiempos de respuesta
o Capacidad de almacenamiento
o Tasa de entrada/salida de datos
o 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:

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

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

o 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 Seguridad del sistema, incluyendo acceso a datos o Funciones de negocios y
o 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 Verificar la apropiada aceptacin de datos,
o 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.

Para el 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://yaqui.mxl.uabc.mx/~molguin/as/IngSoft%201-4.pdf
http://www.ctr.unican.es/asignaturas/Ingenieria_Software_4_F/Doc/M7_09_VerificacionVali
dacion-2011.pdf
http://datateca.unad.edu.co/contenidos/301404/301404.pdf