Pruebas de aceptación

En ingeniería y sus diversas subdisciplinas , las pruebas de aceptación son pruebas que se realizan para determinar si se cumplen los requisitos de una especificación o contrato . Pueden incluir pruebas químicas , pruebas físicas o pruebas de rendimiento . ^{[ 1 ]}

En ingeniería de sistemas , puede implicar pruebas de caja negra realizadas en un sistema (por ejemplo: un programa informático , lotes de piezas mecánicas fabricadas o lotes de productos químicos) antes de su entrega. ^{[ 2 ]}

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

Pruebas formales con respecto a las necesidades, requisitos y procesos comerciales del usuario realizadas para determinar si un sistema cumple con los criterios de aceptación ^{[ 3 ]} y para permitir que el usuario, los clientes u otra entidad autorizada determinen si aceptan el sistema.

La prueba final del ciclo de vida de control de calidad, la prueba de aceptación del usuario, se realiza justo antes del lanzamiento final para evaluar si el producto o la aplicación pueden manejar escenarios del mundo real. Al replicar el comportamiento del usuario, se verifica si el sistema satisface los requisitos del negocio y se rechazan los cambios si no se cumplen ciertos criterios. ^{[ 5 ]}

Algunas formas de pruebas de aceptación son: pruebas de aceptación del usuario (UAT), pruebas de usuario final, pruebas de aceptación operativa (OAT), desarrollo guiado por pruebas de aceptación (ATDD) y pruebas de campo (de aceptación). Los criterios de aceptación son los criterios que un sistema o componente debe cumplir para ser aceptado por un usuario, cliente u otra entidad autorizada. ^{[ 6 ]}

Las pruebas son un conjunto de actividades realizadas para facilitar el descubrimiento y/o la evaluación de las propiedades de uno o más elementos bajo prueba. ^{[ 7 ]} Cada prueba, conocida como caso de prueba, ejecuta un conjunto de actividades de prueba predefinidas, desarrolladas para guiar la ejecución del elemento de prueba y cumplir con los objetivos de la prueba; incluyendo la implementación correcta, la identificación de errores, la verificación de la calidad y otros detalles valiosos. ^{[ 7 ]} El entorno de prueba generalmente se diseña 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 destinados o utilizados para realizar las pruebas de software. ^{[ 7 ]}

Los casos de prueba UAT y OAT se elaboran idealmente en colaboración con clientes, analistas de negocio, evaluadores y desarrolladores. Estas pruebas deben incluir tanto pruebas de lógica de negocio como de condiciones del entorno operativo. Los clientes (propietarios del producto) son los principales interesados ​​en estas pruebas. A medida que las condiciones de prueba cumplen con éxito sus criterios de aceptación, los interesados ​​tienen la certeza de que el desarrollo avanza en la dirección correcta. ^{[ 8 ]}

• Los criterios de las pruebas de aceptación del usuario (UAT, por sus siglas en inglés) (en el desarrollo ágil de software ) suelen ser creados por los clientes y expresados ​​en un lenguaje propio del dominio empresarial . Se trata de pruebas de alto nivel para verificar la completitud de una o varias historias de usuario ejecutadas durante un sprint o iteración.
• Los criterios de las pruebas de aceptación operativa (OAT, por sus siglas en inglés) (independientemente de si se utiliza desarrollo ágil, iterativo o secuencial) se definen en términos de requisitos funcionales y no funcionales ; abarcando atributos clave de calidad como la estabilidad funcional , la portabilidad y la fiabilidad .

Es posible que sea necesario realizar el conjunto de pruebas de aceptación varias veces, ya que no todos los casos de prueba se pueden ejecutar en una sola iteración de prueba. ^{[ 9 ]}

El conjunto de pruebas de aceptación se ejecuta utilizando procedimientos de prueba de aceptación predefinidos que guían a los evaluadores sobre qué datos usar, los procesos paso a paso a seguir y el resultado esperado tras la ejecución. Los resultados reales se conservan para compararlos con los resultados esperados. ^{[ 9 ]} Si los resultados reales coinciden con los resultados esperados para cada caso de prueba, se dice que el caso de prueba se aprueba. Si la cantidad de casos de prueba que no se aprueban no supera el umbral predeterminado del proyecto, se dice que el conjunto de pruebas se aprueba. Si lo supera, el sistema puede ser rechazado o aceptado según las condiciones previamente acordadas entre el patrocinador y el fabricante.

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

