DISCIPLINA DE PRUEBA

PRUEBAS
Propósito
• Para verificar la interacción entre los objetos • Para verificar la integración 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
Propósito
En muchas organizaciones, las prueba de software abarcan del 30 al 50 por ciento de los costos de desarrollo de software. Todavía la mayoría de las personas cree que el software no se prueba bien antes de que se entregue. Esta contradicción está arraigada en dos hechos claros.

Primero, las pruebas de software son enormemente difíciles. Las diferentes maneras que un programa dado puede comportarse son incuantificables.
Segundo, las pruebas se realizan sinuna metodología clara y sin la automatización requerida o apoyo de herramienta. Mientras la complejidad del software hace la comprobación completa una meta imposible, una metodología bien concebida y el uso de herramientas innovadoras, puede mejorar la productividad y efectividad de la comprobación del software grandemente.
TOPICOS II

DISCIPLINA DE PRUEBA

PRUEBAS
Propósito
Para sistemas de "seguridad crítica" dónde un fracaso puede dañar a personas (como el control de tráfico aéreo, guía de proyectiles, o los sistemas de entrega médica), software con calidad superior es esencial para el éxito del sistema producido. Para un sistema de MIS típico, esta situación 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, bajarán el costo de completar y mantener el software significativamente.

También 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 cálculo, y conducta funcional inaceptable.
TOPICOS II

DISCIPLINA DE PRUEBA

PRUEBAS
Propósito
Hoy día, muchos sistema de MIS son de "misión crítica", esto significa, que las compañías no pueden cumplir sus funciones y experimentan pérdidas masivas cuando las fallas ocurren. Por ejemplo: los bancos, o compañías de transporte. Deben probarse los sistemas de misión-crítica usando los mismos acercamientos rigurosos usados para los sistemas de seguridad-críticos.

TOPICOS II

DISCIPLINA DE PRUEBA Requerimientos TOPICOS II .

DISCIPLINA DE PRUEBA Requerimientos: Actividades TOPICOS II .

DISCIPLINA DE PRUEBA Requerimientos: Artefactos TOPICOS II .

primero cuando el sistema se integra. TOPICOS II .DISCIPLINA DE PRUEBA PRUEBA Relación 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 Análisis y Diseño describe cómo desarrollar un diseño. La disciplina de Administración de proyecto. como las Pautas de la Prueba. La disciplina de Ambiente desarrolla y mantiene artefactos de apoyo que se usan durante la prueba. La disciplina de Implementación produce construcciones del modelo de implementación que se prueban. Dentro de una iteración hay varias construcciones probadas. y por último se debe probar el sistema entero. planea el proyecto y cada iteración (descrito en un Plan de la Iteración). ésta es la otra entrada primaria por identificar qué pruebas se deben realizar.

Hay tres estrategias comunes para llevar a cabo una prueba de aceptación. 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. TOPICOS II .DISCIPLINA DE PRUEBA Conceptos: Pruebas de Aceptación La Prueba de aceptación es la acción de prueba final prioritaria para desplegar el software. y el dominio de la aplicación. normas de la organización y corporativas. Ellas son: Aceptación Formal Aceptación Informal o Pruebas Alfa Pruebas Beta La estrategia que se selecciona es a menudo basada en los requisitos contractuales.

la prueba de aceptación es completamente realizada por los usuarios finales de la organización. o un grupo objetivo de personas escogido por los usuarios finales. En muchas organizaciones. con los representantes de la organización del usuario final. Las actividades y artefactos son iguales que para la prueba del sistema. realizan la prueba de aceptación. En otras organizaciones. la organización de desarrollo (o su grupo de la prueba independiente). Las pruebas se planean y diseñan cuidadosamente y en el mismo detalle como la comprobación del sistema. TOPICOS II .DISCIPLINA DE PRUEBA Conceptos: Pruebas de Aceptación Pruebas Formales de Aceptación La prueba de aceptación formal es un proceso altamente manejado y es a menudo una extensión de la prueba del sistema. En algunas organizaciones. Es importante no desviarse de forma alguna de los casos de la prueba escogidos. las pruebas de aceptación formales son totalmente automatizadas. Los casos de prueba escogidos debe ser un subconjunto de aquéllos realizado en la prueba del sistema.

