DISCIPLINA DE PRUEBA

PRUEBAS
Propsito
Para verificar la interaccin entre los objetos Para verificar la integracin apropiada de todos los componentes del software Para verificar que todos los requisitos se han llevado a cabo correctamente

Para identificar y asegurar que los defectos se corrigen para la entrega del software

TOPICOS II

DISCIPLINA DE PRUEBA

PRUEBAS
Propsito
En muchas organizaciones, las prueba de software abarcan del 30 al 50 por ciento de los costos de desarrollo de software. Todava la mayora de las personas cree que el software no se prueba bien antes de que se entregue. Esta contradiccin est arraigada en dos hechos claros.

Primero, las pruebas de software son enormemente difciles. Las diferentes maneras que un programa dado puede comportarse son incuantificables.
Segundo, las pruebas se realizan sinuna metodologa clara y sin la automatizacin requerida o apoyo de herramienta. Mientras la complejidad del software hace la comprobacin completa una meta imposible, una metodologa bien concebida y el uso de herramientas innovadoras, puede mejorar la productividad y efectividad de la comprobacin del software grandemente.
TOPICOS II

DISCIPLINA DE PRUEBA

PRUEBAS
Propsito
Para sistemas de "seguridad crtica" dnde un fracaso puede daar a personas (como el control de trfico areo, gua de proyectiles, o los sistemas de entrega mdica), software con calidad superior es esencial para el xito del sistema producido. Para un sistema de MIS tpico, esta situacin no es obvia, pero el impacto de un defecto puede ser muy caro. Las pruebas bien realizadas, comenzadas temprano en el ciclo de vida del software, bajarn el costo de completar y mantener el software significativamente.

Tambin reducir grandemente los riesgos u obligaciones asociadas con despachar software de calidad pobre, como la productividad del usuario pobre, la entrada de los datos y errores de clculo, y conducta funcional inaceptable.
TOPICOS II

DISCIPLINA DE PRUEBA

PRUEBAS
Propsito
Hoy da, muchos sistema de MIS son de "misin crtica", esto significa, que las compaas no pueden cumplir sus funciones y experimentan prdidas masivas cuando las fallas ocurren. Por ejemplo: los bancos, o compaas de transporte. Deben probarse los sistemas de misin-crtica usando los mismos acercamientos rigurosos usados para los sistemas de seguridad-crticos.

TOPICOS II

DISCIPLINA DE PRUEBA

Requerimientos

TOPICOS II

DISCIPLINA DE PRUEBA

Requerimientos: Actividades

TOPICOS II

DISCIPLINA DE PRUEBA

Requerimientos: Artefactos

TOPICOS II

DISCIPLINA DE PRUEBA

PRUEBA
Relacin con Otras Disciplinas
La disciplina de Requerimientos captura los requisitos en un modelo de casos de uso que es una entrada primaria por identificar qu pruebas se deben realizar

La disciplina de Anlisis y Diseo describe cmo desarrollar un diseo; sta es la otra entrada primaria por identificar qu pruebas se deben realizar.
La disciplina de Implementacin produce construcciones del modelo de implementacin que se prueban. Dentro de una iteracin hay varias construcciones probadas, primero cuando el sistema se integra, y por ltimo se debe probar el sistema entero. La disciplina de Ambiente desarrolla y mantiene artefactos de apoyo que se usan durante la prueba, como las Pautas de la Prueba. La disciplina de Administracin de proyecto, planea el proyecto y cada iteracin (descrito en un Plan de la Iteracin).

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Pruebas de Aceptacin

La Prueba de aceptacin es la accin de prueba final prioritaria para desplegar el software. La meta es verificar que el software est listo y puede usarse por los usuarios finales para realizar esas funciones y tareas para las cuales que el software fue construido.
Hay tres estrategias comunes para llevar a cabo una prueba de aceptacin. Ellas son: Aceptacin Formal Aceptacin Informal o Pruebas Alfa Pruebas Beta

La estrategia que se selecciona es a menudo basada en los requisitos contractuales, normas de la organizacin y corporativas, y el dominio de la aplicacin.

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Pruebas de Aceptacin

