Capitulo 8 Pruebas de Software

1
Lectura 1

Capitulo 8: Pruebas de Software

Contenidos
Desarrollo de pruebas Desarrollo dirigido a las pruebas Versin de Prueba Prueba de Usuario

Capitulo 8: Pruebas de Software

Pruebas de Software
Las pruebas intentan demostrar que un programa hace lo que se pretende que haga y tambin para descubrir defectos del programa antes de que est puesto en uso. Al probar el software, se ejecuta un programa utilizando datos artificiales.

Se revisa los resultados de la prueba que se opera para buscar errores, anomalias o informacin acerca de atributos no funcionales del programa. (Rendimiento, Portabilidad, etc).
Puede revelar la presencia de errores, NO su ausencia.

Las pruebas son partes de un proceso de verificacin y validacin ms general.

Capitulo 8: Pruebas de Software

Objetivos de las Pruebas de Software

Demostrar al desarrollador y comprador que el software cumple con los requerimientos.
Para el software personalizado, esto significa que debe haber al menos una prueba por cada requisito en el documento de requisitos. Para productos de software genricos, significa al menos una prueba para todas las caractersticas del sistema, adems de combinaciones de estas caractersticas, que se incorporaran en el lanzamiento del producto.

Para descubrir situaciones en las cuales el comportamiento del software es incorrecto, indeseable o no conforma sus especificaciones.
Pruebas de defectos tiene que ver con erradicar comportamiento del sistema no deseado, tales como cadas del sistema, interacciones no deseadas con otros sistemas, clculos incorrectos y corrupcin de los datos.

Capitulo 8: Pruebas de Software

Validacin y pruebas de defectos

El primer objetivo lleva a las pruebas de validacin
Uno espera que el sistema rinda correctamente usando un determinado conjunto de casos de prueba que reflejen el uso esperado del sistema.

El segundo objetivo lleva a las pruebas de defecto

Los casos de prueba estn diseados para exponer defectos. Los casos de prueba en las pruebas de defectos pueden ser deliberadamente confusos y no tiene por qu reflejar la forma en que el sistema se utiliza normalmente.

Capitulo 8: Pruebas de Software

Metas del proceso de pruebas

Pruebas de Validacin
Para demostrar al desarrollador y al cliente que el software cumple sus requisitos Una prueba exitosa muestra que el sistema opera como se pretende

Pruebas de Defectos
Para descubrir las fallas o defectos en el software donde su comportamiento es incorrecto o que no est conforme con sus especificaciones

Capitulo 8: Pruebas de Software

Un modelo de Entrada-Salida de prueba del programa

Capitulo 8: Pruebas de Software

Verificacin vs. validacin

Verificacin: "Estamos construyendo bien el producto ?. El software debe conformarse a la especificacin. Validacin: " Estamos construyendo el producto correcto?. El software debe hacer lo que el usuario realmente necesita.

Capitulo 8: Pruebas de Software

Validacin y Verificacin de confianza

Objetivo de la V & V es establecer la confianza de que el sistema de software es "adecuado". El nivel de confianza adquirido depende tanto del propsito del sistema, las expectativas del usuario y el entorno de marketing
Propsito del Software
Cuanto ms critico sea el software, mas importante debe ser su confiabilidad.

Expectativas del usuario

Los usuarios pueden tener bajas expectativas de ciertos tipos de software.

Entorno de Marketing
Llevar un producto de manera rpida al mercado puede ser ms importante que encontrar defectos en el programa.
Capitulo 8: Pruebas de Software

10

Inspecciones y Pruebas

Inspecciones de software: Involucrados en el anlisis de la representacin del sistema esttico para descubrir problemas (verificacin esttica)
Puede ser complementada con herramientas basadas en documentos y anlisis de cdigo.

Pruebas de software: Involucrado con el ejercicio y observacin del comportamiento del producto (verificacin dinmica)
El sistema es ejecutado con datos de prueba y su comportamiento operativo observado.

Capitulo 8: Pruebas de Software

11

Inspecciones y pruebas

Capitulo 8: Pruebas de Software

12

Inspecciones de software
Estos involucran a personas que examinan la representacin fuente con el fin de descubrir anomalas y defectos. Las inspecciones no requieren la ejecucin de un sistema as puede ser usado antes de la implementacin. Se pueden aplicar a cualquier representacin del sistema (requisitos, diseo, datos de configuracin, datos de pruebas, etc). Han sido demostrados ser una tcnica eficaz para descubrir los errores del programa.