• Los detalles de las pruebas son conocidos y pueden medirse. debido a que usted sólo está buscando defectos que usted espera encontrar.DISCIPLINA DE PRUEBA Conceptos: Pruebas de Aceptación Pruebas Formales de Aceptación Los beneficios son: • Las funciones y características a ser probado son conocidos. • No puede descubrir los defectos subjetivos en el software. • Las pruebas pueden automatizarse. lo que permite la regresión de pruebas. TOPICOS II . • Las pruebas pueden ser una re-aplicación de pruebas del sistema. • El progreso de las pruebas puede medirse y puede supervisarse. • El criterio de aceptabilidad es conocido. Las desventajas incluyen: • Requiere los recursos significantes y planificación.

los procedimientos de prueba para realizar la prueba no son rigurosamente definidos en cuanto a la comprobación de aceptación formal. La prueba de aceptación informal frecuentemente es en su mayoría realizado por los usuarios finales de la organización. Se identifican las funciones y las tareas de negocio son exploradas y documentadas. Esta acometida de prueba de aceptación no es tan controlada como la prueba formal y es más subjetiva. El encargado de las pruebas determina qué hacer. TOPICOS II . pero no hay ningún caso de prueba particular para seguir.DISCIPLINA DE PRUEBA Conceptos: Pruebas de Aceptación Pruebas Informales de Aceptación En la prueba de aceptación informal.

• El progreso de las pruebas puede medirse y puede supervisarse. • Usted descubrirá los defectos más subjetivos que con la prueba de aceptación formal. • Los usuarios finales pueden enfocarse en comparar el nuevo sistema con el sistema anterior. • El criterio de aceptabilidad es conocido. • Usted no tiene ningún control sobre que casos de prueba se usan. planificación. Las desventajas: • Se requieren recursos. • Los usuarios finales pueden enfocarse sobre la manera que el sistema trabaja y no ver los defectos. y administración de recursos. TOPICOS II .DISCIPLINA DE PRUEBA Conceptos: Pruebas de Aceptación Pruebas Informales de Aceptación Los beneficios son: • Las funciones y rasgos a ser probado son conocidos. en lugar de buscar los defectos. • Los recursos para las pruebas de aceptación no están bajo el control del proyecto y pueden ser restringidas.

En las pruebas beta. Cada verificador es responsable por identificar su propio criterio para determinar si aceptar el sistema en su estado actual o no. la cantidad de detalle. a menudo con una pequeña o ninguna dirección del desarrollo (u otro no usuario final) la organización. Cada verificador es responsable de crear su propio ambiente. los datos. o tareas va a explorar. características. Las pruebas beta se llevan a cabo por los usuarios finales. seleccionar sus datos. y la acometida tomada depende completamente del personal de prueba. y determinar qué funciones. TOPICOS II . La prueba beta es la más subjetiva de todas las estrategias de prueba de aceptación.DISCIPLINA DE PRUEBA Conceptos: Pruebas de Aceptación Pruebas Beta Las pruebas beta son las menos controladas de las tres estrategias de prueba de aceptación.

• Incrementa la satisfacción de los clientes que participan. • Se descubren los defectos más subjetivos que con las pruebas de aceptación formal o informal TOPICOS II .DISCIPLINA DE PRUEBA Conceptos: Pruebas de Aceptación Pruebas Beta Los beneficios son: • La prueba se lleva a cabo por los usuarios finales. • Grandes volúmenes de potenciales recursos de prueba.

• Los usuarios finales pueden verificar a la manera el sistema trabaja y no ver o informar los defectos. • Los recursos para la prueba de aceptación no están bajo el control de proyecto y pueden ser estrechas. • Los usuarios finales pueden enfocarse en comparar el nuevo sistema con el sistema actual. • El criterio de aceptabilidad no es conocido. en lugar de buscar los defectos. • Se necesita incrementar los recursos de apoyo para manejar los verificadores de la beta TOPICOS II . • El progreso de la prueba es difícil medir.DISCIPLINA DE PRUEBA Conceptos: Pruebas de Aceptación Pruebas Beta Las desventajas: • No todas las funciones y / o características pueden probarse.

