Pruebas asociadas a cambios: Repetición de pruebas y pruebas de regresión (K2 - entender, explicar , razonar)

Objetivos:

1. Comparar cuatro tipos de pruebas de software (funcional, no funcional, estructural y asociado al cambio) (K2).
2. Reconocer que las pruebas funcionales y estructurales se llevan a cabo en cualquier nivel de prueba (K1).
3. Identificar y describir los tipos de pruebas no funcionales en base a requisitos no funcionales (K2).
4. Identificar y describir los tipos de pruebas en base al análisis de la estructura o arquitectura o arquitectura de un sistema de software (K2). 
5. Describir el objetivo de las pruebas de confirmación y regresión (K2).

Términos usados en este artículo: PRUEBAS DE CAJA NEGRA, COBERTURA DE CÓDIGO, PRUEBAS FUNCIONALES, PRUEBAS DE INTEROPERABILIDAD, PRUEBAS DE CARGA, PRUEBAS DE MANTENIBILIDAD, PRUEBAS DE FIABILIDAD, PRUEBAS DE SEGURIDAD, PRUEBAS DE ESTRÉS, PRUEBAS ESTRUCTURALES, PRUEBAS DE USABILIDAD, PRUEBAS DE CAJA BLANCA.

Antecedentes.

Una vez detectado y corregido un defecto, el software debe volver a probarse para confirmar que el defecto original ha sido corregido con éxito. A esto se le denomina  confirmación. La depuración (corrección de defectos) es una actividad de desarrollo, no una actividad de pruebas.

Las pruebas de regresión son la prueba reiterada de un programa ya probado, después de haber sido modificado, con vistas a localizar defectos surgidos o no descubiertos como resultados del cambio o de los cambios. Estos defectos pueden estar en el software objeto de las pruebas, o en cualquier otro componente de software asociado o no asociado. Se realizan cuando el software, o su entorno, sufren modificaciones. El alcance de las pruebas de regresión depende del riesgo de no encontrar defectos en el software que antes funcionaba.

Las pruebas deben ser repetibles si desean utilizarse a efectos de las pruebas de confirmación o para dar soporte de las pruebas de regresión.

Las pruebas de regresión pueden realizarse en todos los niveles de prueba, e incluyen pruebas funcionales, no funcionales y estructurales. Los juegos de pruebas de regresión se ejecutan muchas veces y por lo general son de lenta evolución, por lo que las pruebas de regresión constituyen un gran potencial para la automatización.

Resumiendo:

Objetivos:

• Probar el objeto después del cambio.
• Después de que un objeto de pruebas o el entorno de su sistema ha sido objeto de modificación, los resultados de pruebas asociados a cambios resultan inválidos: las pruebas deben ser repetidas.
•  Dos razones para modificar el software: Corrección de errores y Extensión funcional.
• Debido a los efectos secundarios de la funcionalidad extendida o nueva, es necesario también repetir pruebas de áreas adyacentes.

Áreas de aplicación:

• Repetir una prueba de funcionalidad que ha sido verificada previamente se denomina prueba de regresión.
• El alcance de la prueba de regresión depende del riesgo que la nueva implementación de la funcionalidad (extención o corrección de errores) impone al sistema.
• El análisis del riesgo se puede realizar con un análisis de impacto.
• Las pruebas de confirmación/regresión pueden ser realizadas en todos los niveles de pruebas.
• Las pruebas típicas despúes de un cambio:

1. Repetición de prueba ("re - testing") = pruebas tras la corrección de errores.
2. Pruebas de regresión ("regresión testing") = pruebas para revelar / descubrir nuevos defectos introducidos recientemente.

Ejecución:

• Básicamente la ejecución tiene lugar de la misma forma en la cual se han ejecutado las pruebas en iteraciones previas.
• En la mayoría de los casos, una prueba de regresión completa no es viable dado sus altos costes y duración.
• Un alto grado de modularidad en el software permite unas pruebas de regresión reducidas más apropiadas.
• Criterios para la selección de casos de prueba de regresión:

1. Casos de pruebas de prioridad alta.
2. Probar solamente la funcionalidad estándar, saltarse casos y variaciones especiales.
3. Probar solamente la configuración utilizada con mayor frecuencia.
4. Probar solamente subsistemas / zonas seleccionadas del objeto de pruebas.

