Test de aceptación

Pruebas de aceptación de una catapulta de aeronave

Seis de los espejos primarios del telescopio espacial James Webb que se preparan para la prueba de aceptación

En ingeniería y sus diversas subdisciplinas, las pruebas de aceptación son pruebas realizadas para determinar si se cumplen los requisitos de una especificación o contrato. Puede incluir pruebas químicas, pruebas físicas o pruebas de rendimiento.

En ingeniería de sistemas, puede implicar la realización de pruebas de caja negra en un sistema (por ejemplo: una pieza de software, muchas piezas mecánicas fabricadas o lotes de productos químicos) antes de su entrega.

En las pruebas de software, el ISTQB define las pruebas de aceptación como:

Pruebas formales con respecto a las necesidades de los usuarios, requisitos y procesos de negocio realizados para determinar si un sistema cumple los criterios de aceptación y para permitir que el usuario, los clientes u otra entidad autorizada determine si aceptar el sistema.

—Glosario estándar de términos usados en pruebas de software

Las pruebas de aceptación también se conocen como pruebas de aceptación del usuario (UAT), pruebas de usuario final, pruebas de aceptación operativa (OAT), desarrollo basado en pruebas de aceptación (ATDD) o pruebas de campo (aceptación). Los criterios de aceptación son los criterios que un sistema o componente debe satisfacer para ser aceptado por un usuario, cliente u otra entidad autorizada.

Resumen

La prueba es un conjunto de actividades realizadas para facilitar el descubrimiento o la evaluación de las propiedades de uno o más elementos bajo prueba. Cada prueba individual, conocida como caso de prueba, ejerce un conjunto de actividades de prueba predefinidas, desarrolladas para impulsar la ejecución del elemento de prueba para cumplir con los objetivos de la prueba; incluyendo la implementación correcta, identificación de errores, verificación de calidad y otros detalles valiosos. El entorno de prueba suele estar diseñado para ser idéntico, o lo más parecido posible, al entorno de producción previsto. Incluye todas las instalaciones, hardware, software, firmware, procedimientos y/o documentación destinada o utilizada para realizar la prueba de software.

Los casos de prueba de UAT y OAT se derivan idealmente en colaboración con clientes comerciales, analistas comerciales, evaluadores y desarrolladores. Es fundamental que estas pruebas incluyan tanto pruebas de lógica empresarial como condiciones del entorno operativo. Los clientes comerciales (propietarios de productos) son los principales interesados en estas pruebas. A medida que las condiciones de prueba alcanzan con éxito sus criterios de aceptación, las partes interesadas se aseguran de que el desarrollo avanza en la dirección correcta.

• Los criterios de la prueba de aceptación del usuario (UAT) (en desarrollo de software ágil) suelen ser creados por clientes empresariales y expresados en un lenguaje de dominio empresarial. Estas son pruebas de alto nivel para verificar la integridad de una historia de usuario o historias 'jugadas' durante cualquier sprint/iteration.
• Los criterios de la prueba de aceptación operacional (OAT) (independientemente de si se utilizan el desarrollo ágil, iterativo o secuencial) se definen en términos de requisitos funcionales y no funcionales; cubriendo atributos clave de calidad de estabilidad funcional, portabilidad y fiabilidad.

Proceso

Es posible que el conjunto de pruebas de aceptación deba realizarse varias veces, ya que es posible que no se ejecuten todos los casos de prueba en una sola iteración de prueba.

El conjunto de pruebas de aceptación se ejecuta utilizando procedimientos de prueba de aceptación predefinidos para indicar a los probadores qué datos usar, los procesos paso a paso a seguir y el resultado esperado después de la ejecución. Los resultados reales se conservan para compararlos con los resultados esperados. Si los resultados reales coinciden con los resultados esperados para cada caso de prueba, se dice que pasa el caso de prueba. Si la cantidad de casos de prueba que no pasan no supera el umbral predeterminado del proyecto, se dice que el conjunto de pruebas pasa. Si lo hace, el sistema puede ser rechazado o aceptado en condiciones previamente acordadas entre el patrocinador y el fabricante.

El resultado anticipado de una ejecución de prueba exitosa:

• casos de prueba se ejecutan utilizando datos predeterminados
• los resultados efectivos se registran
• se comparan los resultados efectivos y previstos, y
• Los resultados de las pruebas se determinan.

El objetivo es brindar confianza de que el producto desarrollado cumple con los requisitos funcionales y no funcionales. El propósito de realizar las pruebas de aceptación es que, una vez completadas, y siempre que se cumplan los criterios de aceptación, se espera que los patrocinadores aprueben el desarrollo/mejora del producto como si cumpliera los requisitos definidos (previamente acordados entre la empresa y el proveedor/desarrollador del producto).

Pruebas de aceptación del usuario

La prueba de aceptación del usuario (UAT) consiste en un proceso de verificación de que una solución funciona para el usuario. No es una prueba del sistema (garantizar que el software no falle y cumpla con los requisitos documentados), sino que asegura que la solución funcionará para el usuario (es decir, prueba que el usuario acepta la solución); los proveedores de software a menudo se refieren a esto como "prueba beta".

Esta prueba debe llevarla a cabo un experto en la materia (SME), preferiblemente el propietario o cliente de la solución que se está probando, y debe proporcionar un resumen de los hallazgos para confirmarlos después de la prueba o revisión. En el desarrollo de software, UAT como una de las etapas finales de un proyecto a menudo ocurre antes de que un cliente acepte el nuevo sistema. Los usuarios del sistema realizan pruebas en línea con lo que ocurriría en escenarios de la vida real.

Es importante que los materiales entregados al probador sean similares a los materiales que tendrá el usuario final. A los probadores se les deben dar escenarios de la vida real, como las tres tareas más comunes o difíciles que realizarán los usuarios que representan.

La UAT actúa como una verificación final de la funcionalidad comercial requerida y el funcionamiento adecuado del sistema, emulando las condiciones del mundo real en nombre del cliente que paga o de un gran cliente específico. Si el software funciona según lo requerido y sin problemas durante el uso normal, se puede extrapolar razonablemente el mismo nivel de estabilidad en producción.

Las pruebas de usuario, que suelen realizar los clientes o los usuarios finales, normalmente no se centran en identificar problemas estéticos simples, como errores de ortografía, ni defectos importantes, como fallas de software; los evaluadores y desarrolladores identifican y solucionan estos problemas durante las fases anteriores de prueba de unidad, prueba de integración y prueba del sistema.

UAT debe ejecutarse en escenarios de prueba. Los escenarios de prueba suelen diferir de los casos de prueba de sistema o funcionales en que representan un "jugador" o "usuario" viaje. La naturaleza amplia del escenario de prueba garantiza que la atención se centre en el viaje y no en los detalles técnicos o específicos del sistema, evitando los "clic por clic" pasos de prueba para permitir una variación en los usuarios' comportamiento. Los escenarios de prueba se pueden dividir en "días" lógicos, que generalmente son donde cambia el actor (jugador/cliente/operador) o el sistema (back office, front-end).

En la industria, una UAT común es una prueba de aceptación de fábrica (FAT). Esta prueba se realiza antes de la instalación del equipo. La mayoría de las veces, los probadores no solo verifican que el equipo cumpla con las especificaciones, sino también que sea completamente funcional. Una FAT generalmente incluye una verificación de integridad, una verificación de los requisitos contractuales, una prueba de funcionalidad (ya sea por simulación o una prueba de funcionamiento convencional) y una inspección final.

Los resultados de estas pruebas brindan confianza a los clientes sobre el rendimiento del sistema en producción. También pueden existir requisitos legales o contractuales para la aceptación del sistema.

Pruebas de aceptación operativa

Las pruebas de aceptación operativa (OAT) se utilizan para llevar a cabo la preparación operativa (prelanzamiento) de un producto, servicio o sistema como parte de un sistema de gestión de calidad. OAT es un tipo común de prueba de software no funcional, que se utiliza principalmente en proyectos de desarrollo y mantenimiento de software. Este tipo de prueba se centra en la preparación operativa del sistema para recibir soporte y/o para convertirse en parte del entorno de producción.

Pruebas de aceptación en programación extrema