Pruebas Formales de Aceptacin
La prueba de aceptacin formal es un proceso altamente manejado y es a menudo una extensin de la prueba del sistema. Las pruebas se planean y disean cuidadosamente y en el mismo detalle como la comprobacin del sistema. Los casos de prueba escogidos debe ser un subconjunto de aqullos realizado en la prueba del sistema. Es importante no desviarse de forma alguna de los casos de la prueba escogidos. En muchas organizaciones, las pruebas de aceptacin formales son totalmente automatizadas. Las actividades y artefactos son iguales que para la prueba del sistema. En algunas organizaciones, la organizacin de desarrollo (o su grupo de la prueba independiente), con los representantes de la organizacin del usuario final, realizan la prueba de aceptacin. En otras organizaciones, la prueba de aceptacin es completamente realizada por los usuarios finales de la organizacin, o un grupo objetivo de personas escogido por los usuarios finales.

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Pruebas de Aceptacin

Pruebas Formales de Aceptacin
Los beneficios son: Las funciones y caractersticas a ser probado son conocidos. Los detalles de las pruebas son conocidos y pueden medirse. Las pruebas pueden automatizarse, lo que permite la regresin de pruebas. El progreso de las pruebas puede medirse y puede supervisarse. El criterio de aceptabilidad es conocido. Las desventajas incluyen: Requiere los recursos significantes y planificacin. Las pruebas pueden ser una re-aplicacin de pruebas del sistema. No puede descubrir los defectos subjetivos en el software, debido a que usted slo est buscando defectos que usted espera encontrar.

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Pruebas de Aceptacin

Pruebas Informales de Aceptacin
En la prueba de aceptacin informal, los procedimientos de prueba para realizar la prueba no son rigurosamente definidos en cuanto a la comprobacin de aceptacin formal. Se identifican las funciones y las tareas de negocio son exploradas y documentadas, pero no hay ningn caso de prueba particular para seguir. El encargado de las pruebas determina qu hacer. Esta acometida de prueba de aceptacin no es tan controlada como la prueba formal y es ms subjetiva.

La prueba de aceptacin informal frecuentemente es en su mayora realizado por los usuarios finales de la organizacin.

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Pruebas de Aceptacin

Pruebas Informales de Aceptacin
Los beneficios son: Las funciones y rasgos a ser probado son conocidos. El progreso de las pruebas puede medirse y puede supervisarse. El criterio de aceptabilidad es conocido. Usted descubrir los defectos ms subjetivos que con la prueba de aceptacin formal. Las desventajas: Se requieren recursos, planificacin, y administracin de recursos. Usted no tiene ningn control sobre que casos de prueba se usan. Los usuarios finales pueden enfocarse sobre la manera que el sistema trabaja y no ver los defectos. Los usuarios finales pueden enfocarse en comparar el nuevo sistema con el sistema anterior, en lugar de buscar los defectos. Los recursos para las pruebas de aceptacin no estn bajo el control del proyecto y pueden ser restringidas.
TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Pruebas de Aceptacin

Pruebas Beta
Las pruebas beta son las menos controladas de las tres estrategias de prueba de aceptacin. En las pruebas beta, la cantidad de detalle, los datos, y la acometida tomada depende completamente del personal de prueba. Cada verificador es responsable de crear su propio ambiente, seleccionar sus datos, y determinar qu funciones, caractersticas, o tareas va a explorar. Cada verificador es responsable por identificar su propio criterio para determinar si aceptar el sistema en su estado actual o no.

Las pruebas beta se llevan a cabo por los usuarios finales, a menudo con una pequea o ninguna direccin del desarrollo (u otro no usuario final) la organizacin. La prueba beta es la ms subjetiva de todas las estrategias de prueba de aceptacin.

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Pruebas de Aceptacin

Pruebas Beta
Los beneficios son: La prueba se lleva a cabo por los usuarios finales. Grandes volmenes de potenciales recursos de prueba. Incrementa la satisfaccin de los clientes que participan. Se descubren los defectos ms subjetivos que con las pruebas de aceptacin formal o informal

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Pruebas de Aceptacin

Pruebas Beta
Las desventajas: No todas las funciones y / o caractersticas pueden probarse. El progreso de la prueba es difcil medir. Los usuarios finales pueden verificar a la manera el sistema trabaja y no ver o informar los defectos. Los usuarios finales pueden enfocarse en comparar el nuevo sistema con el sistema actual, en lugar de buscar los defectos. Los recursos para la prueba de aceptacin no estn bajo el control de proyecto y pueden ser estrechas. El criterio de aceptabilidad no es conocido. Se necesita incrementar los recursos de apoyo para manejar los verificadores de la beta

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Las claves de medidas para las pruebas

