De Wikipedia, la enciclopedia libre
Saltar a navegación Saltar a búsqueda

Prueba de aceptación de una catapulta de avión.
Seis de los espejos primarios del Telescopio Espacial James Webb en preparación para las pruebas de aceptación

En ingeniería y sus diversas subdisciplinas , la prueba de aceptación es una prueba realizada para determinar si se cumplen los requisitos de una especificación o contrato . Puede involucrar pruebas químicas , pruebas físicas o pruebas de rendimiento .

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

En las pruebas de software , la 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 satisface los criterios de aceptación [2] y para permitir al usuario, clientes u otra entidad autorizada determinar si acepta el sistema.

-  Glosario estándar de términos utilizados en las pruebas de software [3] : 2

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 impulsado por 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. [4]

Se puede utilizar una prueba de humo como prueba de aceptación antes de introducir una compilación de software en el proceso de prueba principal. [ no verificado en el cuerpo ]

Resumen [ editar ]

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. [5] 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; incluida la implementación correcta, la identificación de errores, la verificación de la calidad y otros detalles valiosos. [5] El entorno de prueba generalmente está diseñado para ser idéntico, o lo más cercano posible, al entorno de producción previsto. Incluye todas las instalaciones, hardware, software, firmware, procedimientos y / o documentación destinados o utilizados para realizar pruebas de software. [5]

Los casos de prueba de UAT y OAT se derivan idealmente en colaboración con clientes comerciales, analistas comerciales, probadores y desarrolladores. Es esencial 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 logran con éxito sus criterios de aceptación, los interesados ​​se sienten seguros de que el desarrollo avanza en la dirección correcta. [6]

  • Los criterios de la prueba de aceptación del usuario (UAT) (en el desarrollo de software ágil ) generalmente los crean los clientes comerciales y se expresan en un lenguaje de dominio comercial . Estas son pruebas de alto nivel para verificar la integridad de una historia de usuario o historias 'reproducidas' durante cualquier sprint / iteración.
  • Los criterios de la prueba de aceptación operativa (OAT) (independientemente de si se utiliza un desarrollo ágil, iterativo o secuencial) se definen en términos de requisitos funcionales y no funcionales; cubriendo atributos de calidad clave de estabilidad funcional , portabilidad y confiabilidad .

Proceso [ editar ]

Es posible que la serie de pruebas de aceptación deba realizarse varias veces, ya que es posible que no todos los casos de prueba se ejecuten en una única iteración de prueba. [7]

El conjunto de pruebas de aceptación se ejecuta utilizando procedimientos de prueba de aceptación predefinidos para indicar a los evaluadores qué datos utilizar, 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. [7] Si los resultados reales coinciden con los resultados esperados para cada caso de prueba, se dice que el caso de prueba pasa. 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 es así, el sistema puede ser rechazado o aceptado en condiciones previamente acordadas entre el patrocinador y el fabricante.

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

  • 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 brindar confianza en 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 una satisfacción de los requisitos definidos (previamente acordados entre la empresa y el proveedor / desarrollador del producto). .

Prueba de aceptación del usuario [ editar ]