Capitulo 8: Pruebas de Software

13

Ventajas de Inspecciones
Durante las pruebas, los errores pueden enmascarar (ocultar) otros errores. Debido a que la inspeccin es un proceso esttico, no tiene que preocuparse por las interacciones entre los errores. Versiones incompletas de un sistema pueden ser inspeccionados sin costes adicionales. Si un programa est incompleto, entonces necesita desarrollar arneses especiales de prueba para probar las piezas que estn disponibles.

Capitulo 8: Pruebas de Software

1 4

Un modelo del proceso de pruebas de software

Capitulo 8: Pruebas de Software

15

Etapas de prueba
Pruebas de desarrollo, donde se prueba el sistema durante el desarrollo de descubrir errores y defectos. Pruebas de lanzamiento, donde un equipo de testeo independiente prueba una versin completa del sistema antes de que se libere a los usuarios. Pruebas de usuario, donde los usuarios o potenciales usuarios de un sistema prueban el sistema en su entorno.

Capitulo 8: Pruebas de Software

16

Pruebas de Desarrollo
Las pruebas de desarrollo incluyen todas las actividades de prueba que se llevan a cabo por el equipo que desarrolla el sistema.
Las pruebas unitarias, donde las unidades de programa individuales o clases de objetos se ponen a prueba. Las pruebas unitarias deben centrarse en probar la funcionalidad de los objetos o mtodos. Las pruebas de componentes, donde varias unidades individuales se integran para crear componentes compuestos. . Las pruebas de componentes deberan centrarse en las interfaces de los componentes de prueba. Las pruebas del sistema, donde algunos o todos los componentes en un sistema estn integrados y el sistema se ha probado como un todo. Las pruebas del sistema debe centrarse en las interacciones de los componentes de prueba.

Capitulo 8: Pruebas de Software

17

Prueba de unidad
La prueba unitaria es el proceso de determinacin de componentes individuales de forma aislada. Es un proceso de pruebas de defectos. Las unidades pueden ser:
Las funciones individuales o mtodos dentro de un objeto Clases de objetos con varios atributos y mtodos Componentes compuestos con interfaces definidas utilizadas para acceder a su funcionalidad.

Capitulo 8: Pruebas de Software

18

Pruebas de clase de objeto

Cobertura completa de la prueba de una clase implica
Probando todas las operaciones asociadas con un objeto Establecer y verificar el valor de todos los atributos del objeto Poner el objeto en todos los estados posibles.

La herencia hace que sea ms difcil disear pruebas de clase de objeto ya que la informacin a ensayar no se localiza.

Capitulo 8: Pruebas de Software

19

La estacin meteorolgica interfaz de objeto

Capitulo 8: Pruebas de Software

20

Pruebas automatizadas
Cuando sea posible, las pruebas unitarias deberan ser automatizadas para que se ejecuten las pruebas y se comprueben sin intervencin manual. En las pruebas unitarias automatizadas, se hace uso de un framework (marco de trabajo) de automatizacin de pruebas (tales como JUnit) para escribir y ejecutar las pruebas del programa. Frameworks de pruebas unitarias proporcionan clases genricas de prueba que se extienden a crear casos de prueba especficos. Luego pueden ejecutar todas las pruebas que se han implementado e informar, a menudo a travs de alguna GUI, en el xito o inexactitud de las pruebas.

Capitulo 8: Pruebas de Software

21

Componentes automatizados de prueba

Una parte de configuracin, donde se inicializa el sistema con el caso de prueba, es decir, las entradas y salidas esperadas. Una parte de llamado, donde se llama al objeto o mtodo a probar. Una parte de afirmacin donde se compara el resultado de la afirmacin con el resultado esperado. Si la afirmacin se evala como verdadera, la prueba ha tenido xito, si es falso, entonces ha fallado.

Capitulo 8: Pruebas de Software

22

Eleccin de casos de prueba de unidad

Los casos de prueba deben mostrar que, cuando se utiliza como se esperaba, el componente que se est probando hace lo que se supone que debe hacer. Si hay defectos en el componente, stos deben ser revelados por los casos de prueba.

Esto lleva a 2 tipos de casos de unidad de prueba:

El primero de ellos debera reflejar el funcionamiento normal de un programa y deben mostrar que el componente funciona como se espera. El otro tipo de caso de prueba debe estar basado en la experiencia de las pruebas de donde surgen los problemas comunes. Se deben utilizar entradas anormales para comprobar que stos son procesados correctamente y no bloquearn el componente.

Capitulo 8: Pruebas de Software

23

Las estrategias de prueba

Pruebas de particin, donde se identifican grupos de entradas que tienen caractersticas comunes y debe ser procesados de la misma manera..
Usted debe elegir las pruebas desde dentro de cada uno de dichos grupos.

Orientacin basada en pruebas, donde se utilizan pautas de pruebas para elegir los casos de prueba.
Estas pautas reflejan experiencias anteriores de los tipos de errores que los programadores suelen hacer en el desarrollo de componentes.

Capitulo 8: Pruebas de Software

24

Pruebas de particin
Los datos de entrada y los resultados de salida a menudo caen en diferentes categoras donde todos los miembros de una clase estn relacionados. Cada una de estas clases es una particin de equivalencia o dominio donde el programa se comporta de una manera equivalente, para cada miembro de la clase. Los casos de prueba deben ser elegidos de cada particin.

Capitulo 8: Pruebas de Software

25

Particin de equivalencia

Capitulo 8: Pruebas de Software

26

Particiones de equivalencia

Capitulo 8: Pruebas de Software

27

Pautas de prueba (secuencias)

Las pruebas de software con secuencias que tienen un nico valor. Utilizar secuencias de diferentes tamaos en diferentes pruebas. Esto disminuye la oportunidad de que un programa con defectos genere accidentalmente una salida correcta. Derivar pruebas para que los primeros elementos, medio y ltimos de la secuencia sean accedidas. Este enfoque revela problemas en las fronteras de la particion.

Capitulo 8: Pruebas de Software

28

Pautas generales de prueba

Selecciona las entradas que obligan al sistema a generar todos los mensajes de error Entradas de diseo que causan el desbordamiento de buffers de entrada

Repita la misma entrada o serie de entradas en numerosas ocasiones

Forzar salidas invlidas que se generen Forzar resultados de clculo que sean demasiado grande o demasiado pequeo.

Capitulo 8: Pruebas de Software

29

Puntos Clave
Las pruebas slo puede mostrar la presencia de errores en un programa. No pueden demostrar que no hay fallas restantes. La prueba de desarrollo es la responsabilidad del equipo de desarrollo de software. Un equipo independiente debe ser responsable de probar un sistema antes de que este disponible para los clientes. Las pruebas de desarrollo incluyen las pruebas unitarias, en las que se prueban distintos objetos y mtodos. Las pruebas de componentes en los que se prueban los grupos relacionados a los objetos y las pruebas del sistema, en el que se prueban los sistemas parciales o totales.
Capitulo 8: Pruebas de Software

30

Capitulo 8 Prueba de software

Lectura 2
Capitulo 8: Pruebas de Software

Prueba de componentes
Los componentes del software son a menudo elaborados mediante objetos en interaccin.
Por ejemplo, en el sistema de estacin meteorolgica, el componente de reconfiguracin incluye objetos que tienen que ver con cada aspecto de esta

Se accede a la funcionalidad de estos objetos a travs de la interfaz del componente. La prueba de componentes compuestos , debe centrarse en demostrar que la interfaz del componente se comporta de acuerdo a sus especificaciones.

Interfaz de prueba
Casos de Prueba

Prueba de interfaz
Los objetivos son detectar fallos debidos a errores de interfaz o suposiciones invlidas sobre las interfaces. Tipos de interfaces: Interfase de parmetros : Datos que pasan de un mtodo o procedimiento a otro. Interfaces de memoria compartida: Estas son interfases en las cuales un bloque de memoria es compartido entre componentes. Los datos puestos en la memoria por un subsistema, son retirados de ah por otro subsistema. Interfaces de procedimiento: Son interfaces en las cuales el sub-sistema encapsula un conjunto de procedimientos que sern llamadas por otros subsistemas.

Interfaces de paso de mensajes: Es un interfaz en la cual los subsistemas que solicitan los servicios de otros subsistemas

Errores de Interfase
Mal uso de interfaces: Un componente de
llamada, llama a otro componente y efecta un error en el uso del interfaz; por ejemplo, cuando los parmetros estn en el orden incorrecto.