Introduccin
Las medidas importantes de una prueba incluyen cobertura y calidad. La cobertura de la prueba esta relacionado con probar la integridad, y esta basado en la cobertura de la prueba, o expresado por la cobertura de los requisitos de prueba y los casos de prueba, o por la cobertura del cdigo ejecutado. La calidad es una medida de fiabilidad, estabilidad, y desempeo de objetivo de la prueba (sistema o aplicacin bajo prueba). La Calidad es basada en la evaluacin de los resultados de las pruebas y el anlisis de demandas de cambio (los defectos) identificados durante la prueba.

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Las claves de medidas para las pruebas

Medidas de Cobertura
El mtrica de cobertura proporciona las respuestas a la pregunta "Cuan completa es la prueba? Las medidas de cobertura normalmente usadas son las basadas en requisitos y las basadas en cdigo. En el informe, la prueba de cobertura es cualquier medida de integridad con respecto a un requisito (basado en requisitos) o el diseo de cdigo o criterios de implementacin (basado en cdigo), como la verificacin de los casos de uso (basado en requisitos) o ejecucin de todas las lneas de cdigo (basado en cdigo). Cualquier actividad de prueba sistemtica es basada en por lo menos una estrategia de prueba de cobertura. La estrategia de cobertura gua el diseo de los casos de prueba declarando el propsito general de la comprobacin. La declaracin de estrategia de cobertura puede ser tan simple como verificar todo el desempeo.

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Las claves de medidas para las pruebas

Medidas de Cobertura
Si los requisitos son completamente catalogados, una estrategia de cobertura basada en requisitos puede ser suficiente para obtener una medida cuantificable para probar la integridad. Por ejemplo, si todos los requisitos de prueba de desempeo se han identificado, entonces los resultados de la prueba pueden ser los referenciados para conseguir las medidas, como el 75 por ciento de los requisitos de prueba de desempeo se han verificado. Si una prueba de cobertura basada en cdigo es aplicada, se formulan las estrategias en trminos de cuanto del cdigo de fuente se ha ejecutado por las pruebas. Este tipo de estrategia de prueba de cobertura es muy importante para los sistemas de seguridad-crtica. Ambas medidas pueden ser derivadas manualmente o pueden ser calculadas por herramientas de pruebas automatizadas.

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Las claves de medidas para las pruebas

Medidas de Calidad
Mientras la evaluacin de la prueba de cobertura proporciona la medida de probar la realizacin, una evaluacin de defectos descubiertos durante la prueba proporciona la mejor indicacin de calidad del software. La calidad es la indicacin de cuan bien el software rene los requisitos, en ese contexto, los defectos se identifican como un tipo de demanda de cambio. La evaluacin de defecto puede ser basada en mtodos que van desde simples defectos al modelo estadstico riguroso.

El anlisis de los defectos significa analizar la distribucin de defectos sobre los valores de uno o ms parmetros asociados con un defecto. El anlisis de defecto proporciona una indicacin de la fiabilidad del software.
Para el anlisis del defecto, hay normalmente cuatro parmetros usados: El estado el estado actual del defecto (abre, mientras siendo fijo, cerrado, etc.). La prioridad de la relativa importancia de este defecto que tiene que ser manejado y resuelto.
TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Las claves de medidas para las pruebas

Medidas de Calidad
La severidad del impacto relativo de este defecto. El impacto al usuario final, una organizacin, terceras partes, etc., La fuente dnde y qu origina la falla que produce este defecto, o qu componente se arreglar para eliminar el defecto. Es un elemento clave a determinar Las cuentas de Defectos pueden informarse como una funcin de tiempo, creando un diagrama de Tendencia de Defecto o un reporte, pueden informarse las cuentas del defecto como una funcin de uno o ms parmetros del defecto, como severidad o estado, en un informe de Densidad de Defecto. Estos tipos de anlisis proporcionan una perspectiva en las tendencias o distribucin de defectos que revelan la fiabilidad del software, respectivamente.

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Las claves de medidas para las pruebas