• Si durante fases tempranas del proyecto resulta evidente que ciertas pruebas son adecuadas para las pruebas de regresión, se deberá considerar la automatización de estas pruebas.

Pregunta de examen:

2.- Las pruebas de regresión se deben realizar:

v ).- cada semana

w).- Después que el software a cambiado.

x).- Tan seguido como sea posible.

y).- cuando el ambiente ha cambiado

z ).- cuando el director del proyecto , dice

a) v & w son verdaderas, x – z son falsas

b) w, x & y son verdaderas, v & z son falsas

c) w & y son verdaderas, v, x & z son falsas

d) w is verdadera, v, x y and z son falsas

e) Todo lo mencionado es verdadero

2 Regression testing should be performed:

v) every week

w) after the software has changed

x) as often as possible

y) when the environment has changed

z) when the project manager says

a) v & w are true, x – z are false

b) w, x & y are true, v & z are false

c) w & y are true, v, x & z are false

d) w is true, v, x y and z ar

e) all of the above are true

26 The difference between re-testing and regression testing is
a) re-testing is running a test again; regression testing looks for unexpected side effects-->OK
b) re-testing looks for unexpected side effects; regression testing is repeating those tests
c) re-testing is done after faults are fixed; regression testing is done earlier
d) re-testing uses different environments, regression testing uses the same environment
e) re-testing is done by developers, regression testing is done by independent testers

26 La diferencia entre re- pruebas y pruebas de regresión es:
a) El re-testing es volver a realizar la  prueba ; las pruebas de regresión busca efectos secundarios inesperados-->OK
b ) El re-testing busca efectos secundarios inesperados ; las pruebas de regresión está repitiendo esas pruebas.
c) El re-testing se realiza después de las fallas encontradas ; pruebas de regresión se realiza antes
d ) El re-testing utiliza diferentes entornos , las pruebas de regresión utiliza el mismo entorno
e) El re- testing se realiza por los desarrolladores , las pruebas de regresión se realiza por los probadores independientes

Pruebas de estructura/arquitectura de software (Pruebas estructurales) (K2 - entender, explicar , razonar)

Objetivos:

1. Comparar cuatro tipos de pruebas de software (funcional, no funcional, estructural y asociado al cambio) (K2).
2. Reconocer que las pruebas funcionales y estructurales se llevan a cabo en cualquier nivel de prueba (K1).
3. Identificar y describir los tipos de pruebas no funcionales en base a requisitos no funcionales (K2).
4. Identificar y describir los tipos de pruebas en base al análisis de la estructura o arquitectura o arquitectura de un sistema de software (K2). 
5. Describir el objetivo de las pruebas de confirmación y regresión (K2).

Términos usados en este artículo: PRUEBAS DE CAJA NEGRA, COBERTURA DE CÓDIGO, PRUEBAS FUNCIONALES, PRUEBAS DE INTEROPERABILIDAD, PRUEBAS DE CARGA, PRUEBAS DE MANTENIBILIDAD, PRUEBAS DE FIABILIDAD, PRUEBAS DE SEGURIDAD, PRUEBAS DE ESTRÉS, PRUEBAS ESTRUCTURALES, PRUEBAS DE USABILIDAD, PRUEBAS DE CAJA BLANCA.

Antecedentes.

Las pruebas estructurales son una aproximación al diseño de casos de prueba en donde las pruebas se derivan a partir del conocimiento de la estructura e implementación del software.

Esta aproximación se denomina a veces pruebas de «caja blanca», de «caja de cristal» o de «caja transparente» para distinguirlas de las pruebas de caja negra.

La comprensión del algoritmo utilizado en un componente puede ayudar a identificar particiones adicionales y casos de prueba. Para ilustrar esto, se ha implementado la especificación de la rutina de búsqueda como una rutina de búsqueda binaria (ver figura). Por supuesto, ésta tiene precondiciones más estrictas. La secuencia se implementa como un vector, este vector debe estar ordenado y el valor del límite inferior del vector debe ser menor que el valor del límite superior.

Examinando el código de la rutina de búsqueda, puede verse que la búsqueda binaria implica dividir el espacio de búsqueda en tres partes. Cada una de estas partes constituye una partición de equivalencia (ver figura). A continuación, se diseñan los casos de prueba en los que el elemento buscado se sitúa en los límites de cada una de estas particiones.

