Différence entre test d'acceptation et test fonctionnel?

Quelle est la vraie différence entre les tests d'acceptation et les tests fonctionnels?

Quels sont les points forts ou les objectifs de chacun? Partout où je lis, ils sont similaires de manière ambiguë.

Dans mon monde, nous utilisons les termes comme suit:

test fonctionnel : il s'agit d'une activité de vérification ; avons-nous construit un produit qui fonctionne correctement? Le logiciel répond-il aux exigences de l'entreprise?

Pour ce type de test, nous avons des cas de test qui couvrent tous les scénarios possibles auxquels nous pouvons penser, même s'il est peu probable que ce scénario existe "dans le monde réel". Lors de ce type de test, nous visons une couverture maximale du code. Nous utilisons n'importe quel environnement de test que nous pouvons saisir à ce moment-là, il n'a pas besoin d'être de calibre "production", tant qu'il est utilisable.

tests d'acceptation : il s'agit d'une activité de validation ; avons-nous construit la bonne chose? Est-ce ce dont le client a vraiment besoin?

Cela se fait généralement en coopération avec le client ou par un proxy client interne (propriétaire du produit). Pour ce type de test, nous utilisons des cas de test qui couvrent les scénarios typiques dans lesquels nous prévoyons que le logiciel sera utilisé. Ce test doit être réalisé dans un environnement «de type production», sur du matériel identique ou proche de ce qu'un client utilisera. C'est alors que nous testons nos "ilities":

• Fiabilité, disponibilité : Validé via un test de résistance.

• Évolutivité : validée via un test de charge.

• Convivialité : Validé via une inspection et une démonstration au client. L'interface utilisateur est-elle configurée à leur goût? Avons-nous mis la marque du client aux bons endroits? Avons-nous tous les champs / écrans demandés?