Medidas de Calidad
Los defectos incluidos en un anlisis de este tipo tienen que ser defectos confirmados. No todos los defectos reportados informan una falla real, algunos puede ser un requerimiento de mejora, fuera del alcance del proyecto, o describe un defecto ya reportado. Sin embargo, hay valores que buscar y analizar porque hay muchos defectos siendo reportados pueden estar duplicados o no ser defectos confirmados.

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Las claves de medidas para las pruebas

Medidas de Desempeo
Varias medidas son usadas para evaluar las conductas de desempeo del blanco de prueba y enfocadas en capturar datos relacionados a las conductas como tiempo de respuesta, perfiles de tiempo, flujo de la ejecucin, fiabilidad operacional y lmites. Principalmente, estas medidas se evalan en la actividad Evaluacin de la Prueba, sin embargo, hay medidas de desempeo que son usadas durante la actividad Ejecucin de la Prueba para evaluar el estado y progreso de la prueba.

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Las claves de medidas para las pruebas

Medidas de Desempeo
Las medidas de desempeo primarias incluyen: El monitoreo dinmico - captura en tiempo real y despliegue del estatus y el estado de cada prueba ejecutada durante la ejecucin de la prueba. El tiempo de respuesta / Throughput - la medida de el tiempo de respuesta o throughput del blanco-de-prueba para los actores especificados, y / o los casos de uso.

El Reporte Percentil - medida del percentil / el clculo de los valores recolectados de datos
Reporte de Comparacin - diferencias o tendencias entre dos (o ms) juegos de datos que representan las diferentes ejecuciones de prueba. Los Reporte de Rastro - los detalles de los mensajes / las conversaciones entre el actor y el blanco de prueba.
TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Prueba de Desempeo

La Prueba de Desempeo es una clase de pruebas llevada a implementadas y ejecutadas para caracterizar y evaluar el desempeo relacionado con las caractersticas del objetivo de la prueba como son los perfiles de tiempo, el flujo de la ejecucin, el tiempo de respuesta, y fiabilidad operacional y lmites. Los diferentes tipos de pruebas de desempeo, cada uno es enfocada en un objetivo de prueba diferente, que se lleva a cabo a lo largo del desarrollo del vida ciclo software (SDLC).
Temprano, en las iteraciones de arquitectura, las pruebas de desempeo se enfocan en identificar y eliminar los cuellos de botella en el desempeo arquitectnico. En las iteraciones de construccin, se llevan a cabo tipos adicionales de pruebas de desempeo y se ejecutan para poner a punto el software y el ambiente (perfeccionando tiempo de la respuesta y recursos), y para verificar que las aplicaciones y sistema se manejan adecuadamente con la carga alta y en condiciones de tensin, como un nmeros grandes de transacciones, clientes y / o volmenes de datos.

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Prueba de Desempeo

Incluye los siguientes tipos de pruebas:
La Prueba de Referencia (Benchmark testing): compara el desempeo del nuevo o desconocido blanco de prueba a una referencia conocida normal como software existente o medidas La prueba de Contencin (Contention test): Verifica que el blanco de la prueba puede manejar mltiple demandas del actor aceptablemente sobre los mismos recursos (grabar datos, memoria, etc.). El Perfil de Desempeo (Performance profiling): Verifica la aceptabilidad del desempeo del comportamiento del blanco de prueba usando condiciones variantes mientras las condiciones operacionales permanecen constantes. La comprobacin de carga (Load testing): Verifica la aceptabilidad del desempeo del comportamiento del blanco de prueba variando las condiciones operacionales (como el nmero de usuarios, nmero de transacciones, y as sucesivamente) mientras la configuracin permanece constante.
TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Prueba de Desempeo

Incluye los siguientes tipos de pruebas:
La comprobacin de tensin (Stress testing): Verifica la aceptabilidad del desempeo del comportamiento del blanco de prueba cuando se encuentran las condiciones anormales o extremas, como recursos disminuidos o el nmero sumamente alto de usuarios. La evaluacin del desempeo normalmente se realiza junto con el representante del Usuario y se hace en un acercamiento multi-nivelado. El primer nivel de anlisis involucra la evaluacin de los resultados para un solo actor o caso de uso y la comparacin de resultados por algunos pruebas de ejecucin. Por ejemplo, capturando la conducta de la actuacin de un solo actor que realiza un solo caso del uso sin cualquier otra actividad en el blanco-de-prueba, y comparando los resultados con varias otras ejecuciones de la prueba del mismo actor o caso del uso. Este anlisis de primer nivel puede ayudar a identificar tendencias que pueden indicar si hay disputa entre recursos del sistema que pueden afectar la validez de las conclusiones deducidas de otros resultados de la prueba de desempeo.
TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Prueba de Desempeo