Esto da lugar a un conjunto de casos de prueba revisados para la rutina de búsqueda, tal y como se muestra en la última figura. Observe que se ha modificado el vector de entrada para que esté ordenado de forma ascendente y se han añadido pruebas adicionales en las que el elemento a buscar es adyacente a la posición central del vector.

Las pruebas estructurales (caja blanca) pueden realizarse en todos los niveles de prueba. Las técnicas estructurales son las más idóneas, después de las técnicas basadas en la especificación, para ayudar a medir las exhaustividad de las pruebas mediante una evaluación de la cobertura de un tipo de estructura.

La cobertura es la medida en que un juego de pruebas ha probado una estructura expresada como porcentaje de los elemento cubiertos. Si la cobertura no es del 100%, entonces podrán diseñarse más pruebas para probar los elementos que faltan para aumentar la cobertura. Las técnicas de cobertura se abordarán en los siguientes capítulos.

En todos los niveles de prueba, pero especialmente en las pruebas de componente y en las pruebas de integración de componentes, puede recurrirse a herramientas para medir la cobertura de código de los elementos, tales como sentencias o decisiones. Las pruebas estructurales pueden basarse en la arquitectura del sistema, como por ejemplo una jerarquía de llamadas.

Los enfoques de las pruebas estructurales también pueden aplicarse a nivel de sistema, integración de sistemas o pruebas de aceptación.

Resumiendo:

Objetivo:  Cobertura.

•  Análisis de la estructura de un objeto de prueba (enfoque: caja blanca).
• La finalidad de las pruebas es medir el grado en el cual la estructura del objeto de prueba ha sido cubierta por los casos de prueba.

Ámbito de aplicación:

• Las pruebas estructurales son posibles en todos los niveles de pruebas, la cobertura del código se realiza de forma conjunta a las pruebas de componente y de integración mediante el uso de herramientas.
• El diseño de pruebas estructurales se finaliza tras haber sido diseñadas las pruebas funcionales, con el propósito de obtener un alto grado de cobertura.

Ejecución:

• Se probará la estructura interna de un objeto de prueba (por ejemplo el flujo de control en el interior de un componente, el flujo a través de la estructura de un menú).
• Su objetivo es: todos los elementos estructurales identificados deberán estar cubiertos por casos de prueba.

Pregunta de examen:

12 Given the following code, which is true about the minimum number of test cases
required for full statement and branch coverage:
Read P
Read Q
IF P+Q > 100 THEN
Print “Large”
ENDIF
If P > 50 THEN
Print “P Large”
ENDIF
a) 1 test for statement coverage, 3 for branch coverage
b) 1 test for statement coverage, 2 for branch coverage-->OK
c) 1 test for statement coverage, 1 for branch coverage
d) 2 tests for statement coverage, 3 for branch coverage
e) 2 tests for statement coverage, 2 for branch coverage


12 Dado el siguiente código, que es verdad sobre el número mínimo de casos de prueba
necesaria para la plena afirmación y la cobertura de la rama :

Read P
Read Q
IF P+Q > 100 THEN
Print “Large”
ENDIF
If P > 50 THEN
Print “P Large”
ENDIF


a) Prueba 1 para la cobertura de declaración, 3 para la cobertura de la rama
b) 1 prueba para la cobertura de sentencias , 2 para la cobertura de rama--->OK
c ) 1 prueba para la cobertura de declaración, 1 para la cobertura de rama
d ) 2 pruebas para la cobertura de declaración , 3 para la cobertura de la rama

e) 2 pruebas para la cobertura de declaración, 2 para la cobertura de rama

Pruebas no funcionales (K2 - entender, explicar , razonar)

Objetivos:

1. Comparar cuatro tipos de pruebas de software (funcional, no funcional, estructural y asociado al cambio) (K2).
2. Reconocer que las pruebas funcionales y estructurales se llevan a cabo en cualquier nivel de prueba (K1).
3. Identificar y describir los tipos de pruebas no funcionales en base a requisitos no funcionales (K2).
4. Identificar y describir los tipos de pruebas en base al análisis de la estructura o arquitectura o arquitectura de un sistema de software (K2). 
5. Describir el objetivo de las pruebas de confirmación y regresión (K2).

