tipos - testing de software ejemplos
¿Diferencia entre la prueba de aceptación y la prueba funcional? (11)
En mi mundo, usamos los términos de la siguiente manera:
prueba funcional : esta es una actividad de verificación ; construimos un producto que funciona correctamente? ¿El software cumple con los requisitos del negocio?
Para este tipo de pruebas, tenemos casos de prueba que cubren todos los escenarios posibles que podemos pensar, incluso si ese escenario es poco probable que exista "en el mundo real". Al realizar este tipo de pruebas, buscamos una máxima cobertura de código. Usamos cualquier entorno de prueba que podamos capturar en ese momento, no tiene que ser 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 prueba usamos casos de prueba que cubren los escenarios típicos bajo los cuales esperamos que se use el software. Esta prueba debe llevarse a cabo en un entorno "similar a la producción", en hardware que sea igual o cercano a lo que usará un cliente. Esto es cuando probamos nuestras "ilidades":
Confiabilidad, disponibilidad : Validado a través de una prueba de estrés.
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 conocido como Securability, solo para encajar) : Validado por demostración. En ocasiones, un cliente contratará a una empresa externa para que realice una auditoría de seguridad y / o pruebas de intrusión.
Mantenibilidad : Validado a través de la demostración de cómo entregaremos actualizaciones / parches de software.
Configurabilidad : Validado a través de 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 contradictorias aquí. Lo más importante para su organización es que defina estos términos de manera precisa y se adhiera a ellos.
¿Cuál es la diferencia real entre las pruebas de aceptación y las pruebas funcionales?
¿Cuáles son los aspectos más destacados o los objetivos de cada uno? En todas partes que leo, son ambiguamente similares.
Ellos son la misma cosa.
La prueba de aceptación se realiza en el sistema completo de la manera más idéntica posible al entorno real de producción / implementación antes de desplegar o entregar el sistema.
Puede hacer pruebas de aceptación de manera automática o manual.
En mi opinión, la principal diferencia es quién dice si las pruebas tienen éxito o fracasan.
Una prueba funcional prueba que el sistema cumple con los requisitos predefinidos. Lo llevan a cabo y controlan 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 puesta de sol de una prueba funcional ya que los usuarios no invierten suficiente tiempo. Tenga en cuenta que esta vista es de los usuarios comerciales 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,
... se realizan pruebas de caja negra en un sistema (por ejemplo, software, muchas piezas mecánicas fabricadas o lotes de productos químicos) antes de su entrega.
Aunque esto continúa para decir:
También se lo conoce como pruebas funcionales, pruebas de caja negra, aceptación de versiones, pruebas de control de calidad, pruebas de aplicaciones, pruebas de confianza, pruebas finales, pruebas de validación o pruebas de aceptación en fábrica.
con una marca de "cita requerida".
Prueba funcional (que en realidad redirige a las Pruebas del sistema):
conducido en un sistema completo e integrado para evaluar el cumplimiento del sistema con sus requisitos específicos. Las pruebas del sistema caen dentro del alcance de las pruebas de caja negra, y como tal, no deberían requerir conocimiento del diseño interno del código o la lógica.
Entonces, a partir de esta definición, son más o menos lo mismo.
En mi experiencia, la prueba de aceptación suele ser un subconjunto de las pruebas funcionales y el cliente la utiliza en el proceso formal de cierre de sesión, mientras que las pruebas funcionales / del sistema son las que realiza el departamento de desarrollador / QA.
Prueba Funcional: 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: Pruebas formales realizadas para determinar si un sistema cumple o no con sus criterios de aceptación: permite que un usuario final determine si acepta o no el sistema.
Audiencia. Las pruebas funcionales son 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 la pena o el tiempo que le tomará probarlo para determinar su aceptabilidad).
El software puede pasar pruebas funcionales, pruebas de integración y pruebas del sistema; solo para fallar las pruebas de aceptación cuando el cliente descubre que las características simplemente no satisfacen sus necesidades. Esto generalmente implicaría que alguien arruinó la especificación. El software también puede fallar algunas pruebas funcionales, pero pasar las pruebas 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 aceptablemente (el software beta a menudo será aceptado por un subconjunto de usuarios antes de que es completamente funcional).
La diferencia es 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 resolvió el problema. Esta es una parte integral del desarrollo de software, comparable a las pruebas que se realizan en productos de producción masiva antes de que salga de la fábrica. Una prueba funcional verifica que el producto realmente funciona como usted (el desarrollador) piensa que lo hace.
Las pruebas de aceptación verifican que el producto realmente resuelve el problema para el cual fue creado. Esto puede hacerse mejor por el usuario (cliente), por ejemplo, realizando sus tareas con las que el software asiste. 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, verificando que tiene las cualidades que ha diseñado o construido (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 en el (los) problema (s) original (es).
La respuesta es opinión. Trabajé en muchos proyectos y soy testmanager y issuemanager y los diferentes roles y las descripciones en varios libros difieren así que aquí está mi variación:
pruebas funcionales: tome los requisitos del negocio y pruebe todo bien y exhaustivamente desde un punto de vista funcional.
Prueba de aceptación: el cliente "que paga" realiza 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 las 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 de negocios que prueba la cosa.
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 variedad de estimulación (dentro del alcance de la prueba) lo que típicamente produce el entorno objetivo o incluso más allá, mientras 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 pasaron la prueba de fabricación. Diferentes consumidores pueden probar el diseño de diferentes maneras.
Las pruebas de aceptación se conocen como verificación cuando el diseño se prueba en función de la especificación del producto, y las pruebas de aceptación se denominan como validación, cuando el producto se coloca en el entorno real del consumidor.
La prueba de aceptación es solo una prueba llevada a cabo por el cliente, e incluye otros tipos de pruebas:
- Pruebas funcionales: "este botón no funciona"
- Prueba no funcional: "esta página funciona pero es demasiado lenta"
Para pruebas funcionales versus pruebas no funcionales (sus subtipos), vea mi respuesta a esta pregunta SO .
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 de desarrollo.
- prueba componente / unidad => verificar diseño detallado
- prueba de integración de componentes / unidades => verificación del diseño global
- prueba del sistema => verificar los requisitos del sistema
- prueba de integración del sistema => verificación de los requisitos del sistema
- prueba de aceptación => validación de los requisitos del usuario
tipos de prueba
Un tipo de prueba es una característica, se centra en un objetivo de prueba específico. Los tipos de prueba hacen hincapié en 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 usar como tipos de prueba las características de calidad mencionadas en ISO / IEC 25010: 2011.
- pruebas funcionales
- prueba de confiabilidad
- pruebas de rendimiento
- prueba de operabilidad
- prueba de seguridad
- prueba de compatibilidad
- prueba de mantenimiento
- prueba de transferibilidad
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 el tiempo para repetir todas las pruebas. Las pruebas de regresión son una respuesta a eso.