Un segundo nivel de anlisis examina los sumarios de estadsticas y los valores de los datos actuales para un actor especfico o ejecucin de un caso de uso y la conducta de la actuacin del blanco de prueba. Los sumarios de estadsticas incluyen desviaciones normales y distribuciones del percentil durante los tiempos de respuesta que proporcionan una indicacin de la variabilidad en las respuestas del sistema vistos por los actores individuales.
Un tercer nivel de anlisis puede ayudar entender las causas e importancias de problemas de desempeo. Esto anlisis detallado toma los datos de bajo nivel y usos los mtodos estadsticos para ayudar a los verificadores a deducir las conclusiones correctas de los datos. El anlisis detallado mantiene objetivo y el criterio cuantitativo tomando las decisiones, pero es ms tiempo consumiendo y requiere un entendiendo bsico de estadsticas. El anlisis detallado usa el concepto de importancia estadstica para ayudar a entender cuando diferencias en la conducta del desempeo es real o debido a algn evento aleatorio asociado con la coleccin de datos de prueba. La idea es que en un nivel fundamental, hay aleatoriedad asociada con cualquier evento. Las pruebas estadsticas determina si hay una diferencia sistemtica que no puede explicarse por los eventos aleatorios.
TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Calidad del Producto

La calidad del producto es la calidad del producto a producirse por el proceso. En el desarrollo del software el producto es la agregacin de muchos artefactos, incluyendo:
Desplegado, el cdigo ejecutable (la aplicacin, el sistema, etc.), quizs el ms visible de los artefactos, es el producto primario que proporciona el valor al cliente (los usuarios finales, accionistas, el stakeholders, etc.) Los artefactos no ejecutables desplegados, incluso los artefactos como los manuales del usuario y materiales del curso. El ejecutables no desplegado, como el juego implementacin de artefactos incluyendo los scripts de la prueba y herramientas de desarrollo creadas para apoyar la implementacin. No desplegado, artefactos no ejecutables como los planes de implementacin, planes de prueba, y los varios modelos. Muchos de estos artefactos son basados en otros, la calidad de todos los artefactos est hasta cierto punto relacionada. Por esta razn, debe medirse la calidad de cada artefacto y evaluarse.
TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Calidad del Producto

La Calidad del Producto en Ejecutables (desplegado o no desplegado):
Los artefactos ejecutables se describen por sus requisitos, declarados como casos de uso o los requisitos suplementarios (como comercializar, desempeo, etc.). Para medir y lograr la calidad, estos requisitos deben conocerse y deben declararse de una manera clara, concisa, y comprobable (el testable). Para el software, no todos los requerimientos sern el blanco de prueba para un rol de Probador, (como penetracin del mercado o rdito de las ventas). Para aqullos que sern el blanco de prueba, un diseador de la prueba debe ser capaz de especificar un mtodo para verificar que el requisito se ha logrado (como declarado), no se desve de su intento, y est sin la falla.

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Calidad del Producto

La Calidad del Producto en Ejecutables (desplegado o no desplegado):
La Calidad del producto es determinada midiendo las siguientes dimensiones de calidad y evaluando el logro de los productos para estas dimensiones: La fiabilidad: la resistencia de los cdigos desplegados al fracaso (golpes, colgado, fallas de memoria, etc.) durante la ejecucin. La funcin: el cdigo desplegado ejecuta lo requerido por el caso de uso El desempeo: el cdigo desplegado ejecuta y responde de una manera oportuna y aceptable y contina un desempeo aceptablemente cuando esta sujet a las caractersticas operacionales del mundo real, como la carga, tensin, y los perodos de largo funcionamiento.

Para cada uno de estas dimensiones, uno o mas tipos individuales de prueba debe llevarse a cabo y debe ejecutarse durante uno o ms fases diferentes de prueba.