Términos usados en este artículo: PRUEBAS DE CAJA NEGRA, COBERTURA DE CÓDIGO, PRUEBAS FUNCIONALES, PRUEBAS DE INTEROPERABILIDAD, PRUEBAS DE CARGA, PRUEBAS DE MANTENIBILIDAD, PRUEBAS DE FIABILIDAD, PRUEBAS DE SEGURIDAD, PRUEBAS DE ESTRÉS, PRUEBAS ESTRUCTURALES, PRUEBAS DE USABILIDAD, PRUEBAS DE CAJA BLANCA.

Antecedentes.

Las pruebas no funcionales incluyen, pero sin limitarse a ello, pruebas de rendimiento, pruebas de carga, pruebas de estrés, pruebas de usabilidad, pruebas de mantenibilidad, pruebas de fiabilidad y pruebas de portabilidad. Estas pruebas se refieren a "cómo" funciona el sistema.

Las pruebas no funcionales pueden ejecutarse a todos los niveles de prueba. El término pruebas no funcionales hace referencia a las pruebas necesarias para medir las características de los sistemas y software que pueden cuantificarse según una escala variable , tales como los tiempos de respuesta en el caso de las pruebas de rendimiento.

Estas pruebas pueden hacer referencia a un modelo de calidad como el previsto en "Ingeniería de software" (ISO 9126). 

Las pruebas no funcionales tienen en cuenta el comportamiento externo del software y , en la mayoría de los casos, para ello utiliza técnicas de diseño de pruebas de caja negra.

Resumiendo:

Pruebas de Sistemas

• Pruebas de carga ("load test"): Sistema bajo carga (carga mínima, más usuarios / Transaccionales).

La carga de trabajo se refiere a la capacidad máxima que tiene un servidor web (hardware y software), para atender a un conjunto de usuarios de manera simultánea. Por ello, las actividades de esta etapa tienen relación con comprobar, de manera anticipada, el funcionamiento que tendrá el servidor del Sitio Web cuando esté en plena operación.

Las pruebas en este caso consisten en simular una carga de trabajo similar y superior a la que tendrá cuando el sitio esté funcionando, con el fin de detectar si el software instalado (programas y aplicaciones) cumple con los requerimientos de muchos usuarios simultáneos y también si el hardware (servidor y el equipamiento computacional de redes y enlace que lo conecta a Internet) es capaz de soportar la cantidad de visitas esperadas.

Es importante considerar que si el servidor está en las dependencias de un tercero que entrega el servicio de alojamiento del Sitio Web (hosting), se le debe solicitar a dicho proveedor un informe en que dé a conocer las características de carga de la solución de hardware y software sobre la cual funciona el Sitio Web de la institución.

Hay diversos software en el mercado que están orientados a este tipo de simulaciones, todos los cuales ofrecen características similares. Entre los datos más relevantes que es posible obtener se cuenta:

• Tiempo de acceso de los usuarios a los datos
• Volumen de datos y ancho de banda utilizado
• Archivos solicitados y tiempos usados en transferencia de datos
• Tiempo de espera de los usuarios tras hacer un clic
• Tiempo de respuesta a clicks de usuarios
• Niveles de error existentes tras clicks de usuarios

Como se puede apreciar del listado anterior, los reportes que se obtienen a través de esta vía se refieren a tiempos de acceso que tienen los usuarios que acceden al Sitio Web y la degradación que ocurre en los servicios cuando aumenta el volumen de visitantes concurrentes.

Enlace Recomendado

Apache JMeter Herramienta Open Source para las pruebas de carga.

• Pruebas de rendimiento ("perfomance test"): Rapidez con la cual un sistema ejecuta una determinada función.

Enlace Recomendado

Apache JMeter Herramienta Open Source para las pruebas de rendimiento.

• Pruebas de volumen ("volumne test"): Porcesamiento de grandes cantidades de datos / ficheros.
• Pruebas de estrés ("stress test") : Reacción a la sobrecarga / recuperación tras el retorno a una carga normal.
• Pruebas de estabilidad ("stability test"): Rendimiento en "modo de operación contínua".
• Pruebas de robustez ("test for robustness"): Reacción a entradas erróneas no especificadas. a fallos de hardware / recuperación ante situaciones de desastre.
• Pruebas de cumplimiento: Cumplir normas y reglamentos (interno/ externo).
• Pruebas de usabilidad: Estructurado , comprensible , fácil de aprender por parte del usuario.

Otros aspectos no funcionales de calidad