• Sécurité (aka, Securability, juste pour s'intégrer) : Validé via démonstration. Parfois, un client embauche une société externe pour effectuer un audit de sécurité et / ou des tests d'intrusion.

• Maintenabilité : validée par une démonstration de la manière dont nous fournirons des mises à jour / correctifs logiciels.

• Configurabilité : validée par une démonstration de la façon dont le client peut modifier le système en fonction de ses besoins.

Ce n'est en aucun cas une norme, et je ne pense pas qu'il existe une définition «standard», comme le démontrent les réponses contradictoires ici. La chose la plus importante pour votre organisation est que vous définissiez ces termes avec précision et que vous vous y teniez.

J'aime la réponse de Patrick Cuff. Ce que j'aime ajouter, c'est la distinction entre un niveau de test et un type de test qui a été pour moi une révélation.

niveaux de test

Le niveau de test est facile à expliquer à l'aide du modèle en V , un exemple: chaque niveau de test a son niveau de développement correspondant . Il a une caractéristique de temps typique, ils sont exécutés à une certaine phase du cycle de vie du développement.

1. test des composants / unités => vérification de la conception détaillée
2. tests d'intégration composants / unités => vérification de la conception globale
3. test du système => vérification de la configuration système requise
4. test d'intégration système => vérification de la configuration système requise
5. test d'acceptation => validation des besoins des utilisateurs

types de test

Un type de test est une caractéristique, il se concentre sur un objectif de test spécifique. Les types de test mettent l'accent sur vos aspects de qualité, également appelés aspects techniques ou non fonctionnels. Les types de test peuvent être exécutés à n'importe quel niveau de test . J'aime utiliser comme types de test les caractéristiques de qualité mentionnées dans l'ISO / CEI 25010: 2011.

1. test fonctionel
2. test de fiabilité
3. Test de performance
4. test d'opérabilité
5. tests de sécurité
6. test de compatibilité
7. test de maintenabilité
8. test de transférabilité

Pour le rendre complet. Il y a aussi quelque chose appelé test de régression . Il s'agit d'une classification supplémentaire à côté du niveau de test et du type de test . Un test de régression est un test que vous souhaitez répéter car il touche à quelque chose de critique dans votre produit. Il s'agit en fait d'un sous-ensemble de tests que vous avez définis pour chaque niveau de test . S'il y a une petite correction de bogue dans votre produit, on n'a pas toujours le temps de répéter tous les tests. Les tests de régression sont une réponse à cela.

La différence est entre tester le problème et la solution. Le logiciel est une solution à un problème, les deux peuvent être testés.

Le test fonctionnel confirme que le logiciel exécute une fonction dans les limites de la façon dont vous avez résolu le problème. Cela fait partie intégrante du développement de logiciels, comparable aux tests effectués sur un produit fabriqué en série avant qu'il ne quitte l'usine. Un test fonctionnel vérifie que le produit fonctionne réellement comme vous (le développeur) le pensez.

Les tests d'acceptation vérifient que le produit résout réellement le problème qu'il a été conçu pour résoudre. Cela peut être mieux fait par l'utilisateur (client), par exemple en effectuant ses tâches auxquelles le logiciel assiste. Si le logiciel réussit ce test du monde réel, il est accepté pour remplacer la solution précédente. Ce test d'acceptation ne peut parfois être effectué correctement qu'en production, surtout si vous avez des clients anonymes (par exemple un site Web). Ainsi, une nouvelle fonctionnalité ne sera acceptée qu'après des jours ou des semaines d'utilisation.

Test fonctionnel - testez le produit en vérifiant qu'il possède les qualités que vous avez conçues ou construites (fonctions, vitesse, erreurs, cohérence, etc.)

Test d'acceptation - tester le produit dans son contexte, cela nécessite (une simulation de) l'interaction humaine, le tester a l'effet souhaité sur le (s) problème (s) d'origine.

La réponse est l'opinion. J'ai travaillé dans de nombreux projets et en tant que testmanager et issuemanager et tous les différents rôles et les descriptions dans divers livres diffèrent donc voici ma variation:

tests fonctionnels: prenez les exigences de l'entreprise et testez-les toutes correctement et minutieusement d'un point de vue fonctionnel.

test d'acceptation: le client «payant» fait les tests qu'il aime faire pour pouvoir accepter le produit livré. Cela dépend du client, mais les tests ne sont généralement pas aussi approfondis que les tests fonctionnels, surtout s'il s'agit d'un projet interne, car les parties prenantes examinent et font confiance aux résultats des tests effectués lors des phases de test précédentes.

Comme je l'ai dit, c'est mon point de vue et mon expérience. Le test fonctionnel est systématique et le test d'acceptation est plutôt le service commercial qui teste la chose.

1. Public. Les tests fonctionnels visent à garantir aux membres de l'équipe qui produit le logiciel qu'il fait ce qu'ils attendent. Les tests d'acceptation visent à garantir au consommateur qu'il répond à ses besoins.

2. Portée. Les tests fonctionnels testent uniquement la fonctionnalité d'un composant à la fois. Les tests d'acceptation couvrent tout aspect du produit qui compte suffisamment pour le consommateur pour être testé avant d'accepter le logiciel (c'est-à-dire tout ce qui vaut le temps ou l'argent qu'il faudra pour le tester afin de déterminer son acceptabilité).