Adicionalmente, la calidad del producto es evaluada midiendo el nmero y tipos de cambios que se hacen al artefacto ejecutable para cada nueva versin del artefacto.
TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Calidad del Producto

La Calidad del Producto en No Ejecutables (desplegado o no desplegado):
La calidad del producto de un no ejecutables es descrita por el propsito de los artefactos, su meta, y estructura y se evala asegurando que los artefactos logran lo siguiente: La consistencia interior dentro y entre los artefactos (el uso del idioma, terminologa, la semntica, etc.). La complacencia de las pautas, normas, y los requisitos contractuales (el uso del idioma, terminologa, la semntica, el formato, el volumen, etc.)

Adicionalmente, la calidad del producto no ejecutable es evaluada por el nmero y tipo de cambios hechos entre las versiones del artefacto.

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Etapas de las Pruebas

Probar normalmente se aplica a los tipos diferentes de blancos en las fases diferentes del ciclo de la entrega del software. Estas fases progresan desde probar los componentes pequeos (pruebas de unidad) hasta probar los sistemas completos (pruebas de sistema).
Pruebas de Unidad La prueba de la unidad, llevada a cabo temprano en la iteracin, se enfoca en verificar los elementos ms pequeos del software. La prueba de unidad se aplica tpicamente a los componentes en modelo de implementacin para verificar que el flujo de control y el flujo de los datos es cubierto y funciona como es esperado. Estas expectativas son basado en cmo el componente participa ejecutando un caso de uso, esto se hace a travs de un diagrama de secuencia para ese caso de uso. El Implementador realiza la prueba de la unidad en lo que la unidad se desarrolla.

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Tipos de Prueba

Probar, es mucho ms que probar el software a travs de las funciones, la interfaz, y caractersticas de tiempo de respuesta. Las pruebas adicionales deben enfocarse en las caractersticas / los atributos como:
La integridad (la resistencia a fallas) La habilidad para ser instalado / ejecutado en las diferentes plataformas La habilidad de manejar muchas demandas simultneamente Para lograr esto, muchas pruebas diferentes son implementadas y ejecutadas, cada una con un objetivo de prueba especfico. Cada uno enfocado en probar slo una caracterstica o atributo. A menudo las pruebas individuales se categorizan, se implementan, y se ejecutan en grupos, la mayora normalmente colocado por las similitudes en los objetivos de la prueba o la dimensin de calidad ellos se dirigen, como:

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Etapas de las Pruebas

Dimensin de la Calidad: Funcionalidad
La prueba de funcin: Pruebas enfocadas en verificar que el blanco de prueba funciona como es debido, mientras es proporcionado el servicio(s) requerido, metodo(s), o caso(s) de uso. Esta prueba se lleva a cabo y se ejecuta contra blanco-de-prueba diferentes, incluso las unidades, las unidades integradas, aplicacion(es), y sistemas. La prueba de seguridad: Pruebas enfocadas en asegurar el blanco-de-prueba, los datos, (o sistemas) es accesible a slo esos actores pensados. Esta prueba son implementadas y ejecutadas el varios blanco-de-prueba. La prueba de volumen: Prueba enfocada en verificar la habilidad del blanco-deprueba de manejar grandes cantidades de datos, as como la entrada y rendimiento dentro de la base de datos. Esta prueba incluye las estrategias de la prueba como crear consultas que pueden retornar los volmenes enteros de la base de datos, o tiene tantas restricciones que ningn datos ha sido devuelto, o entrada de los datos de la cantidad mxima de datos en cada campo.
TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Etapas de las Pruebas

Dimensin de la Calidad: Usabilidad
Pruebas de Usabilidad: enfocada en: Factores Humanos Esttica la consistencia en la interfaz del usuario (vea las Pautas: La usuario-interfaz) la ayuda en lnea y contexto-sensible los wizards y agentes la documentacin del usuario los materiales de entrenamiento

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Etapas de las Pruebas