• Portabilidad: adaptabilidad , reemplazabilidad, instalabilidad, coexistencia, cumplimiento de portabilidad.
• Mantenibilidad: analizabilidad, modificabilidad, estabilidad, testabilidad, cumplimiento de mantenibilidad.
• Fiabilidad: madurez, tolerancia a fallos, recuperabilidad, cumplimiento de fiabilidad. 

Pregunta de examen

7 Non-functional system testing includes:

a) testing to see where the system does not function properly

b) testing quality attributes of the system including performance and usability-->OK

c) testing a system feature using only the software required for that action

d) testing a system feature using only the software required for that function

e) testing for functions that should not exist

7 Pruebas del sistema no funcional incluye:

a) la prueba para ver donde el sistema no funciona correctamente

b ) los atributos de calidad de pruebas del sistema , incluyendo el rendimiento y facilidad de uso-->OK

c) probar una característica del sistema utilizando sólo el software necesario para la acción

d ) probando una característica del sistema utilizando sólo el software requerido para esa función

e) las pruebas para las funciones que no deberían existir.

39 Which of the following is not part of performance testing:
a) Measuring response time
b) Measuring transaction rates
c) Recovery testing-->NOK
d) Simulating many users
e) Generating many transactions

39 ¿Cuál de los siguientes no es parte de las pruebas de rendimiento 
a) Medición de tiempo de respuesta-->OK
b ) La medición de las tasas de transacción-->OK
c ) las pruebas de regresión-->NOK
d ) La simulación de muchos usuarios-->OK
e) Generar muchas transacciones-->OK

Pruebas Funcionales o Pruebas de funciones (K2 - entender, explicar , razonar)

Objetivos:

1. Comparar cuatro tipos de pruebas de software (funcional, no funcional, estructural y asociado al cambio) (K2).
2. Reconocer que las pruebas funcionales y estructurales se llevan a cabo en cualquier nivel de prueba (K1).
3. Identificar y describir los tipos de pruebas no funcionales en base a requisitos no funcionales (K2).
4. Identificar y describir los tipos de pruebas en base al análisis de la estructura o arquitectura o arquitectura de un sistema de software (K2). 
5. Describir el objetivo de las pruebas de confirmación y regresión (K2).

Términos usados en este artículo: PRUEBAS DE CAJA NEGRA, COBERTURA DE CÓDIGO, PRUEBAS FUNCIONALES, PRUEBAS DE INTEROPERABILIDAD, PRUEBAS DE CARGA, PRUEBAS DE MANTENIBILIDAD, PRUEBAS DE FIABILIDAD, PRUEBAS DE SEGURIDAD, PRUEBAS DE ESTRÉS, PRUEBAS ESTRUCTURALES, PRUEBAS DE USABILIDAD, PRUEBAS DE CAJA BLANCA.

Antecedentes.

Las funciones que un sistema, subsistema o componente debe llevar a cabo pueden describirse en productos de trabajo tales como una especificación de requisitos , casos de uso o una especificación funcional, o incluso pueden no estar documentadas. Las funciones son "lo que" hace el sistema.

Las pruebas funcionales se basan en funciones y prestaciones (descritas en documentos o entendidas por lo probadores) y en su interoperabilidad con sistemas específicos, que pueden llevarse a cabo en todos los niveles de prueba (por ejemplo , las pruebas de componente pueden basarse en una especificación de componente).

Las técnicas basadas en la especificación sirven para obtener condiciones de prueba y casos de prueba a partir de la funcionalidad de un software o sistema.

Las pruebas funcionales  tienen en cuenta el comportamiento externo del software (pruebas de caja negra).

Un tipo de pruebas funcionales, las pruebas de seguridad, estudian las funciones (por ejemplo , un cortafuegos) asociadas a la detección de amenazas procedentes de personas ajenas y malintencionadas, tales como virus. Otro tipo de pruebas funcionales, las pruebas de interoperabilidad, evalúan la capacidad del producto de software de interactuar con uno o más componentes o sistemas especificados. 

Resumiendo:

Objetivos

1. El objetivo de las pruebas funcionales es, la función del objeto de prueba.
2. La  funcionalidad puede ser vinculada a los datos de entrada y salida de un objeto de prueba.
3. Los métodos de caja negra ("black box") se utilizan en el diseño de casos de prueba relevantes.
4. Las pruebas son para verificar los requisitos funcionales (establecidos en las especificaciones, conceptos, casos de estudio, reglas de negocio o documentos relacionados).