La calidad es una medida de fiabilidad. o por la cobertura del código ejecutado. La cobertura de la prueba esta relacionado con probar la integridad. y esta basado en la cobertura de la prueba. TOPICOS II .DISCIPLINA DE PRUEBA Conceptos: Las claves de medidas para las pruebas Introducción Las medidas importantes de una prueba incluyen cobertura y calidad. y desempeño de objetivo de la prueba (sistema o aplicación bajo prueba). o expresado por la cobertura de los requisitos de prueba y los casos de prueba. La Calidad es basada en la evaluación de los resultados de las pruebas y el análisis de demandas de cambio (los defectos) identificados durante la prueba. estabilidad.

la prueba de cobertura es cualquier medida de integridad con respecto a un requisito (basado en requisitos) o el diseño de código o criterios de implementación (basado en código). Cualquier actividad de prueba sistemática es basada en por lo menos una estrategia de prueba de cobertura.DISCIPLINA DE PRUEBA Conceptos: Las claves de medidas para las pruebas Medidas de Cobertura El métrica 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 código. La estrategia de cobertura guía el diseño de los casos de prueba declarando el propósito general de la comprobación. La declaración de estrategia de cobertura puede ser tan simple como verificar todo el desempeño. En el informe. TOPICOS II . como la verificación de los casos de uso (basado en requisitos) o ejecución de todas las líneas de código (basado en código).

como el 75 por ciento de los requisitos de prueba de desempeño se han verificado. Ambas medidas pueden ser derivadas manualmente o pueden ser calculadas por herramientas de pruebas automatizadas. se formulan las estrategias en términos de cuanto del código de fuente se ha ejecutado por las pruebas. Por ejemplo. una estrategia de cobertura basada en requisitos puede ser suficiente para obtener una medida cuantificable para probar la integridad. entonces los resultados de la prueba pueden ser los referenciados para conseguir las medidas. Este tipo de estrategia de prueba de cobertura es muy importante para los sistemas de seguridad-crítica. TOPICOS II . Si una prueba de cobertura basada en código es aplicada.DISCIPLINA DE PRUEBA Conceptos: Las claves de medidas para las pruebas Medidas de Cobertura Si los requisitos son completamente catalogados. si todos los requisitos de prueba de desempeño se han identificado.

DISCIPLINA DE PRUEBA Conceptos: Las claves de medidas para las pruebas Medidas de Calidad Mientras la evaluación de la prueba de cobertura proporciona la medida de probar la realización. La evaluación de defecto puede ser basada en métodos que van desde simples defectos al modelo estadístico riguroso. hay normalmente cuatro parámetros usados: El estado el estado actual del defecto (abre. El análisis de defecto proporciona una indicación de la fiabilidad del software. TOPICOS II . La prioridad de la relativa importancia de este defecto que tiene que ser manejado y resuelto. una evaluación de defectos descubiertos durante la prueba proporciona la mejor indicación de calidad del software. Para el análisis del defecto. los defectos se identifican como un tipo de demanda de cambio. El análisis de los defectos significa analizar la distribución de defectos sobre los valores de uno o más parámetros asociados con un defecto. cerrado. La calidad es la indicación de cuan bien el software reúne los requisitos. en ese contexto.). etc. mientras siendo fijo.

El impacto al usuario final. La fuente dónde y qué origina la falla que produce este defecto. etc. terceras partes. en un informe de Densidad de Defecto. respectivamente. como severidad o estado. Es un elemento clave a determinar Las cuentas de Defectos pueden informarse como una función de tiempo. pueden informarse las cuentas del defecto como una función de uno o más parámetros del defecto.. una organización. o qué componente se arreglará para eliminar el defecto. Estos tipos de análisis proporcionan una perspectiva en las tendencias o distribución de defectos que revelan la fiabilidad del software. creando un diagrama de Tendencia de Defecto o un reporte. TOPICOS II .DISCIPLINA DE PRUEBA Conceptos: Las claves de medidas para las pruebas Medidas de Calidad La severidad del impacto relativo de este defecto.