Dimensin de la Calidad: Confiabilidad
La prueba de integridad: Pruebas que enfocan en evaluar la robustez del blancode-prueba (la resistencia a fallas) y complacencia tcnica al idioma, sintaxis, y uso del recurso. Esta prueba se lleva a cabo y se ejecutan contra los blanco-de-prueba diferentes, incluso las unidades e integracin de las unidades. La prueba de la estructura: Pruebas que enfocan en evaluar la adhesin del blanco-de-prueba a su diseo y formacin. Tpicamente, esta prueba se hace para aplicaciones web que aseguran que todos los links se conectan, el volumen apropiado se despliega, y no hay ningn hurfano. La prueba de tensin: Un tipo de prueba de fiabilidad que enfoca en asegurar las funciones del sistema cuando se encuentran las condiciones anormales. Las tensiones en el sistema pueden incluir trabajos extremos, la memoria insuficiente, los servicios no disponible / el hardware, o disminucin los recursos compartido. Tpicamente, estas pruebas se realizan para determinar cuando el sistema se cae, y cmo se cae.
TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Etapas de las Pruebas

Dimensin de la Calidad: Desempeo
La Prueba de Referencia (Benchmark testing): compara el desempeo del nuevo o desconocido blanco de prueba a una referencia conocida normal como software existente o medidas. La Prueba de Contencin (Contention test): Verifica que el blanco de la prueba puede manejar mltiple demandas del actor aceptablemente sobre los mismos recursos (grabar datos, memoria, etc.). El Perfil de Desempeo (Performance profiling): Verifica la aceptabilidad del desempeo del comportamiento del blanco de prueba usando condiciones variantes mientras las condiciones operacionales permanecen constantes.

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Etapas de las Pruebas

Dimensin de la Calidad: Desempeo
La Comprobacin de Carga (Load testing): Verifica la aceptabilidad del desempeo del comportamiento del blanco de prueba variando las condiciones operacionales (como el nmero de usuarios, nmero de transacciones, y as sucesivamente) mientras la configuracin permanece constante. La Comprobacin de Tensin (Stress testing): Verifica la aceptabilidad del desempeo del comportamiento del blanco de prueba cuando se encuentran las condiciones anormales o extremas, como recursos disminuidos o el nmero sumamente alto de usuarios.

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Etapas de las Pruebas

Dimensin de la Calidad: Supportability
Prueba de configuracin: Pruebas enfocadas en asegurar q el software funciona sobre diferente hardware y / o configuraciones del software. Esta prueba tambin puede llevarse a cabo como una prueba de desempeo del sistema. Prueba de instalacin: Pruebas enfocadas en asegurar la instalacin en diferente hardware y / o configuraciones del software y bajo condiciones diferentes (como espacio del disco insuficiente o interrupcin de poder). Esta prueba es implementada y ejecutada contra la aplicacin(es) y sistemas.

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Pruebas de Usabilidad

Las pruebas de usabilidad evalan el sistema desde la perspectiva del usuario final. Incluye los siguientes tipos de prueba:
Factores Humanos Estetica Consistencia de la IU Ayudas en linea y sensitivas al contexto wizards y agentes, documentacin del usuario materiales de entrenamiento

Las pruebas de usabilidad no sustituyen a un buen diseo y es mas efectiva cuando se combinan con el Diseo Centrado al Usuario.
Las pruebas de usabilidad comienzan temprano. Los usuarios van probando desde etapas tempranas el prototipo.

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Pruebas de Usabilidad

Probando las Interfaces de Usuario
Es inmensamente importante exponer la GUI a otros. Como el diseo y la implementacin de la interfaz progresa, usted expone el diseo a numerosos crticos para su revisin: Otros miembros del proyecto Expertos en usabilidad externos Usuarios Exponiendo el Diseo a Otros Miembros del Proyecto

sta es una manera infravalorada de exponer el diseo. Tiene un tiempo de repunte muy rpido: los miembros del proyecto ya estn familiarizados con la aplicacin, y ellos estn normalmente disponibles para una sesin espontnea de usabilidad con tremenda ceremonia o formalidad. Diseadores de la interfaz de usuario deben hacer esto continuamente durante la actividad de diseo, para as involucrar a los usuarios y descubrir defectos.

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Pruebas de Usabilidad