• Los casos de prueba se ejecutan utilizando datos predeterminados.
• Se registran los resultados reales.
• Se comparan los resultados reales y esperados, y
• Se determinan los resultados de la prueba.

El objetivo es garantizar que el producto desarrollado cumpla con los requisitos funcionales y no funcionales. La finalidad de las pruebas de aceptación es que, una vez finalizadas y siempre que se cumplan los criterios de aceptación, los patrocinadores aprueben el desarrollo o la mejora del producto, confirmando que cumple con los requisitos definidos (previamente acordados entre la empresa y el proveedor o desarrollador del producto).

Las pruebas de aceptación del usuario (UAT) consisten en un proceso para verificar que una solución funcione para el usuario. ^{[ 10 ]} No se trata de pruebas del sistema (que garantizan que el software no falle y cumpla con los requisitos documentados), sino que aseguran que la solución funcione para el usuario (es decir, prueban que el usuario acepta la solución); los proveedores de software a menudo se refieren a esto como "pruebas beta".

Estas pruebas deben ser realizadas por el usuario final previsto o por un experto en la materia (SME), preferiblemente el propietario o cliente de la solución que se está probando, y proporcionar un resumen de los resultados para su confirmación y posterior revisión. En el desarrollo de software , las UAT, como una de las etapas finales de un proyecto, suelen tener lugar antes de que el cliente acepte el nuevo sistema. Los usuarios del sistema realizan pruebas que simulan situaciones reales. ^{[ 11 ]}

Los materiales que se le entreguen al evaluador deben ser similares a los que tendrá el usuario final. A los evaluadores se les deben presentar escenarios de la vida real, como las tres tareas más comunes o difíciles que realizarán los usuarios que representan. ^{[ 12 ]}

La UAT actúa como una verificación final de la funcionalidad empresarial requerida y el correcto funcionamiento del sistema, emulando condiciones del mundo real en nombre del cliente de pago o de un cliente importante 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. ^{[ 13 ]}

Las pruebas de usuario, que suelen realizar los clientes o los usuarios finales, no se centran normalmente en identificar problemas estéticos sencillos, como errores ortográficos, ni defectos críticos , como fallos del software ; los evaluadores y desarrolladores identifican y corrigen estos problemas durante las fases anteriores de pruebas unitarias , pruebas de integración y pruebas del sistema.

Las UAT deben ejecutarse contra escenarios de prueba. ^{[ 14 ] [ 15 ]} Los escenarios de prueba generalmente difieren de los casos de prueba de sistema o funcionales en que representan un recorrido del "jugador" o "usuario". La naturaleza amplia del escenario de prueba garantiza que el enfoque esté en el recorrido y no en detalles técnicos o específicos del sistema, evitando los pasos de prueba "clic por clic" para permitir una variación en el comportamiento de los usuarios. Los escenarios de prueba se pueden dividir en "días" lógicos, que generalmente son aquellos en los que cambia el actor (jugador/cliente/operador) o el sistema (backoffice, front end). ^{[ 16 ]}

En la industria, una UAT común es la prueba de aceptación en fábrica (FAT). Esta prueba se realiza antes de la instalación del equipo. Generalmente, los evaluadores no solo verifican que el equipo cumpla con las especificaciones, sino también que sea completamente funcional. Una FAT suele incluir una verificación de integridad, una comprobación de cumplimiento con los requisitos contractuales, una prueba de funcionalidad (ya sea mediante simulación o una prueba de funcionamiento convencional) y una inspección final. ^{[ 17 ]} Los resultados de estas pruebas brindan a los clientes confianza en el rendimiento del sistema en producción. También pueden existir requisitos legales o contractuales para la aceptación del sistema.

Las pruebas de aceptación operativa (OAT) se utilizan para evaluar la preparación operativa (previa al lanzamiento) de un producto, servicio o sistema como parte de un sistema de gestión de calidad . Las OAT son un tipo común de prueba de software no funcional , utilizada principalmente en proyectos de desarrollo y mantenimiento de software . Este tipo de prueba se centra en la preparación operativa del sistema para su soporte y/o integración en el entorno de producción. ^{[ 18 ]}

Las pruebas de aceptación son un término utilizado en las metodologías de desarrollo de software ágil , en particular en la programación extrema , que se refiere a las pruebas funcionales de una historia de usuario por parte del equipo de desarrollo de software durante la fase de implementación. ^{[ 19 ]}