Ámbito

1. Las pruebas funcionales se pueden llevar en todos los niveles de prueba (pruebas de componentes, pruebas de integración, pruebas de sistemas y pruebas de aceptación).

Ejecución

1. El objeto de prueba es ejecutado utilizando combinaciones de datos de pruebas derivados/generados a partir de los casos de prueba.
2. Los resultados de la ejecución de las pruebas son comparadas con los resultados esperados.
3. Pruebas de Seguridad.
4. Tipo de prueba funcionales que controlan las  amenazas externas.
5.  Los ataques maliciosos podrían dañar programas o datos (virus).

Tipos de pruebas (K2 - entender, explicar , razonar)

Objetivos:

1. Comparar cuatro tipos de pruebas de software (funcional, no funcional, estructural y asociado al cambio) (K2).
2. Reconocer que las pruebas funcionales y estructurales se llevan a cabo en cualquier nivel de prueba (K1).
3. Identificar y describir los tipos de pruebas no funcionales en base a requisitos no funcionales (K2).
4. Identificar y describir los tipos de pruebas en base al análisis de la estructura o arquitectura o arquitectura de un sistema de software (K2). 
5. Describir el objetivo de las pruebas de confirmación y regresión (K2).

Términos usados en este artículo: PRUEBAS DE CAJA NEGRA, COBERTURA DE CÓDIGO, PRUEBAS FUNCIONALES, PRUEBAS DE INTEROPERABILIDAD, PRUEBAS DE CARGA, PRUEBAS DE MANTENIBILIDAD, PRUEBAS DE FIABILIDAD, PRUEBAS DE SEGURIDAD, PRUEBAS DE ESTRÉS, PRUEBAS ESTRUCTURALES, PRUEBAS DE USABILIDAD, PRUEBAS DE CAJA BLANCA.

Antecedentes.

Un grupo de actividades de pruebas pueden tener por objetivo comprobar el sistema de software (o parte del sistema) en base a un motivo u objetivo específico.

Un tipo de prueba se centra en un objetivo de prueba en particular, que puede ser cualquiera de los siguientes:

• Una función a realizar por el software.
• Una característica  de calidad no funcional , tales como la fiabilidad o la usabilidad.
• La estructura o arquitectura del software o sistema.

Cambios asociados, es decir, confirmar que se han solucionado los defectos (pruebas de confirmación) y localizar cambios no intencionados (pruebas de regresión).

Puede desarrollarse y/o utilizarse un modelo del software en las pruebas estructurales (por ejemplo , un modelo de flujo de control o un modelo de estructura de menús), en las pruebas no funcionales (por ejemplo , un modelo de rendimiento, un modelo de amenaza de seguridad y un modelo de transición de estados o una mera especificación de lenguaje).

Resumiendo:

En la sección previa hemos vistos los distintos noveles de pruebas, como, pruebas de componentes, integración, de sistema , etc.

En cada nivel de prueba los objetivos de las pruebas tienen un foco diferentes, por lo tanto, se aplican tipos de pruebas durante los distintos niveles de pruebas.

Tipos de pruebas:

1. Pruebas funcionales (su objetivos, es probar la función).
2. Pruebas no funcionales (su objetivo, es probar las características del producto).
3. Pruebas estructurales (su objetivo, es probar la estructura / arquitectura del software).
4. Pruebas asociadas al cambio (su objetivo es, probar después del cambio).

Pregunta de examen:

33 Which of the following is NOT part of system testing:
a) business process-based testing
b) performance, load and stress testing
c) requirements-based testing
d) usability testing
e) top-down integration testing-->OK


33 ¿Cuál de los siguientes NO es parte de la prueba del sistema :
a) las pruebas basadas en los procesos de negocio
b ) las pruebas de rendimiento , la carga y el estrés
c ) las pruebas basadas en requisitos
d ) las pruebas de usabilidad
e) las pruebas de integración de arriba hacia abajo-->OK

Pruebas de aceptación (K2 - entender, explicar , razonar)

Objetivos:

1. Comparar los distintos niveles de pruebas : Principales objetivos , objetos típicos de las pruebas, objetivos típicos de las pruebas (por ejemplo , funcionales o estructurales) y productos de trabajos asociados, personas que prueba, tipos de defectos y fallos a identificar (K2).