Malentendido de interfaces: Un

componente de llamada incorpora suposiciones sobre el comportamiento de este que son incorrectos. Por ejemplo, un mtodo de bsqueda binaria puede llamarse con un parmetro que es un arreglo desordenado Entonces fallara la bsqueda.

Errores de sincronizacin: El productor de los datos y el consumidor de los datos, operan en diferentes velocidades.

Directrices de prueba de interfaz

Examina el cdigo a ser probado y hacemos una lista explicita de cada llamada a un componente externo. Siempre pruebe los parmetros de puntero con punteros nulos.

Disea pruebas que hacen que el componente falle.

Es recomendado el uso de pruebas de tensin en los sistemas de paso de mensajes. Esta es una forma efectiva de revelar problemas con el temporizador. En los sistemas de memoria compartida, variar el orden en el que los componentes se activan.

Sistema de prueba
Las pruebas del sistema durante el desarrollo consiste en la integracin de componentes para crear una versin del sistema y despus probar el sistema integrado. El enfoque en las pruebas del sistema es la prueba de las interacciones entre los componentes. El sistema de prueba comprueba que los componentes son compatibles, interactua correctamente y transfiere los datos correctos en el momento adecuado a travs de sus interfaces. Las pruebas del sistema comprueba el comportamiento emergente de un sistema.

Pruebas de Sistema
Durante las pruebas del sistema, los componentes reutilizables que se han desarrollado por separado y fuera de la plataforma del sistema pueden estar integrados con los componentes desarrollados recientemente. El sistema completo se prueba posteriormente.

Los componentes desarrollados por diferentes miembros del equipo o subequipos pueden integrarse en esta etapa. Las pruebas del sistema es un colectivo ms que un proceso individual. En algunas compaas, las pruebas del sistema pueden implicar un equipo de pruebas independiente sin la participacin de diseadores y programadores.

Pruebas de Caso
Los casos de uso desarrollados para identificar las interacciones del sistema pueden ser utilizados como una base para las pruebas del sistema. Cada caso de uso generalmente implica varios componentes del sistema. Probar el caso de uso fuerza a que estas interacciones ocurran. Los diagramas de secuencia asociados con el caso de uso documentan los componentes y las interacciones que se estn probando.

Recopilacin de datos metereolgicos mediante cuadros de secuencia

Polticas de Prueba
Una prueba exhaustiva del sistema donde se prueben todas sus secuencias es imposible. Por lo tanto las pruebas deben estar basadas en unos subconjuntos de casos de pruebas posibles. Ejemplos de Polticas de prueba: Todas las funciones de sistema en las que se accede a travs de los mens, deben de ser probados. Las combinaciones de funciones (por ejemplo, el formato de texto) que se accede a travs del mismo men debe ser probado. Cuando la entrada del usuario se proporciona, todas las funciones deben ser probadas con ambas entradas correctas e incorrectas.

Desarrollo dirigido por pruebas (TDD)

TDD es un enfoque para el desarrollo del programa en el que se intercalan las pruebas y el desarrolla cdigo. Las pruebas se escriben antes del cdigo y 'pasar las pruebas es el motor fundamental del desarrollo. Desarrollar un cdigo de forma escalonada, junto con una prueba para cada escaln. No se pasara al siguiente escaln hasta que el cdigo que se ha desarrollado pase la prueba. TDD fue presentado como parte de los mtodos giles como Programacin extrema.

Desarrollo basado en pruebas

TDD proceso de las actividades

Empezar por identificar el incremento de la funcionalidad que se requiere. Normalmente, esta debe ser pequea y aplicable en unas pocas lneas de cdigo. Escribir un ensayo para esta funcionalidad y aplicar esto como una prueba automatizada. Ejecute la prueba, junto con todas las dems pruebas que se han implementado. En un principio, no se ha implementado la funcionalidad de modo que la nueva prueba fallar. Implementar la funcionalidad y volver a ejecutar la prueba. Una vez que todas las pruebas se ejecutan correctamente, se pasa a la aplicacin de la siguiente parte de la funcionalidad.

Beneficios de desarrollo basado en pruebas