DISCIPLINA DE PRUEBA Conceptos: Las claves de medidas para las pruebas Medidas de Calidad Los defectos incluidos en un análisis de este tipo tienen que ser defectos confirmados. No todos los defectos reportados informan una falla real. TOPICOS II . Sin embargo. hay valores que buscar y analizar porque hay muchos defectos siendo reportados pueden estar duplicados o no ser defectos confirmados. algunos puede ser un requerimiento de mejora. fuera del alcance del proyecto. o describe un defecto ya reportado.

Principalmente. estas medidas se evalúan en la actividad Evaluación de la Prueba. fiabilidad operacional y límites. flujo de la ejecución. TOPICOS II . perfiles de tiempo. hay medidas de desempeño que son usadas durante la actividad Ejecución de la Prueba para evaluar el estado y progreso de la prueba. sin embargo.DISCIPLINA DE PRUEBA Conceptos: Las claves de medidas para las pruebas Medidas de Desempeño Varias medidas son usadas para evaluar las conductas de desempeño del blanco de prueba y enfocadas en capturar datos relacionados a las conductas como tiempo de respuesta.

medida del percentil / el cálculo de los valores recolectados de datos Reporte de Comparación .captura en tiempo real y despliegue del estatus y el estado de cada prueba ejecutada durante la ejecución de la prueba.diferencias o tendencias entre dos (o más) juegos de datos que representan las diferentes ejecuciones de prueba.los detalles de los mensajes / las conversaciones entre el actor y el blanco de prueba.la medida de el tiempo de respuesta o throughput del blanco-de-prueba para los actores especificados. El tiempo de respuesta / Throughput . El Reporte Percentil . Los Reporte de Rastro .DISCIPLINA DE PRUEBA Conceptos: Las claves de medidas para las pruebas Medidas de Desempeño Las medidas de desempeño primarias incluyen: El monitoreo dinámico . y / o los casos de uso. TOPICOS II .

Los diferentes tipos de pruebas de desempeño. como un números grandes de transacciones. cada uno es enfocada en un objetivo de prueba diferente. y para verificar que las aplicaciones y sistema se manejan adecuadamente con la carga alta y en condiciones de tensión. en las iteraciones de arquitectura. Temprano. y fiabilidad operacional y límites. las pruebas de desempeño se enfocan en identificar y eliminar los cuellos de botella en el desempeño arquitectónico. En las iteraciones de construcción. se llevan a cabo tipos adicionales de pruebas de desempeño y se ejecutan para poner a punto el software y el ambiente (perfeccionando tiempo de la respuesta y recursos). el tiempo de respuesta. clientes y / o volúmenes de datos. que se lleva a cabo a lo largo del desarrollo del vida ciclo software (SDLC). TOPICOS II . el flujo de la ejecución.DISCIPLINA DE PRUEBA Conceptos: Prueba de Desempeño La Prueba de Desempeño es una clase de pruebas llevada a implementadas y ejecutadas para caracterizar y evaluar el desempeño relacionado con las características del objetivo de la prueba como son los perfiles de tiempo.

TOPICOS II . La comprobación de carga (Load testing): Verifica la aceptabilidad del desempeño del comportamiento del blanco de prueba variando las condiciones operacionales (como el número de usuarios. etc. memoria. y así sucesivamente) mientras la configuración permanece constante.DISCIPLINA DE PRUEBA Conceptos: Prueba de Desempeño Incluye los siguientes tipos de pruebas: La Prueba de Referencia (Benchmark testing): compara el desempeño del nuevo o desconocido blanco de prueba a una referencia conocida normal como software existente o medidas La prueba de Contención (Contention test): Verifica que el blanco de la prueba puede manejar múltiple demandas del actor aceptablemente sobre los mismos recursos (grabar datos.). El Perfil de Desempeño (Performance profiling): Verifica la aceptabilidad del desempeño del comportamiento del blanco de prueba usando condiciones variantes mientras las condiciones operacionales permanecen constantes. número de transacciones.

DISCIPLINA DE PRUEBA Conceptos: Prueba de Desempeño Incluye los siguientes tipos de pruebas: La comprobación de tensión (Stress testing): Verifica la aceptabilidad del desempeño del comportamiento del blanco de prueba cuando se encuentran las condiciones anormales o extremas. Por ejemplo. La evaluación del desempeño normalmente se realiza junto con el representante del Usuario y se hace en un acercamiento multi-nivelado. El primer nivel de análisis involucra la evaluación de los resultados para un solo actor o caso de uso y la comparación de resultados por algunos pruebas de ejecución. TOPICOS II . y comparando los resultados con varias otras ejecuciones de la prueba del mismo actor o caso del uso. como recursos disminuidos o el número sumamente alto de usuarios. Este análisis 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 desempeño. capturando la conducta de la actuación de un solo actor que realiza un solo caso del uso sin cualquier otra actividad en el blanco-de-prueba.