Términos usados en este artículo: PRUEBAS DE ACEPTACIÓN DE USUARIO.

Pruebas de Aceptación (K2).

Base de pruebas:

1. Requisitos del usuario.
2. Requisitos del sistema.
3. Casos de uso.
4. Procesos de negocio.
5. Informes de análisis de riesgos.

Objetos de prueba típicos:

1. Procesos de negocio en sistema completamente integrado.
2. Procesos operativos y de mantenimiento.
3. Procedimientos de usuario.
4. Formularios.
5. Informes.

Datos de configuración.

Las pruebas de aceptación son a menudo responsabilidad de los clientes o usuarios de un sistema, a pesar de que también pueden participar otras partes interesadas.

• El Objetivo de las pruebas de aceptación es crear confianza en el sistema, partes del sistema o características no funcionales del sistemas. 
• El objetivo principal de las pruebas de aceptación no es localizar defectos. 
• Las pruebas de aceptación evalúan la buena disposición de un sistema para su despliegue y uso, a pesar de no constituir necesariamente el último nivel de prueba.

 Así por ejemplo, las pruebas de aceptación de un sistema pueden estar seguidas de una prueba de integración del sistema a gran escala.

Las pruebas de aceptación pueden darse en distintos momentos del ciclo de vida, tales como:

1. Un producto de software COTS (Desarrollo de Software basado en componentes) puede ser objeto de pruebas de aceptación una vez instalado o integrado.
2. Las pruebas de aceptación de la usabilidad de un componente pueden realizarse durante las pruebas de componentes.
3. Las pruebas de aceptación de una nueva mejora funcional pueden realizarse antes de las pruebas de sistema.

En general, las pruebas de aceptación pueden adoptar , entre otras, las siguientes formas:

• Pruebas de aceptación de usuario: En general , verifican la idoneidad de uso del sistema por parte de los usuarios comerciales.
• Pruebas operativas (de aceptación): La aceptación del sistema por parte de los administradores del sistema, entre las que se incluyen:

1. Pruebas de backup/restauración.
2. Recuperación de desastres.
3. Gestión de usuarios.
4. Tarea de mantenimiento.
5. Carga de datos y tareas de migración.
6. Comprobaciones periódicas de vulnerabilidad de seguridad.

• Pruebas de aceptación contractual y normativa: Toman como base los criterios de aceptación previstos en un contrato para fabricar un software desarrollado a medida. Los criterios de aceptación deberán establecerse en el momento en que las partes aceptan contraer dicho contrato. Las pruebas de aceptación normativa toman como base cualquier normativa de obligado cumplimiento, tales como normativas gubernamentales, legales o de seguridad.
• Pruebas Alfa y Beta (o de campo): Los desarrolladores de software de mercado, o COTS, a menudo quieren obtener feedback de clientes potenciales o existentes en su mercado antes de poner a la venta un producto de software. Las pruebas alfa se llevan a cabo en el emplazamiento de la organización de desarrollo, pero no las realiza el equipo de desarrollo. Las pruebas beta, o pruebas de campo, las realizan los clientes o clientes en sus propias instalaciones.

Las organizaciones también pueden emplear otros término, tales como pruebas de aceptación en fábrica y pruebas de aceptación en emplazamiento, en el caso de sistemas probados antes y después de su traslado a las instalaciones del cliente. 


Pregunta de examen:

20 Beta testing is:
a) Performed by customers at their own site-->OK
b) Performed by customers at their software developer’s site
c) Performed by an independent test team
d) Useful to test bespoke software
e) Performed as early as possible in the lifecycle

20 Testing Beta es:
a) Realizado por los clientes en su propio sitio-->OK
b ) Ejecutado por sus clientes en el sitio del desarrollador de software
c ) Realizado por un equipo de pruebas independiente
d ) Útil para probar software a medida
e) Se realiza tan pronto como sea posible en el ciclo de vida

22 The main focus of acceptance testing is:
a) finding faults in the system
b) ensuring that the system is acceptable to all users
c) testing the system with other systems
d) testing for a business perspective
e) testing by an independent test team


22 El objetivo principal de las pruebas de aceptación es:
a) la búsqueda de fallas en el sistema
b ) garantizar que el sistema sea aceptable para todos los usuarios
c ) probar el sistema con otros sistemas
d ) las pruebas de una perspectiva de negocio-->OK

e) las pruebas por un equipo de pruebas independiente