El cliente especifica los escenarios a probar cuando una historia de usuario se ha implementado correctamente. Una historia puede tener una o varias pruebas de aceptación, según sea necesario para garantizar que la funcionalidad funcione. Las pruebas de aceptación son pruebas de sistema de caja negra. Cada prueba de aceptación representa un resultado esperado del sistema. Los clientes son responsables de verificar la corrección de las pruebas de aceptación y revisar las puntuaciones para decidir qué pruebas fallidas tienen la máxima prioridad. Las pruebas de aceptación también se utilizan como pruebas de regresión antes de un lanzamiento a producción. Una historia de usuario no se considera completa hasta que haya superado sus pruebas de aceptación. Esto significa que se deben crear nuevas pruebas de aceptación para cada iteración, o el equipo de desarrollo informará de un progreso nulo. ^{[ 20 ]}

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 en 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 lo cual los usuarios pueden realizar pruebas de aceptación en el sitio (SAT) en el sitio. ^{[ 21 ]}

Pruebas de aceptación operativa

También conocida como prueba de preparación operativa, se refiere a la verificación que se realiza a un sistema para asegurar que existan procesos y procedimientos que permitan su uso y mantenimiento. Esto puede incluir verificaciones de las instalaciones de respaldo, procedimientos de recuperación ante desastres, capacitación para usuarios finales, procedimientos de mantenimiento y procedimientos de seguridad. ^{[ 22 ]}

Pruebas de aceptación de contratos y reglamentos

En las pruebas de aceptación contractual, un sistema se prueba según los criterios de aceptación documentados en el contrato, antes de su aceptación. En las pruebas de aceptación regulatoria, un sistema se prueba para garantizar que cumpla con las normas gubernamentales, legales y de seguridad. ^{[ 23 ]}

Pruebas de aceptación en fábrica

Las pruebas de aceptación se realizan en el lugar donde se desarrolla el producto y son llevadas a cabo por empleados de la organización proveedora para determinar si un componente o sistema cumple con los requisitos, que normalmente incluyen tanto hardware como software. ^{[ 24 ]}

Pruebas alfa y beta

Las pruebas alfa se realizan en las instalaciones de los desarrolladores e implican que el personal interno pruebe el sistema operativo antes de su lanzamiento a clientes externos. Las pruebas beta se realizan en las instalaciones de los clientes e implican que un grupo de clientes pruebe el sistema en sus propias ubicaciones y proporcione comentarios antes de que el sistema se lance a otros clientes. Estas últimas se denominan a menudo "pruebas de campo". ^{[ 25 ]}

Según el Project Management Institute , los criterios de aceptación son un "conjunto de condiciones que deben cumplirse antes de que se acepten los entregables". ^{[ 26 ]} Los requisitos que se encuentran en los criterios de aceptación para un componente determinado del sistema suelen ser muy detallados. ^{[ 27 ]}

• Concordion , marco de especificación por ejemplo (SbE)
  • Concordion.NET, pruebas de aceptación en .NET
• Cucumber , un marco de pruebas de aceptación para el desarrollo basado en el comportamiento (BDD).
  • Capybara, marco de pruebas de aceptación para aplicaciones web Ruby
  • Behat, marco de aceptación BDD para PHP
  • Lettuce, marco de aceptación BDD para Python
• Ciprés
• Marco para la prueba integrada (Ajuste)
  • FitNesse , una bifurcación de Fit
• Gauge (software) , marco de automatización de pruebas de Thoughtworks
• iMacros
• Mocha , un popular framework de pruebas de aceptación web basado en Javascript y Node.js.
• Dramaturgo (software)
• Ranorex
• Robot Framework
• Selenio
• Especificación por ejemplo (Specs2)
• Watir

• Muestreo de aceptación
• piloto de sala de conferencias
• Etapa de desarrollo
• Pruebas dinámicas
• Prueba de validación de ingeniería
• Pruebas de caja gris
• desarrollo guiado por pruebas
• Pruebas de caja blanca
• Pruebas funcionales (fabricación)

• Guía de los fundamentos de la gestión de proyectos (Guía PMBOK) (7.ª  ed.). Newtown Square, PA: Project Management Institute. 2021. ISBN 978-1-62825-664-2.

• Hambling, Brian; van Goethem, Pauline (2013). Pruebas de aceptación del usuario: una guía paso a paso . Swindon: BCS Learning and Development Ltd. ISBN 978-1-78017-167-8.

• Guía de ingeniería de pruebas de aceptación archivada el 23 de diciembre de 2017 en Wayback Machine por Microsoft patterns & practices
• " Utilizando las pruebas de los clientes para impulsar el desarrollo " de Methods & Tools