Como se habrá notado, existen muchos tipos de pruebas que pueden aplicarse al software y estasdependen de lo que se quiera probar. También el proceso del mantenimiento puede ser variado y principalmente depende de la situación de cada software en particular. Por lo cual podemos decir que no existe una receta que pueda adaptarse a todos los proyectos. A continuación completa lo que se te indica para que de esta manera puedas experimentar esto que se comenta. Esta actividad tiene como propósito 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 están utilizando. Justifica cada respuesta. 2. Además 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 más 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 continuación se explican uno de los casos de los proyectos que atendimos. El cliente de este proyecto, ha pedido que se le adelante la demostración del código, ya que estará ausente por un viaje no previsto de 15 días. El equipo de desarrollo ha invertido más horas para lograr codificar la iteración planeada, algunas pruebas los programadores las aplicaron y en otras se nos ha pedido que les apoyemos, para de esta manera entregar la aplicación lo más 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, métodos, objetos, atributos. Esto fue realizado por cada programador que además corregía el código 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 válidos. Se registraron los errores que ocurrieron fueron de este tipo: Algunas interfaces no funcionaron adecuadamente. Inconsistencias en la presentación de datos con respecto a las opciones del menú. 3. Se probó el módulo que sería entregado en esta interacción para que se integrara correctamente a la estructura del sistema y se probaron los módulos, liberados anteriormente, para verificar que la inserción del nuevo no causara conflicto a los existentes. 4. Por último, el día de la presentación, un representante del equipo de pruebas y el analista entregaron el avance al cliente, quien se hizo acompañar de uno de los usuarios del sistema. Ambos evaluaron el nuevo en esta ocasión fueron los principales usuarios quienes probaron el software. Valores límites. 5. Además: Pruebas de unidad: se encarga de probar componentes del programa. lo cual nos permitió liberar el módulo. Validaciones. Busca asegurar que el código funciona de acuerdo con las especificaciones y que el módulo lógico es válido. Ya no se encontraron más defectos. Pruebas del sistema: se prueba la integración de todos los componentes. 6. Después de haber liberado este módulo se concluyó con el sistema. . Descripción de la Prueba: Particionar los módulos en pruebas en unidades lógicas fáciles de probar. por lo tanto el diseñador debe construirlos con acceso al código fuente de la unidad a probar. Mensajes posibles. Si existen errores. Se tienen que diseñar pruebas para revisar todas las operaciones asociadas. La última prueba se realizó en la empresa del cliente. como métodos o clases de objetos. establecer y verificar el valor de todos los atributos y poner el objeto en todos los estados posibles. reportarlos y desde luego corregirlos. La empresa ha sido contratada. los cuales fueron oportunamente solucionados. pues está proyectado que en este periodo. Técnica: Comparar el resultado esperado con el resultado obtenido. ej. Para esto los casos de prueba deben diseñarse de forma tal que se recorran todos los caminos de ejecución posibles dentro del código bajo prueba. Valores válidos.módulo en una computadora. los programadores que intervinieron en el caso. También cada programador deberá tener en cuenta: Objetivo de la Prueba: Se focaliza en ejecutar cada módulo (o unidad mínima a ser probada. TIPOS DE PRUEBA Para el punto número 1. para dar mantenimiento al software. o o Pruebas del componente: se prueban las interfaces de los componentes. que se preparó previamente para tal fin por el equipo de pruebas. = una clase) lo que provee un mejor modo de manejar la integración de las unidades en componentes mayores. se apoyaron en: Pruebas de unidad: para probar programas o clases. Manejo de parámetros. Sirven para comprobar la funcionalidad de objetos o métodos. El resultado de esta revisión fueron únicamente 3 defectos de interfaz. Por cada unidad hay que definir los casos de prueba (pruebas de caja blanca). Los aspectos a considerar son los siguientes: Rutinas de excepción. se renovarán las licencias del sistema operativo y del manejador de base de datos y posiblemente se tengan que hacer ajustes al software liberado. Rutinas de error. por este año. Rangos. Por ejemplo: Uso incorrecto de la interfaz. los programadores que intervinieron en el caso. Consideraciones Especiales: Para la elaboración de pruebas unitarias en java se puede utilizar el JUNIT y CACTUS. Mala interpretación de la interfaz. Determina cómo la base de datos de prueba será cargada. Para tal efecto. Determina el enfoque para avanzar desde un nivel de integración de las componentes al siguiente. Errores de temporización. se apoyaron en: Pruebas de componentes: se enfoca en demostrar que la interfaz de componente se comporte según la especificación. Existen diferentes tipos de interfaz entre componentes de programa y. Verificar que las interfaces entre las entidades externas (usuarios) y las aplicaciones funcionan correctamente. en consecuencia. Todos los defectos que se identificaron han sido tenidos en cuenta. Verificar que las especificaciones de diseño sean alcanzadas. Decide qué acciones tomar cuando se descubren problemas. cada programador deberá tener en cuenta: Objetivo de la Prueba: Identificar errores introducidos por la combinación de programas probados unitariamente. distintos tipos de error de interfaz.Criterio de Completitud: Todas las pruebas planeadas han sido ejecutadas. Determina cómo la base de datos de prueba será cargada. Para el punto número 2. Determina el enfoque para avanzar desde un nivel de integración de las componentes al siguiente. Por cada Caso de Prueba ejecutado: Comparar el resultado esperado con el resultado obtenido. Descripción de la Prueba: Describe cómo verificar que las interfaces entre las componentes de software funcionan correctamente. Técnica: . No debe confundirse con las pruebas de volumen: un esfuerzo grande es un pico de volumen de datos que se presenta en un corto período de tiempo. Máximo número de clientes conectados o simulados (actuales o físicamente posibles) Múltiples usuarios desempeñando la misma transacción con los mismos datos. con los parámetros down-top. El peor caso de volumen de transacciones (ver pruebas de desempeño). El objetivo de esta prueba es investigar el comportamiento del sistema bajo condiciones que sobrecargan sus 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. cada programador deberá tener en cuenta: Objetivo de la Prueba: Verificar que el sistema funciona apropiadamente y sin errores. NOTAS: La meta de las pruebas de stress también es identificar y documentar las condiciones bajo las cuales el sistema FALLA. Una manera de descubrir defectos es diseñar pruebas sobre los límites del sistema. Generalmente consisten en aumentar la carga hasta que el sistema se vuelve inaceptable. y se verifica que los superior llaman a los de nivel inferior de manera correcta. Se empieza con los módulos de nivel inferior. significa estresar el sistema al hacer demandas que estén fuera de los límites del diseño del software. Esto se conoce como “prueba de esfuerzo”. Se empieza con los módulos de nivel superior. . Todos los defectos que se identificaron han sido tenidos en cuenta. Para tal efecto. top-down. los programadores que intervinieron en el caso. Descripción de la Prueba: Las pruebas de stress se proponen encontrar errores debidos a recursos bajos o completitud de recursos. Las pruebas de stress identifican la carga máxima que el sistema puede manejar. con los parámetros Criterio de Completitud: Todas las pruebas planeadas han sido ejecutadas. Utilizar la técnica módulos de nivel correctos. como bloqueos de base de datos o ancho de banda de la red. y se verifica que los inferior llaman a los de nivel superior de manera correcta. Consideraciones Especiales: Ninguna Para el punto número 3. con ellas es posible probar el rendimiento y confiabilidad. se apoyaron en: Pruebas de rendimiento: Se aplican cuando el sistema ha sido integrado completamente. Utilizar la técnica módulos de nivel correctos. En las pruebas de rendimiento. bajo estas condiciones de stress: Memoria baja o no disponible en el servidor. la prueba es valiosa porque es de esperar que los mismos errores puedan presentarse en situaciones reales. sin embargo. Para probar recursos limitados. algo menos exigentes. interactivos. Es aplicable. ( O si las condiciones en que el sistema falle ocurren por fuera de las condiciones especificadas). los programadores que intervinieron en el caso. de tiempo real y de control de proceso. Esto no implica. muchas otras serán en verdad situaciones que nunca ocurrirán en la realidad.Puesto que la prueba de esfuerzo involucra un elemento de tiempo. 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. Para los puntos número 4 y 5. no resulta aplicable a muchos programas. Técnica: Usar los scripts utilizados en las pruebas de desempeño. el rendimiento. Aunque muchas pruebas de esfuerzo representan condiciones que el programa encontrará realmente durante su utilización. deciden si está o no listo para ser aceptado. Para las pruebas de stress restantes. cada programador deberá tener en cuenta: Pruebas Alfa . Si se detectan errores durante estas condiciones “imposibles”. deben utilizarse múltiples clientes. ya sea corriendo los mismos scripts o scripts complementarios para producir el peor caso de volumen de transacciones. las pruebas se deben correr en un servidor con configuración reducida (o limitada). Consideraciones Especiales: Producir stress en la red puede requerir herramientas de red para sobrecargarla de tráfico. sin embargo. 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. a programas que trabajan bajo cargas variables. Pruebas de aceptación: son las únicas pruebas que son realizadas por los usuarios. Sincronización de varios clientes accediendo simultáneamente los mismos registros. Criterio de Completitud: Todas las pruebas planeadas han sido ejecutadas y excedidas sin que el sistema falle. que estas pruebas no sean útiles. En la práctica 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 máquina preparada para tal fin. Para tales efectos. el uso y la robustez de un sistema. Pruebas beta: las realiza el usuario después de que el equipo de desarrollo les entregue una versión casi definitiva del producto. por ejemplo a un compilador o a una rutina de pagos. . Criterio de Completitud: Todas las pruebas planeadas han sido ejecutadas. Usan el sistema en sus actividades cotidianas. procesan transacciones y producen salidas normales del sistema. Se selecciona un grupo de usuarios para el alpha test y se les pide trabajen con el sistema como parte de las pruebas. Técnica: Se selecciona un grupo de usuarios que ponen a trabajar el sistema en un ambiente real. con el fin de encontrar errores. Todos los defectos que se identificaron han sido tenidos en cuenta.Objetivo de la Prueba: Prueba de aceptación para detectar errores en el sistema bajo un ambiente controlado. Técnica: Realizar las pruebas de sistema bajo las siguientes características: Se llevan a cabo en el lugar en donde fue desarrollado el SW. Consideraciones Especiales: Ninguna Pruebas Beta Objetivo de la Prueba: Realizar la validación del sistema por parte del usuario. en el cual el desarrollador está presente. Descripción de la Prueba: Prueba de aceptación donde La validación (o pruebas beta) involucra el uso del software en un ambiente real. En un ambiente controlado. Descripción de la Prueba: La verificación involucra la ejecución de partes o todo del sistema en ambientes simulados. La retroalimentación de esta fase produce cambios en el software para resolver los errores y fallas que se descubren. 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. La prueba de aceptación es generalmente desarrollada y ejecutada por el cliente o un especialista de la aplicación y es conducida a determinar como el sistema satisface sus criterios de aceptación validando los requisitos que han sido levantados para el desarrollo. Los usuarios realizan pruebas a su antojo realizando uso de la aplicación. Para la realización de estas pruebas se necesita disponer de los siguientes documentos: Especificación de requisitos del sistema. Técnica: Realización de los documentos de planes de prueba de aceptación y especificación de los mismos. basados en los criterios de aceptación del cliente. Descripción de la Prueba: La prueba de aceptación es ejecutada antes de que la aplicación sea instalada dentro de un ambiente de producción. Prueba de Aceptación Objetivo de la Prueba: Determinación por parte del cliente de la aceptación o rechazo del sistema desarrollado. Criterio de Completitud: Se establece un periodo de pruebas beta en el que los errores detectados no sean de carácter crítico para el sistema. Las transacciones y personas que usan el sistema son reales y trabajan en su área de trabajo real. Sirve para que el usuario pueda validar si el producto final se ajusta a los requisitos fijados. Basado en esta prueba el cliente determina si acepta o rechaza el sistema Estas pruebas están destinadas a probar que el producto está listo para el uso operativo. Los casos prueba de aceptación han de ser planificados. organizados y formalizados de manera que se determine el cumplimiento de los requisitos del sistema. Suelen ser un subconjunto de las Pruebas de Sistema. Consideraciones Especiales: Se deben considerar mecanismos de comunicación entre los desarrolladores y los usuarios de manera que los errores detectados puedan ser corregidos. El desarrollador no está presente. . Los usuarios están advertidos de que están usando un sistema que puede fallar. incluyendo a documentación y procesos de negocio. si las Pruebas ocurren tarde en el ciclo de desarrollo está será una forma de garantizar el buen desarrollo. y la implementación apropiada de las reglas de negocios. procesamiento y recuperación apropiado de datos. pueden llevarse a cabo para una TOTAL satisfacción de los involucrados (Cliente y programador). Manual de administrador. Las pruebas de desempeño usualmente se ejecutan varias veces. la interacción con las aplicaciones que lo usan vía GUI y analizar las salidas o resultados. 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. Prueba de integración: o Describe cómo verificar que las interfaces entre las componentes de software funcionan correctamente. Consideraciones Especiales: Las Pruebas de Aceptación se suelen realizar en un entorno de pre-producción. mantenimiento o desarrollo de la nueva versión del sistema buscando efectos adversos en otras partes. Pruebas de Desempeño: Las pruebas de desempeño miden tiempos de respuesta. que a consideración de los involucrados (Cliente y programador). El objetivo de estas pruebas es verificar el ingreso. Algunas veces. Este tipo de pruebas se basan en técnicas de caja negra. Por cada Caso de Prueba ejecutado: o Comparar el resultado esperado con el resultado obtenido. utilizando en cada una. La prueba inicial debe . o Decide qué acciones tomar cuando se descubren problemas. En algunos proyectos este tipo de prueba va junto con las pruebas funcionales. o Determina cómo la base de datos de prueba será cargada. el desempeño ofrecido por el proponente). 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. Prueba de regresión: En esta prueba se vuelve a probar el sistema a la luz de los cambios realizados durante el debugging. Realizar Pruebas de estilo Criterio de Completitud: Todas las pruebas planeadas han sido ejecutadas. verificar el sistema (y sus procesos internos). el tiempo de desarrollo para el SW. o Determina el enfoque para avanzar desde un nivel de integración de las componentes al siguiente. El objetivo de las pruebas de desempeño es verificar y validar los requisitos de desempeño que se han especificado (en este caso. Todos los defectos que se identificaron han sido tenidos en cuenta. carga diferente en el sistema. Además de estas pruebas siempre se realizan por el equipo de trabajo de la empresa en desarrollo de SW. Las pruebas de humo NO SON exhaustivas. esto es. pero van de extremo a extremo de la aplicación. Manual de usuario. Permite detectar problemas que por lo regular no son detectados en las pruebas normales. otra serie de pruebas. índices de procesamiento de transacciones y otros requisitos sensibles al tiempo. Cuellos de botella en discos. Algunas características que afectan el desempeño son: o o o o o o o o o Errores lógicos Procesamiento ineficiente Diseño pobre: muchas interfaces. CPU o canales de entrada/salida Salidas del sistema Tiempos de respuesta Capacidad de almacenamiento Tasa de entrada/salida de datos Número de transacciones que pueden ser manejadas simultáneamente. Adicionalmente. Una segunda prueba debe hacerse utilizando una carga máxima. las pruebas de carga evalúan las características de desempeño (tiempos de respuesta. una prueba de volumen podría usar una Base de datos de prueba grande y verificar que el sistema se comporta normalmente y produce el reporte correctamente. o Un simulador de circuito electrónico puede recibir un circuito diseñado con miles de componentes. Por ejemplo. También identifican la carga máxima o volumen que el sistema puede manejar en un período dado. La meta de las pruebas de carga es determinar y asegurar que el sistema funciona apropiadamente aún más allá de la carga de trabajo máxima esperada. o Un editor de nexos puede recibir un programa que contenga miles de módulos. las pruebas de desempeño pueden ser utilizadas para perfilar y refinar el desempeño del sistema como una función de condiciones tales como carga o configuraciones de hardware. Los objetivos de nivel de servicio definidos deben guiar la prueba de performance. instrucciones y entradas/salidas. Pruebas de Volumen: Las pruebas de volumen hacen referencia a grandes cantidades de datos para determinar los límites en que se causa que el Sistema falle. Las pruebas de desempeño utilizan las técnicas de caja blanca y caja negra. Poner a punto el sistema para mejorar las métricas de desempeño y proyectar la capacidad futura de carga del sistema. tasas de transacciones y otros aspectos sensibles al tiempo). Pruebas de Carga: Las pruebas de carga miden la capacidad del sistema para continuar funcionando apropiadamente bajo diferentes condiciones de carga. El objetivo de esta prueba es someter al sistema a grandes volúmenes de datos para determinar si el mismo puede manejar el volumen de datos especificado en sus requisitos. . Adicionalmente. Algunos ejemplos de escenarios de prueba de volúmenes: o Un compilador puede ser alimentado por un programa para compilar que sea absurdamente grande.ser ejecutada con una carga similar a la esperada en el sistema. Las principales actividades son: o o Comparar el desempeño del sistema actual con los requisitos. si el sistema está procesando un conjunto de registros de Base de datos para generar un reporte. incluyendo datos financieros. Las pruebas de seguridad de la aplicación garantizan que. Si existe seguridad a nivel de datos. o sistemas manuales. Las pruebas de recuperación son contrarias a las pruebas en que la aplicación o sistema es expuesto a condiciones extremas (o condiciones simuladas). 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. con frecuencia son reemplazos de partes deficientes. con base en la seguridad deseada. errores en dispositivos de entrada/salida) pueden ser simuladas Prueba de Múltiples Sitios: El propósito de esta prueba es evaluar el correcto funcionamiento del sistema o subsistema en múltiples instalaciones. Sin embargo. los sistemas alternos o de respaldo pueden tomar control del sistema sin pérdida de datos o transacciones. 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. a algunas pruebas de volumen Pruebas de Recuperación y Tolerancia a fallas: Estas pruebas aseguran que una aplicación o sistema se recupere de una variedad de anomalías de hardware. El objetivo de esta prueba es determinar la habilidad del sistema para recuperarse de una falla de hardware o software. cada usuario puede estar autorizado a crear nuevas cuentas. cuando una condición de falla ocurre. los usuarios están restringidos a funciones específicas o su acceso está limitado únicamente a los datos que está autorizado a acceder. tales como fallas en dispositivos en entrada/salida o llaves o apuntadores inválidos de base de datos. Como tales. Errores de programación o de datos pueden ser incorporados ex profeso en un sistema para determinar si se puede recuperar de ellos. software o red con pérdidas de datos o fallas de integridad. Por ejemplo. tanto en tiempo de máquina como en personal. La mayoría de los programas que se desarrollan no son completamente nuevos. pero sólo los administradores pueden borrarlas. sin embargo. Las fallas de equipo (por ejemplo errores de paridad en memoria. se debe tratar de no exceder los límites. La recuperación debe ser considerada en el proceso de diseño. Puesto que obviamente. el usuario 2 solamente puede ver los datos institucionales del mismo cliente. Se necesita realizar investigación adicional en el DBMS para identificar las herramientas y técnicas que podrían existir para soportar las pruebas identificadas más adelante. Las pruebas de tolerancia a fallas aseguran que. la prueba de volumen es una prueba costosa. Esta prueba evalúa las características de contingencia construidas en el sistema para procesar interrupciones y para volver a puntos específicos en el ciclo de procesamiento del sistema. todo programa debería ser expuesto. . Estos sistemas deberían ser probados sin usar interfaces de usuario (como las interfaces de datos). los programas tienen a menudo objetivos específicos con respecto a su compatibilidad y a sus procedimientos de conversión con el sistema existente. Prueba de Compatibilidad y Conversión: El propósito es demostrar que los objetivos de compatibilidad no han sido logrados y que los procedimientos de conversión no funcionan. para aquellos sistemas que deben mantenerse corriendo. la prueba garantiza que un usuario “típico” 1 puede ver toda la información de clientes. al menos. ya sea de sistemas de procesamiento de datos. Los procesos de recuperación se invocan y la aplicación es monitoreada y/o inspeccionada para verificar que éstos mecanismos se han ejecutado en forma apropiada. incluyendo acceso a datos o Funciones de negocios y Seguridad del sistema. incluyendo ingresos y accesos remotos al sistema. 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 través de los mecanismos apropiados. Drivers. las pruebas pueden estar basadas directamente en los Casos de Uso (o funciones de negocio). pero el programa debe probarse al menos con cada tipo de dispositivo y con las configuraciones mínima y máxima posibles. formularios. etc. tipos de letra etc. Algunas consideraciones de prueba son: Controles de acceso físico o Acceso a estructuras de datos específicas a través de los programas de aplicación. pueden llegar a utilizarse diferentes combinaciones. errores del operador. balances y conversión de datos. documentación numerada. una vez instalado. Pruebas Funcionales: Las pruebas Funcionales deben enfocarse en los requisitos funcionales. Debido a la creciente preocupación de la sociedad por la privacidad de la información. Esto usualmente implica correr un número significativo de pruebas de Funcionalidad. instalaciones completas o personalizadas. El primero es asegurar que el sistema puede ser instalado en todas las configuraciones posibles. falta de privilegios para algunas tareas. Pruebas de GUI: La prueba de interfaz de usuario verifica la interacción del usuario con el software. Las estaciones pueden tener diferentes versiones de software instaladas (Sistemas Operativos. Pruebas de Configuración: Estas pruebas verifican la operación del sistema en diferentes configuraciones de hardware y software. entre otros. las pruebas de interfaz aseguran que los objetos de la interfaz a ser probada se encuentra dentro de los estándares de la industria. etc) y en cualquier momento. acceso a funciones. como por ejemplo un año. 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. Debería identificarse un periodo. colores corporativos. Prueba de Estilo: Se entienden como tales el formato de las ventanas. muchos programas tienen objetivos específicos de seguridad. incluyendo aquellos para edición de datos. El objetivo es asegurar que la interfaz tiene apropiada navegación a través de las diferentes funcionalidades. y las transacciones y actividades que podrían ocurrir durante un periodo de un año deberían ejecutarse. el número de configuraciones posibles es demasiado grande para intentar una prueba de cada una de ellas. transmisión de datos. y las reglas del negocio. Pruebas del Ciclo del Negocio: Las pruebas del ciclo de negocio deberían emular las actividades ejecutadas en el a través del tiempo. En la mayoría de los ambientes de producción. auditoría. estas últimas incluyen insuficiente espacio en disco. 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. o Seguridad en sitios remotos o Existencia de datos confidenciales en reportes y pantallas o Controles manuales. equipos de red y servidores pueden variar. El segundo propósito es verificar que. Las metas de estas pruebas son: . o Controles automáticos. Prueba de Instalación: Las pruebas de instalación tienen dos propósitos. actualizaciones. El foco principal es probar la vulnerabilidad del sistema frente a accesos o manipulaciones no autorizadas. y bajo condiciones normales o anormales. acceso a datos elementales y archivos. el sistema opera correctamente. incluyendo aquellos para autorización y aprobación. Adicionalmente. como las agendas. tales como nuevas instalaciones. semanales y mensuales que sean datos sensitivos. chequeo de máquinas. Con frecuencia. las especificaciones para las estaciones de trabajo. Incluyendo todos los ciclos y eventos diarios. Muchos programas son parte de sistemas mayores. no completamente automatizados. Adaptación ambiental. que contienen procedimientos realizados por operadores. 2. Adición de funcionalidad. el programador deberá tener en cuenta: Fase de mantenimiento Se centra en el cambio: Corrección de errores . tal como los que llevan a cabo el operador. la adaptación es una palabra clave en el proceso del mantenimiento al software. plataforma operativa o algún otro elemento hacer cambiar al software. Existen tres tipos de mantenimiento de software: 1. que es. Errores de codificación. La prueba de usabilidad detecta problemas relacionados con la conveniencia y practicidad del sistema desde el punto de vista del usuario. ya que lo que se busca es hacer que éste se adapte cada vez más a la solución de las necesidades del ser humano. Lo que se identifica a continuación es un diseño preliminar de las pruebas recomendadas para cada aplicación.o o Verificar la apropiada aceptación de datos. Como podemos darnos cuenta. siendo estos últimos los más costosos de corregir. se apoyarán en: El proceso de mantenimiento consiste en cambiar un sistema después de que éste se entregó. debe ser probado durante la prueba de sistemas. Cualquier procedimiento humano. Este tipo de pruebas están basadas en técnicas de caja negra. Prueba de Usabilidad: Determina cuán bien el usuario podrá usar y entender la aplicación. verificar la aplicación (y sus procesos internos) mediante la interacción con la aplicación vía GUI y analizar la salida (resultados). Prueba de Campo: Realizar un subconjunto válido de pruebas de sistema. los ajustes al contexto ambiental en el que se encuentra o simplemente agregarle mayor funcionalidad. diseño o requerimientos. El sistema debe modificarse para que se adapte a dichos cambios. Para el punto número 6. por ello desde la reparación de fallas. generalmente se aplica a software hecho a la medida y los cambios consisten desde la simple corrección de errores. Identifica las áreas de diseño que hacen al sistema de difícil uso para el usuario. Para el mantenimiento. Es necesario cuando algún aspecto del entorno del sistema como hardware. Verificar el procesamiento y recuperación y la implementación adecuada de las reglas del negocio. 3. Este tipo de mantenimiento es necesario cuando los requerimientos funcionales cambian por algún factor organizacional o empresarial. agregar nuevos requerimientos. son actividades que convertirán al software en una verdadera herramienta de trabajo para la humanidad. el administrador de la base de datos. Generalmente este tipo de cambios es más grande que los anteriores. hasta mejoras significativas para corregir errores de especificación o bien. Reparación de fallas. Prueba de Documentación Y Procedimiento: Evaluar la exactitud y claridad de la documentación del usuario y para determinar si el manual de procedimientos trabajará correctamente como una parte integral del sistema. o el usuario de terminal. los programadores que intervengan en el caso. Muchos defectos son identificados cuando un probador competente chequea totalmente los manuales y documentación del usuario. mx/~molguin/as/IngSoft%201-4.uabc.mx/2005/04/tipos-de-pruebas-de-software. el cliente detecte errores en el software: los errores latentes. 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 Corrección o Adaptación o Mejora o Prevención El software sufrirá cambios a lo largo de su vida útil.pdf . Que se produzcan cambios en alguno de los componentes del sistema.es/asignaturas/Ingenieria_Software_4_F/Doc/M7_09_VerificacionVali dacion-2011.unican.co/contenidos/301404/301404. Estos cambios pueden ser debidos a tres causas: Que. durante la utilización. Que el cliente requiera modificaciones funcionales no contempladas en el proyecto.mxl.ctr.pdf http://www.blogspot.edu. FUENTES DE CONSULTA: http://ing-sw.pdf http://datateca.html http://yaqui.unad.