TOPICOS II .DISCIPLINA DE PRUEBA Conceptos: Prueba de Desempeño Un segundo nivel de análisis examina los sumarios de estadísticas y los valores de los datos actuales para un actor específico o ejecución de un caso de uso y la conducta de la actuación del blanco de prueba. El análisis detallado mantiene objetivo y el criterio cuantitativo tomando las decisiones. Un tercer nivel de análisis puede ayudar entender las causas e importancias de problemas de desempeño. Los sumarios de estadísticas incluyen desviaciones normales y distribuciones del percentil durante los tiempos de respuesta que proporcionan una indicación de la variabilidad en las respuestas del sistema vistos por los actores individuales. pero es más tiempo consumiendo y requiere un entendiendo básico de estadísticas. Esto análisis detallado toma los datos de bajo nivel y usos los métodos estadísticos para ayudar a los verificadores a deducir las conclusiones correctas de los datos. hay aleatoriedad asociada con cualquier evento. El análisis detallado usa el concepto de importancia estadística para ayudar a entender cuando diferencias en la conducta del desempeño es real o debido a algún evento aleatorio asociado con la colección de datos de prueba. Las pruebas estadísticas determina si hay una diferencia sistemática que no puede explicarse por los eventos aleatorios. La idea es que en un nivel fundamental.