Cdigo de cobertura : Cada segmento de cdigo que se escribe tiene por lo menos una prueba asociada, de modo que todo el cdigo escrito tiene por lo menos una prueba. Pruebas de regresin: Un conjunto de pruebas de regresin se desarrolla gradualmente como se desarrolla un programa. Depuracin simplificada: Cuando falla una prueba, debera ser obvio hallar el problema. El nuevo cdigo escrito necesita ser revisado y modificado. Documentacin del sistema: Las propias pruebas son una forma de documentacin que describe lo que el cdigo debera estar haciendo.

Pruebas de regresin
Las pruebas de regresin estn probando el sistema para comprobar que los cambios no han "roto el cdigo del trabajo previamente hecho. En un proceso de prueba manual, las pruebas de regresin son caras, pero, con la prueba automatizada, es sencillo y directo. Todas las pruebas se vuelven a ejecutar cada vez que se realiza un cambio en el programa. Las pruebas se deben ejecutar "con xito" antes de que el cambio se halla dado .

Prueba de versin
Las pruebas de versin : Son el proceso de probar una versin particular de un sistema que est diseado para su uso fuera del equipo de desarrollo. El objetivo principal del proceso de pruebas de versin es convencer al proveedor del sistema que es lo suficientemente bueno para su uso. La prueba de versin tiene que demostrar que el sistema ofrece la funcionalidad especificada para su desempeo y la fiabilidad, que no falle durante el uso normal. Las pruebas de versin suelen ser un proceso de pruebas donde estas slo se derivan de la especificacin del sistema.

Prueba de versin y prueba de sistema

Las pruebas de versin son una forma de prueba de sistemas. Diferencias importantes: Un equipo independiente que no ha participado en el desarrollo del sistema, debe ser el responsable de las pruebas de versin. Las pruebas del sistema hechas por el equipo de desarrollo debern centrarse en el descubrimiento de errores en el sistema (pruebas de defectos). El objetivo de las pruebas de versin es de comprobar que el sistema cumple con los requisitos y es lo suficientemente bueno para el uso externo (pruebas de validacin).

Las pruebas basados en requerimientos

Las pruebas basados en requerimientos, implican

examinar cada requisito y desarrollar una prueba o muchas pruebas para esto.

Ejemplo de requerimientos:
Si un paciente sabe que es alrgico a algn medicamento en particular, entonces la prescripcin de medicamentos tendr un mensaje de advertencia para el usuario del sistema. Si un mdico decide ignorar una advertencia de alergia, debe presentar una razn del por qu lo ha ignorado.

Pruebas de Requerimiento
Establecer un registro de pacientes sin alergias conocidas. Prescribir medicamentos para las alergias que se sabe que existen. Comprobar que el sistema no emite un mensaje de advertencia. Establecer un registro de pacientes con alergia conocida. Prescribir la medicacin para la cual el paciente es alrgico , y comprobar que el aviso es emitido por el sistema. Establecer un registro de paciente en el que las alergias a dos o ms frmacos se registran. Prescribir ambos frmacos por separado y comprobar que la advertencia correcta para cada frmaco sea emitida. Prescribir dos medicamentos al que el paciente sea alrgico. Verificar que las dos advertencias se hayan publicado correctamente.

Prescribir un frmaco que emite una advertencia y hacer caso omiso de esa advertencia. Compruebe que el sistema requiere que el usuario proporcione informacin que explica por qu la advertencia fue denegada.

Caractersticas probadas por el argumento