Las pruebas de aceptación del usuario (UAT) consisten en un proceso de verificación de que una solución funciona para el usuario. [8] No se trata de una prueba del sistema (garantizar que el software no se bloquee 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 ser realizada por un experto en la materia (SME), preferiblemente el propietario o cliente de la solución bajo prueba, y debe proporcionar un resumen de los hallazgos para que la confirmación proceda después del ensayo o revisión. En el desarrollo de software , la 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 de acuerdo con lo que ocurriría en escenarios de la vida real. [9]

Es importante que los materiales entregados al probador sean similares a los materiales que tendrá el usuario final. Los evaluadores deben recibir escenarios de la vida real, como las tres tareas más comunes o difíciles que realizarán los usuarios que representan. [ cita requerida ]

El 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 como se requiere y sin problemas durante el uso normal, se puede extrapolar razonablemente el mismo nivel de estabilidad en la producción. [10]

Las pruebas de usuario, generalmente realizadas por clientes o usuarios finales, normalmente no se enfocan en identificar problemas cosméticos simples como errores ortográficos, ni en defectos llamativos , como fallas de software ; Los probadores y desarrolladores identifican y solucionan estos problemas durante las fases anteriores de pruebas unitarias , pruebas de integración y pruebas del sistema.

UAT debe ejecutarse en escenarios de prueba. [ cita requerida ] Los escenarios de prueba generalmente difieren de los casos de prueba funcionales o del sistema en que representan un viaje de "jugador" o "usuario". La amplia naturaleza del escenario de prueba asegura que el enfoque esté en el viaje y no en detalles técnicos o específicos del sistema, evitando los pasos de prueba "clic a 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 suelen ser donde cambia el actor (jugador / cliente / operador) o el sistema (backoffice, front-end). [ cita requerida ]

En la industria, un UAT común es una prueba de aceptación de fábrica (FAT). Esta prueba tiene lugar 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. Un FAT generalmente incluye una verificación de integridad, una verificación con respecto a los requisitos contractuales, una prueba de funcionalidad (ya sea por simulación o una prueba de funcionamiento convencional) y una inspección final. [11] [12]

Los resultados de estas pruebas dan a los clientes confianza en cómo funcionará el sistema en producción. También puede haber requisitos legales o contractuales para la aceptación del sistema.

Prueba de aceptación operativa [ editar ]

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 la 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 ser compatible y / o para convertirse en parte del entorno de producción.

Pruebas de aceptación en programación extrema [ editar ]

Las pruebas de aceptación es un término utilizado en las metodologías de desarrollo de software ágiles , en particular 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. [13]

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 exactitud de las pruebas de aceptación y de revisar las puntuaciones de las pruebas para decidir qué pruebas reprobadas tienen la máxima prioridad. Las pruebas de aceptación también se utilizan como pruebas de regresión antes de un lanzamiento de producción. Una historia de usuario no se considera completa hasta que ha pasado 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á un progreso cero. [14]

Tipos de pruebas de aceptación [ editar ]

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 mueva a su sitio de destino, después de lo cual los usuarios pueden realizar pruebas de aceptación del sitio (SAT) en el sitio. [15]
Prueba de aceptación operativa
También conocida como prueba de disponibilidad operativa, se refiere a la verificación realizada a un sistema para garantizar que los procesos y procedimientos estén en su lugar para permitir que el sistema se utilice y mantenga. Esto puede incluir verificaciones realizadas a las instalaciones de respaldo, procedimientos de recuperación ante desastres, capacitación para usuarios finales, procedimientos de mantenimiento y procedimientos de seguridad.
Pruebas de aceptación de contratos y regulaciones
En las pruebas de aceptación de contratos, un sistema se prueba con los criterios de aceptación documentados en un contrato, antes de que se acepte el sistema. En las pruebas de aceptación de regulaciones, un sistema se prueba para garantizar que cumpla con los estándares gubernamentales, legales y de seguridad.
Prueba de aceptación de fábrica
Pruebas de aceptación realizadas en el sitio en el que el producto es desarrollado y realizado por los empleados de la organización proveedora, para determinar si un componente o sistema satisface los requisitos, que normalmente incluyen tanto hardware como software. [dieciséis]
Pruebas alfa y beta
Las pruebas alfa se llevan a cabo en los sitios de los desarrolladores e implican pruebas del sistema operativo por parte del personal interno, antes de que se entregue a los clientes externos. Las pruebas beta se llevan a cabo en los sitios de los clientes e implican pruebas por parte de un grupo de clientes que usan el sistema en sus propias ubicaciones y brindan comentarios, antes de que el sistema se entregue a otros clientes. Este último se denomina a menudo "pruebas de campo".

Lista de marcos de pruebas de aceptación [ editar ]

  • Concordion , marco de especificación por ejemplo (SbE)
    • Concordion.NET, pruebas de aceptación en .NET
  • Pepino , un marco de prueba de aceptación de desarrollo impulsado por el comportamiento (BDD)
    • Capybara, marco de prueba de aceptación para aplicaciones web Ruby
    • Behat, marco de aceptación de BDD para PHP
    • Lettuce, marco de aceptación de BDD para Python
  • Fabasoft app.test para pruebas de aceptación automatizadas
  • Marco para la prueba integrada (ajuste)
    • FitNesse , un tenedor de Fit
  • Gauge (software) , marco de automatización de pruebas de Thoughtworks
  • iMacros
  • Marco web ItsNat Java Ajax con capacidades de prueba web funcionales integradas, basadas en servidor.
  • Maveryx Test Automation Framework para pruebas funcionales, pruebas de regresión, pruebas GUI, pruebas basadas en datos y sin código de aplicaciones web y de escritorio.
  • Mocha , un popular marco de pruebas de aceptación web basado en Javascript y Node.js
  • Ranorex
  • Marco de robot
  • Selenio
  • Especificación por ejemplo (Specs2)
  • Watir

Ver también [ editar ]

  • Muestreo de aceptacion
  • Piloto de sala de conferencias
  • Etapa de desarrollo
  • Pruebas dinámicas
  • Prueba de validación de ingeniería
  • Prueba de caja gris
  • Desarrollo impulsado por pruebas
  • Prueba de caja blanca
  • Pruebas funcionales (fabricación)

Referencias [ editar ]

  1. ^ Black, Rex (agosto de 2009). Gestión del proceso de prueba: herramientas y técnicas prácticas para la gestión de pruebas de hardware y software . Hoboken, Nueva Jersey: Wiley. ISBN 0-470-40415-9.
  2. ^ "criterios de aceptación" . Innolution, LLC. 10 de junio de 2019.
  3. ^ "Glosario estándar de términos utilizados en pruebas de software, versión 3.2: todos los términos" (PDF) . ISTQB . Consultado el 23 de noviembre de 2020 .
  4. ^ Norma internacional ISO / IEC / IEEE - Ingeniería de software y sistemas . ISO / IEC / IEEE. 2010. págs. Vol., No., Págs. 1-418.
  5. ^ a b c ISO / IEC / IEEE 29119-1-2013 Ingeniería de software y sistemas - Pruebas de software - Parte 1- Conceptos y definiciones . ISO . 2013 . Consultado el 14 de octubre de 2014 .
  6. ^ ISO / IEC / IEEE DIS 29119-4 Ingeniería de sistemas y software - Pruebas de software - Parte 4 - Técnicas de prueba . ISO . 2013 . Consultado el 14 de octubre de 2014 .
  7. ^ a b ISO / IEC / IEEE 29119-2-2013 Ingeniería de sistemas y software - Pruebas de software - Parte 2- Procesos de prueba . ISO . 2013 . Consultado el 21 de mayo de 2014 .
  8. ^ Cimperman, Rob (2006). Definición de UAT: una guía para las pruebas prácticas de aceptación del usuario . Educación Pearson. pp. Capítulo 2. ISBN 9780132702621.
  9. ^ Goethem, Brian; van Hambling, Pauline (2013). Prueba de aceptación del usuario: una guía paso a paso . BCS Learning & Development Limited. ISBN 9781780171678.
  10. ^ Pusuluri, Nageshwar Rao (2006). Herramientas y conceptos de pruebas de software . Prensa Dreamtech. pag. 62. ISBN 9788177227123.
  11. ^ "Prueba de aceptación de fábrica (FAT)" . Tuv.com. Archivado desde el original el 4 de febrero de 2013 . Consultado el 18 de septiembre de 2012 .
  12. ^ "Prueba de aceptación de fábrica" . Inspection-for-industry.com . Consultado el 18 de septiembre de 2012 .
  13. ^ "Introducción a las pruebas de aceptación / cliente como artefactos de requisitos" . agilemodeling.com . Modelado ágil . Consultado el 9 de diciembre de 2013 .
  14. ^ Wells, Don. "Pruebas de aceptación" . Extremeprogramming.org . Consultado el 20 de septiembre de 2011 .
  15. ^ Prasad, Durga (29 de marzo de 2012). "La diferencia entre un FAT y un SAT" . Kneat.com . Consultado el 27 de julio de 2016 .
  16. ^ "Glosario estándar ISTQB de términos utilizados en pruebas de software" . Consultado el 15 de marzo de 2019 .

Lectura adicional [ editar ]

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

Enlaces externos [ editar ]

  • Guía de ingeniería de pruebas de aceptación de patrones y prácticas de Microsoft
  • " Uso de pruebas de clientes para impulsar el desarrollo " de Métodos y herramientas
  • " Aceptación TDD explicada " de Métodos y herramientas