En mi mundo, usamos los términos de la siguiente manera:
prueba funcional : esta es una actividad de verificación ; ¿Creamos un producto que funcione correctamente? ¿El software cumple con los requisitos comerciales?
Para este tipo de pruebas, tenemos casos de prueba que cubren todos los escenarios posibles en los que podemos pensar, incluso si ese escenario es poco probable que exista "en el mundo real". Al realizar este tipo de pruebas, buscamos la máxima cobertura de código. Utilizamos cualquier entorno de prueba que podamos tomar en ese momento, no tiene que ser calibre de "producción", siempre que sea utilizable.
prueba de aceptación : esta es una actividad de validación ; ¿Construimos lo correcto? ¿Es esto lo que el cliente realmente necesita?
Esto generalmente se hace en cooperación con el cliente, o por un proxy interno del cliente (propietario del producto). Para este tipo de pruebas, utilizamos casos de prueba que cubren los escenarios típicos en los que esperamos que se utilice el software. Esta prueba debe llevarse a cabo en un entorno "similar a la producción", en hardware que sea igual o similar al que utilizará un cliente. Esto es cuando probamos nuestras "ilities":
Fiabilidad, disponibilidad : validado a través de una prueba de esfuerzo.
Escalabilidad : Validado a través de una prueba de carga.
Usabilidad : Validado a través de una inspección y demostración al cliente. ¿La interfaz de usuario está configurada a su gusto? ¿Pusimos la marca del cliente en todos los lugares correctos? ¿Tenemos todos los campos / pantallas que pidieron?
Seguridad (también conocida como asegurabilidad, solo para encajar) : validada mediante demostración. A veces, un cliente contratará a una empresa externa para realizar una auditoría de seguridad y / o pruebas de intrusión.
Mantenimiento : validado mediante la demostración de cómo entregaremos actualizaciones / parches de software.
Configurabilidad : Validado mediante la demostración de cómo el cliente puede modificar el sistema para satisfacer sus necesidades.
Esto de ninguna manera es estándar, y no creo que haya una definición "estándar", como lo demuestran las respuestas en conflicto aquí. Lo más importante para su organización es que defina estos términos con precisión y se adhiera a ellos.
Me gusta la respuesta de Patrick Cuff. Lo que me gusta agregar es la distinción entre un nivel de prueba y un tipo de prueba que fue para mí una revelación.
niveles de prueba
El nivel de prueba es fácil de explicar usando el modelo V , un ejemplo:
cada nivel de prueba tiene su nivel de desarrollo correspondiente . Tiene una característica de tiempo típica, se ejecutan en cierta fase del ciclo de vida del desarrollo.
tipos de prueba
Un tipo de prueba es una característica, se enfoca en un objetivo de prueba específico. Los tipos de prueba enfatizan sus aspectos de calidad, también conocidos como aspectos técnicos o no funcionales. Los tipos de prueba se pueden ejecutar en cualquier nivel de prueba . Me gusta utilizar como tipos de prueba las características de calidad mencionadas en ISO / IEC 25010: 2011.
Para hacerlo completo. También hay algo llamado prueba de regresión . Esta es una clasificación adicional junto al nivel de prueba y el tipo de prueba . Una prueba de regresión es una prueba que desea repetir porque toca algo crítico en su producto. De hecho, es un subconjunto de pruebas que definió para cada nivel de prueba . Si hay una pequeña corrección de errores en su producto, uno no siempre tiene tiempo para repetir todas las pruebas. La prueba de regresión es una respuesta a eso.
fuente
La diferencia está entre probar el problema y la solución. El software es una solución a un problema, ambos pueden ser probados.
La prueba funcional confirma que el software realiza una función dentro de los límites de cómo ha resuelto el problema. Esta es una parte integral del desarrollo de software, comparable a las pruebas que se realizan en un producto producido en masa antes de que salga de la fábrica. Una prueba funcional verifica que el producto realmente funciona como usted (el desarrollador) cree que lo hace.
Las pruebas de aceptación verifican que el producto realmente resuelve el problema para el que fue creado. Esto lo puede hacer mejor el usuario (cliente), por ejemplo, realizando sus tareas con las que ayuda el software. Si el software pasa esta prueba del mundo real, se acepta reemplazar la solución anterior. Esta prueba de aceptación a veces solo se puede realizar correctamente en producción, especialmente si tiene clientes anónimos (por ejemplo, un sitio web). Por lo tanto, una nueva característica solo se aceptará después de días o semanas de uso.
Pruebas funcionales : pruebe el producto y verifique que tenga las cualidades que ha diseñado o creado (funciones, velocidad, errores, consistencia, etc.)
Prueba de aceptación : pruebe el producto en su contexto, esto requiere (simulación) de la interacción humana, pruebe que tiene el efecto deseado sobre el problema o los problemas originales.
fuente
La respuesta es la opinión. Trabajé en muchos proyectos y como administrador de pruebas y administrador de problemas y todos los roles diferentes y las descripciones en varios libros difieren, así que aquí está mi variación:
prueba funcional: tome los requisitos comerciales y pruébelos todos desde un punto de vista funcional.
prueba de aceptación: el cliente "que paga" hace las pruebas que le gusta hacer para poder aceptar el producto entregado. Depende del cliente, pero generalmente las pruebas no son tan exhaustivas como las pruebas funcionales, especialmente si se trata de un proyecto interno porque las partes interesadas revisan y confían en los resultados de las pruebas realizadas en fases de prueba anteriores.
Como dije, este es mi punto de vista y experiencia. La prueba funcional es sistemática y la prueba de aceptación es más bien el departamento comercial que prueba la cosa.
fuente
Audiencia. La prueba funcional es para asegurar a los miembros del equipo que produce el software que hace lo que esperan. La prueba de aceptación es para asegurar al consumidor que satisface sus necesidades.
Alcance. Las pruebas funcionales solo prueban la funcionalidad de un componente a la vez. Las pruebas de aceptación cubren cualquier aspecto del producto que le importe al consumidor lo suficiente como para probarlo antes de aceptar el software (es decir, cualquier cosa que valga el tiempo o el dinero que tomará probarlo para determinar su aceptabilidad).
El software puede pasar pruebas funcionales, pruebas de integración y pruebas de sistema; solo para suspender las pruebas de aceptación cuando el cliente descubre que las funciones simplemente no satisfacen sus necesidades. Esto generalmente implicaría que alguien se equivocó en la especificación. El software también puede fallar en algunas pruebas funcionales, pero pasa la prueba de aceptación porque el cliente está dispuesto a lidiar con algunos errores funcionales siempre que el software haga las cosas básicas que necesita de manera aceptable (el software beta a menudo será aceptado por un subconjunto de usuarios antes de hacerlo). Es completamente funcional).
fuente
Pruebas funcionales: aplicación de datos de prueba derivados de los requisitos funcionales especificados sin tener en cuenta la estructura final del programa. También conocido como prueba de caja negra.
Pruebas de aceptación: las pruebas formales realizadas para determinar si un sistema cumple o no con sus criterios de aceptación, permite al usuario final determinar si acepta o no el sistema.
fuente
En mi opinión, la principal diferencia es quién dice si las pruebas tienen éxito o no.
Una prueba funcional prueba que el sistema cumple con los requisitos predefinidos. Es llevado a cabo y verificado por las personas responsables del desarrollo del sistema.
Los usuarios firman una prueba de aceptación. Idealmente, los usuarios dirán lo que quieren probar, pero en la práctica es probable que sea una suspensión de una prueba funcional ya que los usuarios no invierten suficiente tiempo. Tenga en cuenta que esta vista es de los usuarios comerciales con los que trato con otros grupos de usuarios, por ejemplo, la aviación y otros aspectos críticos de seguridad podrían no tener esta diferencia,
fuente
Prueba de aceptación :
Aunque esto continúa diciendo:
con una marca de "cita requerida".
Pruebas funcionales (que en realidad redirigen a Pruebas del sistema):
Entonces, desde esta definición, son más o menos lo mismo.
En mi experiencia, las pruebas de aceptación suelen ser un subconjunto de las pruebas funcionales y el cliente las utiliza en el proceso formal de cierre de sesión, mientras que las pruebas funcionales / del sistema serán las realizadas por el departamento de desarrollo / control de calidad.
fuente
La relación entre los dos: la prueba de aceptación generalmente incluye pruebas funcionales, pero puede incluir pruebas adicionales. Por ejemplo, verificar los requisitos de etiquetado / documentación.
La prueba funcional es cuando el producto bajo prueba se coloca en un entorno de prueba que puede producir una variedad de estimulación (dentro del alcance de la prueba) de lo que el entorno objetivo normalmente produce o incluso más allá, mientras se examina la respuesta del dispositivo bajo prueba.
Para un producto físico (no software) hay dos tipos principales de pruebas de aceptación : pruebas de diseño y pruebas de fabricación. Las pruebas de diseño generalmente usan una gran cantidad de muestras de productos, que han pasado la prueba de fabricación. Diferentes consumidores pueden probar el diseño de diferentes maneras.
Las pruebas de aceptación se denominan verificación cuando el diseño se prueba según las especificaciones del producto, y las pruebas de aceptación se denominan validación, cuando el producto se coloca en el entorno real del consumidor.
fuente
Las pruebas de aceptación son solo pruebas realizadas por el cliente e incluyen otros tipos de pruebas:
Para pruebas funcionales versus pruebas no funcionales (sus subtipos), vea mi respuesta a esta pregunta SO .
fuente
Ellos son la misma cosa.
La prueba de aceptación se realiza en el sistema completo de la forma más idéntica posible al entorno real de producción / implementación antes de que el sistema se implemente o entregue.
Puede realizar pruebas de aceptación de manera automatizada o manual.
fuente