como el juego implementación de artefactos incluyendo los scripts de la prueba y herramientas de desarrollo creadas para apoyar la implementación.). la calidad de todos los artefactos está hasta cierto punto relacionada. el stakeholders. Por esta razón. artefactos no ejecutables como los planes de implementación. TOPICOS II . incluso los artefactos como los manuales del usuario y materiales del curso. quizás el más visible de los artefactos. No desplegado. y los varios modelos.) Los artefactos no ejecutables desplegados. etc. Muchos de estos artefactos son basados en otros. el sistema.DISCIPLINA DE PRUEBA Conceptos: Calidad del Producto La calidad del producto es la calidad del producto a producirse por el proceso. debe medirse la calidad de cada artefacto y evaluarse. En el desarrollo del software el producto es la agregación de muchos artefactos. el código ejecutable (la aplicación. planes de prueba. es el producto primario que proporciona el valor al cliente (los usuarios finales. etc. incluyendo: Desplegado. accionistas. El ejecutables no desplegado.

concisa. Para medir y lograr la calidad. (como penetración del mercado o rédito de las ventas). desempeño. no todos los requerimientos serán el blanco de prueba para un rol de Probador. Para aquéllos que serán el blanco de prueba. declarados como casos de uso o los requisitos suplementarios (como comercializar. y está sin la falla. un diseñador de la prueba debe ser capaz de especificar un método para verificar que el requisito se ha logrado (como declarado). estos requisitos deben conocerse y deben declararse de una manera clara. Para el software. etc. y comprobable (el testable). no se desvíe de su intento.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.). TOPICOS II .

TOPICOS II . etc. La función: el código desplegado ejecuta lo requerido por el caso de uso El desempeño: el código desplegado ejecuta y responde de una manera oportuna y aceptable y continúa un desempeño aceptablemente cuando esta sujetó a las características operacionales del mundo real. tensión. Adicionalmente. colgado. Para cada uno de estas dimensiones. fallas de memoria. como la carga.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 códigos desplegados al fracaso (golpes. y los períodos de largo funcionamiento. la calidad del producto es evaluada midiendo el número y tipos de cambios que se hacen al artefacto ejecutable para cada nueva versión del artefacto.) durante la ejecución. uno o mas tipos individuales de prueba debe llevarse a cabo y debe ejecutarse durante uno o más fases diferentes de prueba.

terminología. terminología. su meta. la semántica.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 propósito de los artefactos. TOPICOS II .) Adicionalmente. el volumen.). y los requisitos contractuales (el uso del idioma. el formato. la semántica. y estructura y se evalúa asegurando que los artefactos logran lo siguiente: • • La consistencia interior dentro y entre los artefactos (el uso del idioma. etc. etc. normas. la calidad del producto no ejecutable es evaluada por el número y tipo de cambios hechos entre las versiones del artefacto. La complacencia de las pautas.

Pruebas de Unidad La prueba de la unidad. esto se hace a través de un diagrama de secuencia para ese caso de uso. TOPICOS II . llevada a cabo temprano en la iteración. La prueba de unidad se aplica típicamente a los componentes en modelo de implementación para verificar que el flujo de control y el flujo de los datos es cubierto y funciona como es esperado. El Implementador realiza la prueba de la unidad en lo que la unidad se desarrolla. Estas expectativas son basado en cómo el componente participa ejecutando un caso de uso.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. se enfoca en verificar los elementos más pequeños del software. Estas fases progresan desde probar los componentes pequeños (pruebas de unidad) hasta probar los sistemas completos (pruebas de sistema).

la mayoría normalmente colocado por las similitudes en los objetivos de la prueba o la dimensión de calidad ellos se dirigen. muchas pruebas diferentes son implementadas y ejecutadas. Las pruebas adicionales deben enfocarse en las características / 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 simultáneamente Para lograr esto.DISCIPLINA DE PRUEBA Conceptos: Tipos de Prueba Probar. la interfaz. Cada uno enfocado en probar sólo una característica o atributo. como: TOPICOS II . A menudo las pruebas individuales se categorizan. y se ejecutan en grupos. y características de tiempo de respuesta. es mucho más que probar el software a través de las funciones. cada una con un objetivo de prueba específico. se implementan.

los datos. incluso las unidades. y sistemas. las unidades integradas.DISCIPLINA DE PRUEBA Conceptos: Etapas de las Pruebas Dimensión de la Calidad: Funcionalidad La prueba de función: Pruebas enfocadas en verificar que el blanco de prueba funciona como es debido. Esta prueba son implementadas y ejecutadas el varios blanco-de-prueba. TOPICOS II . Esta prueba se lleva a cabo y se ejecuta contra blanco-de-prueba diferentes. Esta prueba incluye las estrategias de la prueba como crear consultas que pueden retornar los volúmenes enteros de la base de datos. o tiene tantas restricciones que ningún datos ha sido devuelto. o caso(s) de uso. La prueba de volumen: Prueba enfocada en verificar la habilidad del blanco-deprueba de manejar grandes cantidades de datos. (o sistemas) es accesible a sólo esos actores pensados. La prueba de seguridad: Pruebas enfocadas en asegurar el blanco-de-prueba. así como la entrada y rendimiento dentro de la base de datos. o entrada de los datos de la cantidad máxima de datos en cada campo. metodo(s). mientras es proporcionado el servicio(s) requerido. aplicacion(es).

DISCIPLINA DE PRUEBA Conceptos: Etapas de las Pruebas Dimensión de la Calidad: Usabilidad Pruebas de Usabilidad: enfocada en: • Factores Humanos • Estética • la consistencia en la interfaz del usuario (vea las Pautas: La usuario-interfaz) • la ayuda en línea y contexto-sensible • los wizards y agentes • la documentación del usuario • los materiales de entrenamiento TOPICOS II .

La prueba de tensión: Un tipo de prueba de fiabilidad que enfoca en asegurar las funciones del sistema cuando se encuentran las condiciones anormales. incluso las unidades e integración de las unidades. o disminución los recursos compartido.DISCIPLINA DE PRUEBA Conceptos: Etapas de las Pruebas Dimensión de la Calidad: Confiabilidad La prueba de integridad: Pruebas que enfocan en evaluar la robustez del blancode-prueba (la resistencia a fallas) y complacencia técnica al idioma. Típicamente. TOPICOS II . la memoria insuficiente. Típicamente. estas pruebas se realizan para determinar cuando el sistema se cae. los servicios no disponible / el hardware. y cómo se cae. sintaxis. Las tensiones en el sistema pueden incluir trabajos extremos. La prueba de la estructura: Pruebas que enfocan en evaluar la adhesión del blanco-de-prueba a su diseño y formación. Esta prueba se lleva a cabo y se ejecutan contra los blanco-de-prueba diferentes. y uso del recurso. esta prueba se hace para aplicaciones web que aseguran que todos los links se conectan. y no hay ningún huérfano. el volumen apropiado se despliega.

El Perfil de Desempeño (Performance profiling): Verifica la aceptabilidad del desempeño del comportamiento del blanco de prueba usando condiciones variantes mientras las condiciones operacionales permanecen constantes. memoria. La Prueba de Contención (Contention test): Verifica que el blanco de la prueba puede manejar múltiple demandas del actor aceptablemente sobre los mismos recursos (grabar datos.DISCIPLINA DE PRUEBA Conceptos: Etapas de las Pruebas Dimensión de la Calidad: Desempeño La Prueba de Referencia (Benchmark testing): compara el desempeño del nuevo o desconocido blanco de prueba a una referencia conocida normal como software existente o medidas. etc.). TOPICOS II .

y así sucesivamente) mientras la configuración permanece constante. La Comprobación de Tensión (Stress testing): Verifica la aceptabilidad del desempeño del comportamiento del blanco de prueba cuando se encuentran las condiciones anormales o extremas.DISCIPLINA DE PRUEBA Conceptos: Etapas de las Pruebas Dimensión de la Calidad: Desempeño La Comprobación de Carga (Load testing): Verifica la aceptabilidad del desempeño del comportamiento del blanco de prueba variando las condiciones operacionales (como el número de usuarios. TOPICOS II . número de transacciones. como recursos disminuidos o el número sumamente alto de usuarios.

TOPICOS II . Esta prueba también puede llevarse a cabo como una prueba de desempeño del sistema. Prueba de instalación: Pruebas enfocadas en asegurar la instalación en diferente hardware y / o configuraciones del software y bajo condiciones diferentes (como espacio del disco insuficiente o interrupción de poder).DISCIPLINA DE PRUEBA Conceptos: Etapas de las Pruebas Dimensión de la Calidad: Supportability Prueba de configuración: Pruebas enfocadas en asegurar q el software funciona sobre diferente hardware y / o configuraciones del software. Esta prueba es implementada y ejecutada contra la aplicación(es) y sistemas.

DISCIPLINA DE PRUEBA Conceptos: Pruebas de Usabilidad Las pruebas de usabilidad evalúan el sistema desde la perspectiva del usuario final. documentación del usuario materiales de entrenamiento Las pruebas de usabilidad no sustituyen a un buen diseño y es mas efectiva cuando se combinan con el Diseño Centrado al Usuario. Las pruebas de usabilidad comienzan temprano. TOPICOS II . Los usuarios van probando desde etapas tempranas el prototipo. Incluye los siguientes tipos de prueba: Factores Humanos Estetica Consistencia de la IU Ayudas en linea y sensitivas al contexto wizards y agentes.

Tiene un tiempo de repunte muy rápido: los miembros del proyecto ya están familiarizados con la aplicación. para así involucrar a los usuarios y descubrir defectos. y ellos están normalmente disponibles para una sesión espontánea de usabilidad con tremenda ceremonia o formalidad. Como el diseño y la implementación de la interfaz progresa. TOPICOS II . usted expone el diseño a numerosos críticos para su revisión: Otros miembros del proyecto Expertos en usabilidad externos Usuarios Exponiendo el Diseño a Otros Miembros del Proyecto Ésta es una manera infravalorada de exponer el diseño.DISCIPLINA DE PRUEBA Conceptos: Pruebas de Usabilidad Probando las Interfaces de Usuario Es inmensamente importante exponer la GUI a otros. Diseñadores de la interfaz de usuario deben hacer esto continuamente durante la actividad de diseño.

y normalmente ofrecerá otras perspectivas en la interfaz del usuario basada en la experiencia. Esto o puede ocurrir durante la captura de los requisitos o el diseño de la interfaz de usuario. TOPICOS II . la segunda vez q lo haga. el usuario se corromperá por sus ideas del diseño más tempranas y como tal el valor de la actividad es disminuida.DISCIPLINA DE PRUEBA Conceptos: Pruebas de Usabilidad Exponiendo el Diseño a los Expertos en Usabilidad Externos Un experto en usabilidad puede ayudar reducir el esfuerzo de desarrollo señalando las fallas de usabilidad comunes. Puede ser así de valor involucrar a los expertos de usabilidad externos más temprano en el trabajo de diseño de la interfaz de usuario para que usted tenga el tiempo suficiente para mejorar el diseño al incorporar sus recomendaciones. evite exponer al mismo usuario la interfaz más de una vez. Esto debe hacerse muy a menudo para ganar la aprobación de los stakeholders y para corregir cualquier mala interpretación de las necesidades. Donde sea posible.

el segundo tiempo. evite exponer al mismo usuario más de una vez a la interfaz. merece la pena cuando la oportunidad se da de presentar el diseño a estos. Haga esto tan a menudo como el requisito gane el stakeholders' la aprobación y para corregir cualquier mala interpretación de los accionistas. y como a tal el valor de la actividad se disminuye. el usuario se corromperá por sus ideas del plan más tempranas (similar a la "ceguedad de la casa"). Esto o puede ocurrir durante los requisitos capture o plan de la usuario-interfaz.DISCIPLINA DE PRUEBA Conceptos: Pruebas de Usabilidad Exponiendo el Diseño a los Usuarios El acceso a los usuarios está a menudo limitado. Donde posible. TOPICOS II .

Anime a la persona a hacer preguntas y dar comentarios. Otra manera de exponer el diseño de la interfaz de usuario es realizar las pruebas de uso. como esta descrito en el storyboard del caso de uso. tenga alguien más hacer esto para no interrumpir el flujo natural de los usuarios. los usuarios reales realizan las tareas reales con la interfaz. Chequee escenarios comunes. El desafío con este acercamiento es asegurar que la información obtenida es tan imparcial como es posible. En una prueba de uso.DISCIPLINA DE PRUEBA Conceptos: Pruebas de Usabilidad Cómo Exponer el Diseño Una manera de exponer un diseño de interfaz de usuario es tener un analista de negocio o de sistema se siente junto con el usuario final. Tome tantas notas como usted pueda: si es posible. TOPICOS II . delante de una pantalla u otro medio que muestre la interfaz. revise el flujo básico de un caso de uso con los valores típicos. a menudo dirigidas como un laboratorio o taller con representantes de la comunidad de usuarios finales. conjuntamente con el personal de desarrollo de software que toma un papel de observador pasivo. por ejemplo.

Con la presencia de estos factores. y resultados económicos: Como una regla general. TOPICOS II . A menudo el mayor el valor de realizar estas pruebas. coordinar y manejar esta actividad con el usuario final. el riesgo de no realizar la prueba de uso incrementa.DISCIPLINA DE PRUEBA Conceptos: Pruebas de Usabilidad Cómo Exponer el Diseño Mucho puede ganarse con este tipo de pruebas de usabilidad. esta acometida tiene mayor valor cuando la comunidad del usuario final es grande. lo más duro es obtener el acceso a. variada y tiene un gran grado de control sobre su selección de sistema del software. Es importante identificar los modelos de uso más comunes. descontando los resultados excepcionales. sin embargo hay varios desafíos que deben enfrentarse y se debe conseguir fiabilidad. para asegurar que las decisiones de diseño de la interfaz de usuario son basado en las necesidades de la mayoría.

puede ser necesario proporcionar el entrenamiento en el uso básico de la tecnología antes de obtener valor significante con la prueba de uso. Cada equipo del proyecto necesita considerar estos desafíos contra el único ambiente del proyecto en el cual ellos están trabajando. los usuarios de sistema actual pueden no haber tenido experiencia anterior usando un ratón o trabajando con una GUI. TOPICOS II . 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 tecnología está proponiéndose a una comunidad de usuarios finales. Desgraciadamente.DISCIPLINA DE PRUEBA Conceptos: Pruebas de Usabilidad Cómo Exponer el Diseño Donde los usuarios finales emigran de un sistema existente a un nuevo sistema. y llega al cronometrar apropiadamente. Por ejemplo. este problema raramente se levanta directamente. el método y la acometida para la prueba de usabilidad. ellos están a menudo interesados que el nuevo sistema proporcionará menos funcionalidad de la que es proporcionada por el viejo.