La prueba de aceptación es un término que se utiliza en las metodologías ágiles de desarrollo de software, particularmente en la programación extrema, y se refiere a la prueba funcional de una historia de usuario por parte del equipo de desarrollo de software durante la fase de implementación.

El cliente especifica escenarios para probar cuando una historia de usuario se ha implementado correctamente. Una historia puede tener una o varias pruebas de aceptación, lo que sea necesario para garantizar que la funcionalidad funcione. Las pruebas de aceptación son pruebas del sistema de caja negra. Cada prueba de aceptación representa algún resultado esperado del sistema. Los clientes son responsables de verificar la corrección de las pruebas de aceptación y revisar los puntajes de las pruebas para decidir qué pruebas fallidas son las de mayor prioridad. Las pruebas de aceptación también se utilizan como pruebas de regresión antes de una versión de producción. Una historia de usuario no se considera completa hasta que haya superado las pruebas de aceptación. Esto significa que se deben crear nuevas pruebas de aceptación para cada iteración o el equipo de desarrollo reportará un progreso cero.

Tipos de pruebas de aceptación

Los tipos típicos de pruebas de aceptación incluyen los siguientes

Pruebas de aceptación del usuario

Esto puede incluir pruebas de aceptación de fábrica (FAT), es decir, las pruebas realizadas por un proveedor antes de que el producto o sistema se traslade a su sitio de destino, después de las cuales las pruebas de aceptación del sitio (SAT) pueden ser realizadas por los usuarios en el sitio.

Pruebas de aceptación operacional

También conocido como pruebas de preparación operacional, esto se refiere a la comprobación realizada a un sistema para asegurar que los procesos y procedimientos estén en marcha para permitir que el sistema sea utilizado y mantenido. Esto puede incluir cheques realizados a las instalaciones de apoyo, procedimientos para la recuperación en casos de desastre, capacitación para usuarios finales, procedimientos de mantenimiento y procedimientos de seguridad.

Pruebas de aceptación de contratos y regulación

En las pruebas de aceptación de contratos, se prueba un sistema contra criterios de aceptación documentados en un contrato, antes de que se acepte el sistema. En las pruebas de aceptación reglamentaria, se prueba un sistema para garantizar que cumple con las normas gubernamentales, jurídicas y de seguridad.

Pruebas de aceptación de fábrica

Pruebas de aceptación realizadas en el sitio en el que el producto es desarrollado y realizado por empleados de la organización proveedora, para determinar si un componente o sistema satisface los requisitos, incluyendo normalmente hardware y software.

Pruebas de alfa y beta

Las pruebas alfa tienen lugar en los sitios de los desarrolladores, e implican la prueba del sistema operativo por parte del personal interno, antes de que sea liberado a clientes externos. Las pruebas de beta tienen lugar en los sitios de los clientes, e implican pruebas de un grupo de clientes que utilizan el sistema en sus propias ubicaciones y proporcionan comentarios, antes de que el sistema sea liberado a otros clientes. Este último se llama a menudo "prueba de campo".

Lista de marcos de pruebas de aceptación

• Concordion, Especificación por ejemplo (SbE) framework
  • Concordion. NET, pruebas de aceptación. NET
• Cucumber, un marco de prueba de desarrollo impulsado por el comportamiento (BDD)
  • Capybara, Marco de prueba de aceptación para aplicaciones web de Ruby
  • Behat, marco de aceptación BDD para PHP
  • Lechuga, marco de aceptación de BDD para Python
• Prueba Fabasoft para pruebas de aceptación automatizada
• Marco para el examen integrado (Fit)
  • FitNesse, un tenedor de Fit
• Gauge (software), Test Automation Framework from Thoughtworks
• iMacros
• ItsNat Java Ajax marco web con capacidades integradas, basadas en servidor, de pruebas web funcionales.
• Maveryx Test Automation Framework for functional testing, regression testing, GUI testing, data-driven and codeless testing of Desktop and Web applications.
• Mocha, un popular marco de prueba de aceptación web basado en Javascript y Nodo. js
• Ranorex
• Marco de Robot
• Selenio
• Especificación por ejemplo (Specs2)
• Watir