Le logiciel peut passer les tests fonctionnels, les tests d'intégration et les tests système; seulement pour échouer les tests d'acceptation lorsque le client découvre que les fonctionnalités ne répondent tout simplement pas à ses besoins. Cela impliquerait généralement que quelqu'un a foiré les spécifications. Le logiciel peut également échouer certains tests fonctionnels, mais réussir les tests d'acceptation parce que le client est prêt à gérer certains bogues fonctionnels tant que le logiciel fait les choses essentielles dont il a besoin de manière acceptable (le logiciel bêta sera souvent accepté par un sous-ensemble d'utilisateurs avant cela. est complètement fonctionnel).

Test fonctionnel: application de données de test dérivées des exigences fonctionnelles spécifiées sans égard à la structure finale du programme. Également connu sous le nom de test de boîte noire.

Test d'acceptation: test formel effectué pour déterminer si un système satisfait ou non à ses critères d'acceptation - permet à un utilisateur final de déterminer s'il accepte ou non le système.

À mon avis, la principale différence est de savoir qui dit si les tests réussissent ou échouent.

Un test fonctionnel vérifie que le système répond aux exigences prédéfinies. Il est réalisé et contrôlé par les personnes responsables du développement du système.

Un test d'acceptation est signé par les utilisateurs. Idéalement, les utilisateurs diront ce qu'ils veulent tester, mais dans la pratique, il est probable que ce soit le coucher du soleil d'un test fonctionnel car les utilisateurs n'investissent pas suffisamment de temps. Notez que ce point de vue est celui des utilisateurs professionnels que je traite avec d'autres groupes d'utilisateurs, par exemple l'aviation et d'autres facteurs critiques pour la sécurité pourraient bien ne pas avoir cette différence,

Test d'acceptation :

... est un test en boîte noire effectué sur un système (par exemple, un logiciel, de nombreuses pièces mécaniques fabriquées ou des lots de produits chimiques) avant sa livraison.

Bien que cela continue à dire:

Il est également connu sous le nom de test fonctionnel, de test boîte noire, d'acceptation de version, de test QA, de test d'application, de test de confiance, de test final, de test de validation ou de test d'acceptation en usine.

avec une marque "citation nécessaire".

Test fonctionnel (qui redirige en fait vers System Testing):

menée sur un système complet et intégré pour évaluer la conformité du système aux exigences spécifiées. Les tests du système entrent dans le cadre des tests de la boîte noire et, en tant que tels, ne devraient exiger aucune connaissance de la conception interne du code ou de la logique.

Donc, d'après cette définition, ils sont à peu près la même chose.

D'après mon expérience, les tests d'acceptation sont généralement un sous-ensemble des tests fonctionnels et sont utilisés dans le processus d'approbation formel par le client, tandis que les tests fonctionnels / système seront ceux exécutés par le développeur / département QA.

La relation entre les deux: Le test d'acceptation comprend généralement des tests fonctionnels, mais il peut inclure des tests supplémentaires. Par exemple, vérifier les exigences en matière d'étiquetage / de documentation.

Le test fonctionnel est lorsque le produit testé est placé dans un environnement de test qui peut produire une variété de stimulation (dans le cadre du test) ce que l'environnement cible produit généralement ou même au-delà, tout en examinant la réponse de l'appareil testé.

Pour un produit physique (et non un logiciel), il existe deux types principaux de tests d'acceptation : les tests de conception et les tests de fabrication. Les tests de conception utilisent généralement un grand nombre d'échantillons de produits, qui ont réussi les tests de fabrication. Différents consommateurs peuvent tester la conception de différentes manières.

Les tests d'acceptation sont appelés vérification lorsque la conception est testée par rapport aux spécifications du produit, et les tests d'acceptation sont appelés validation, lorsque le produit est placé dans l'environnement réel du consommateur.

Les tests d'acceptation ne sont que des tests effectués par le client et incluent d' autres types de tests:

• Test fonctionnel: "ce bouton ne fonctionne pas"
• Test non fonctionnel: "cette page fonctionne mais est trop lente"

Pour les tests fonctionnels vs les tests non fonctionnels (leurs sous-types) - voir ma réponse à cette question SO .

Ce sont les mêmes choses.

Les tests d'acceptation sont effectués sur le système terminé de manière aussi identique que possible à l'environnement réel de production / déploiement avant que le système ne soit déployé ou livré.

Vous pouvez effectuer des tests d'acceptation de manière automatisée ou manuellement.