Autenticacin de inicio de sesin en el sistema. Carga y descarga de los registros de pacientes especficos a un ordenador porttil. Iniciar la programacin de las visitas medicas. El encriptado y descifrado de los registros de pacientes en un dispositivo mvil. Registro de la recuperacin y modificacin. Los vnculos con la base de datos de los medicamentos que mantienen la informacin de los efectos secundarios. El sistema de consultas por llamada.

 Kate es una enfermera que se especializa en el cuidado de la salud mental. Una de sus responsabilidades es la de visitar a los pacientes en sus casas para comprobar que su tratamiento sea efectivo y que no estn sufriendo de los efectos secundarios de la medicacin. En un da de visitas a los hogares, Kate se registra en el sistema y lo utiliza para imprimir su horario de visitas a domicilio para un da en especifico, junto con la informacin acerca de los pacientes que se visitan. Ella pide que los registros de estos pacientes se pueda descargar a su computadora porttil. Ella se crea una clave para descargar los archivos en su computadora. Uno de los pacientes que ella visita es Jim, que est siendo tratado con medicamentos para la depresin. Jim siente que el medicamento lo est ayudando, pero cree que tiene uno de los efecto secundarios que es mantenerlo despierto por la noche. Kate mira el registro de Jim y se le solicita su clave para desencriptar el registro de Jim.

 Ella revisa el medicamento prescrito y consulta sus efectos secundarios. El insomnio es un efecto secundario conocido as que toma nota del problema en el registro de Jim y le sugiere que visite la clnica para que cambie su medicacin. Jim est de acuerdo con que Kate lo ingrese en el sistema el cual lo llamara cuando regrese a la clnica para hacer una cita con un mdico. Ella termina la consulta y el sistema vuelve a encriptar el registro de Jim. Despus, terminando sus consultas, Kate regresa a la clnica y carga los registros de los pacientes que se visitaron deacuerdo a la base de datos. El sistema genera una lista de llamadas para Kate de los pacientes con los que ella tiene que ponerse en contacto para obtener informacin de seguimiento y hacer citas en la clnica.

Pruebas de Rendimiento
Parte de las pruebas de emisin pueden implicar un anlisis de las propiedades emergentes de un sistema, como el rendimiento y la fiabilidad. Las pruebas de rendimiento por lo general implican la planificacin de una serie de pruebas en las que est en constante aumento su carga hasta que el rendimiento del sistema se vuelva inaceptable.

Las pruebas de tensin son una forma de pruebas de rendimiento, cuando es deliberadamente sobrecargado el sistema para comprobar si su comportamiento fracasa.

Pruebas de usuario
El usuario o cliente de este software entrar en una etapa en el proceso de prueba en el que los usuarios o clientes deben proporcionar informacin y recibir asesoramiento sobre las pruebas del sistema. Las pruebas de usuario son esenciales, incluso cuando el sistema esta completo y las pruebas de emisin se han llevado a cabo. La razn de esto es que las influencias del entorno de trabajo del usuario tienen un efecto importante en la fiabilidad, rendimiento, facilidad de uso y robustez de un sistema. Estos no pueden ser replicados en un entorno de pruebas.

55

Tipos de prueba de usuario

Prueba Alfa

Usuarios del sistema trabajan con el equipo de desarrollo para probar el software en lugar del desarrollador.
Prueba Beta Una versin de prueba del software es distribuida a los usuarios para permitirles experimentar con ella y reportar los problemas que descubran con los desarrolladores del software. Prueba de Aceptacin

Los usuarios prueban un sistema para decidir si este esta listo para para ser puesto en circulacin. Principalmente usado en sistemas acomodados a los pedidos del usuario.

Chapter 8 Software testing

56

Proceso de las Pruebas de Aceptacin

Capitulo 8: Pruebas de Software

57

Niveles en el proceso de prueba de aceptacin

Definir el criterio de aceptacin Planear las pruebas de aceptacin Derivar a las pruebas de aceptacin Realizar las pruebas de aceptacin Investigar los resultados Aceptar/Rechazar el sistema

Chapter 8 Software testing

58

Mtodos giles y pruebas de aceptacin

En los mtodos giles, el usuario es parte del equipo de desarrollo y es responsable de tomar decisiones sobre la aceptacin del sistema. Las pruebas son definidas por el usuario y son integradas con otras pruebas de modo que sean ejecutadas automticamente cuando se realiza cambios en el sistema. No hay un proceso separado de pruebas de aceptacin.

Chapter 8 Software testing

59

Puntos claves

Cuando se prueba el software, se debe de tratar de quebrarlo usando la experiencia o guas para elegir tipos de pruebas que han sido efectivas en descubrir defectos en otros sistemas. Siempre que sea posible, usted debe de escribir pruebas automticas. Estas pruebas son anexadas en un programa que se puede correr cada vez que un cambio sea hecho en el sistema.

El desarrollo de prueba-primero es un acercamiento donde las pruebas son escritas antes de el cdigo a ser probado.
La prueba de caractersticas involucra inventar una caracterstica tpica de uso y usarla para derivar casos de prueba.

Las pruebas de aceptacin son un proceso de prueba de usuario donde el objetivo es decidir si el software es lo suficientemente bueno para ser emitido y usado en su ambiente operacional.
Chapter 8 Software testing