Exponiendo el Diseo a los Expertos en Usabilidad Externos
Un experto en usabilidad puede ayudar reducir el esfuerzo de desarrollo sealando las fallas de usabilidad comunes, y normalmente ofrecer otras perspectivas en la interfaz del usuario basada en la experiencia. Puede ser as de valor involucrar a los expertos de usabilidad externos ms temprano en el trabajo de diseo de la interfaz de usuario para que usted tenga el tiempo suficiente para mejorar el diseo al incorporar sus recomendaciones. Esto debe hacerse muy a menudo para ganar la aprobacin de los stakeholders y para corregir cualquier mala interpretacin de las necesidades. Esto o puede ocurrir durante la captura de los requisitos o el diseo de la interfaz de usuario. Donde sea posible, evite exponer al mismo usuario la interfaz ms de una vez; la segunda vez q lo haga, el usuario se corromper por sus ideas del diseo ms tempranas y como tal el valor de la actividad es disminuida.

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Pruebas de Usabilidad

Exponiendo el Diseo a los Usuarios
El acceso a los usuarios est a menudo limitado, merece la pena cuando la oportunidad se da de presentar el diseo a estos. Haga esto tan a menudo como el requisito gane el stakeholders' la aprobacin y para corregir cualquier mala interpretacin de los accionistas. Esto o puede ocurrir durante los requisitos capture o plan de la usuario-interfaz. Donde posible, evite exponer al mismo usuario ms de una vez a la interfaz; el segundo tiempo, el usuario se corromper por sus ideas del plan ms tempranas (similar a la "ceguedad de la casa"), y como a tal el valor de la actividad se disminuye.

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Pruebas de Usabilidad

Cmo Exponer el Diseo
Una manera de exponer un diseo de interfaz de usuario es tener un analista de negocio o de sistema se siente junto con el usuario final, delante de una pantalla u otro medio que muestre la interfaz. Chequee escenarios comunes, por ejemplo, revise el flujo bsico de un caso de uso con los valores tpicos, como esta descrito en el storyboard del caso de uso. Anime a la persona a hacer preguntas y dar comentarios. El desafo con este acercamiento es asegurar que la informacin obtenida es tan imparcial como es posible. Tome tantas notas como usted pueda: si es posible, tenga alguien ms hacer esto para no interrumpir el flujo natural de los usuarios. Otra manera de exponer el diseo de la interfaz de usuario es realizar las pruebas de uso, a menudo dirigidas como un laboratorio o taller con representantes de la comunidad de usuarios finales.

En una prueba de uso, los usuarios reales realizan las tareas reales con la interfaz, conjuntamente con el personal de desarrollo de software que toma un papel de observador pasivo.
TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Pruebas de Usabilidad

Cmo Exponer el Diseo
Mucho puede ganarse con este tipo de pruebas de usabilidad, sin embargo hay varios desafos que deben enfrentarse y se debe conseguir fiabilidad, y resultados econmicos: Como una regla general, esta acometida tiene mayor valor cuando la comunidad del usuario final es grande, variada y tiene un gran grado de control sobre su seleccin de sistema del software. Con la presencia de estos factores, el riesgo de no realizar la prueba de uso incrementa. A menudo el mayor el valor de realizar estas pruebas, lo ms duro es obtener el acceso a, coordinar y manejar esta actividad con el usuario final. Es importante identificar los modelos de uso ms comunes, descontando los resultados excepcionales, para asegurar que las decisiones de diseo de la interfaz de usuario son basado en las necesidades de la mayora.

TOPICOS II

DISCIPLINA DE PRUEBA

Conceptos: Pruebas de Usabilidad

Cmo Exponer el Diseo
Donde los usuarios finales emigran de un sistema existente a un nuevo sistema, ellos estn a menudo interesados que el nuevo sistema proporcionar menos funcionalidad de la que es proporcionada por el viejo. Desgraciadamente, este problema raramente se levanta directamente, y es a menudo es disimulado por comentarios como "Yo quiero que el nuevo sistema luzca y se sienta exactamente igual al sistema existente" Donde un cambio significante en la tecnologa est proponindose a una comunidad de usuarios finales, puede ser necesario proporcionar el entrenamiento en el uso bsico de la tecnologa antes de obtener valor significante con la prueba de uso. Por ejemplo, los usuarios de sistema actual pueden no haber tenido experiencia anterior usando un ratn o trabajando con una GUI. Cada equipo del proyecto necesita considerar estos desafos contra el nico ambiente del proyecto en el cual ellos estn trabajando, y llega al cronometrar apropiadamente, el mtodo y la acometida para la prueba de usabilidad.
TOPICOS II