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 équivoques.
Dans mon monde, nous utilisons les termes comme suit:
test fonctionnel : Il s'agit d'une activité verification; 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 scénarios 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 tous les environnements de test que nous pouvons utiliser à ce moment-là, il n’est pas nécessaire que le calibre soit "de production", du moment que ce soit utilisable.
test d'acceptation : il s'agit d'une activité validation; Avons-nous construit la bonne chose? Est-ce ce dont le client a réellement besoin?
Cela se fait généralement en collaboration avec le client ou par un mandataire client interne (propriétaire du produit). Pour ce type de test, nous utilisons des scénarios de test qui couvrent les scénarios typiques dans lesquels nous nous attendons à ce que le logiciel soit utilisé. Ce test doit être effectué dans un environnement de type "production", sur un matériel identique ou proche de ce qu'un client utilisera. C'est à ce moment-là que nous testons nos "compétences":
Fiabilité, disponibilité : Validé via un test de stress.
Evolutivité : Validé via un test de charge.
Convivialité : Validé via une inspection et une démonstration au client. L'interface utilisateur est-elle configurée à leur convenance? Avons-nous mis la marque du client aux bons endroits? Avons-nous tous les champs/écrans qu'ils ont demandé?
Sécurité (alias Sécurité, pour s'intégrer): Validé par démonstration. Parfois, un client engage un cabinet externe pour effectuer un audit de sécurité et/ou des tests d'intrusion.
Maintenabilité : validé via une démonstration de la manière dont nous allons fournir les mises à jour/correctifs logiciels.
Configurabilité : Validé via une démonstration de la manière 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 montrent les réponses contradictoires. La chose la plus importante pour votre organisation est que vous définissiez ces termes avec précision et que vous les respectiez.
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
Niveau test est facile à expliquer avec V-model , 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.
- test des composants/unités => vérification de la conception détaillée
- test d'intégration composant/unité => vérification de la conception globale
- test du système => vérification de la configuration système requise
- test d'intégration du système => vérification de la configuration système requise
- tests d'acceptation => validation des exigences de l'utilisateur
types de test
Un type de test} est une caractéristique, il se concentre sur un objectif de test spécifique. Types de tests insistez sur vos aspects qualité, également appelés aspects techniques ou non fonctionnels. Types de test _ peut être exécuté à n'importe quel niveau de test. J'aime utiliser comme {types de test} _ les caractéristiques de qualité mentionnées dans ISO/IEC 25010: 2011.
- test fonctionel
- test de fiabilité
- test de performance
- test d'opérabilité
- tests de sécurité
- test de compatibilité
- test de maintenabilité
- test de transférabilité
Pour le rendre complet. Il y a aussi quelque chose appelé test de régression. Ceci est une classification supplémentaire à côté de niveau de test _ et type de test_. Un test de régression est un test que vous souhaitez répéter car il concerne un élément essentiel de votre produit. C'est en fait un sous-ensemble de tests que vous avez défini pour chaque niveau de test. S'il y a un petit correctif dans votre produit, vous n'avez pas toujours le temps de répéter tous les tests. (Test de régression} _ est une réponse à cette question.
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 résolution du problème. Cela fait partie intégrante du développement de logiciels, comparable aux tests effectués sur des produits fabriqués en série avant qu’ils ne quittent l’usine. Un test fonctionnel vérifie que le produit fonctionne réellement comme vous (le développeur) le pensez.
Des tests d'acceptation vérifient que le produit résout réellement le problème pour lequel il a été conçu. 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é de remplacer la solution précédente. Ce test de réception ne peut parfois être effectué correctement en production, en particulier si vous avez des clients anonymes (par exemple, un site Web). Ainsi, une nouvelle fonctionnalité ne sera acceptée qu'après plusieurs jours, voire plusieurs semaines d'utilisation.
Tests fonctionnels - tester le produit, en vérifiant qu'il possède les qualités que vous avez conçues ou développées (fonctions, vitesse, erreurs, cohérence, etc.)
Test d'acceptation - teste le produit dans son contexte; cela nécessite (simulation d'une) interaction humaine, le test a l'effet souhaité sur le (s) problème (s) d'origine.
La réponse est l'opinion. J'ai travaillé sur de nombreux projets et étant testmanager et issemanager, tous les rôles et descriptions diffèrent de ceux de différents livres. Voici donc ma variante:
tests fonctionnels: prenez les exigences de votre entreprise et testez-les correctement et minutieusement du point de vue fonctionnel.
test d'acceptation: / le client "payant" fait le test qu'il aime faire pour pouvoir accepter le produit livré. Cela dépend du client, mais généralement les tests ne sont pas aussi complets 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. Les tests fonctionnels sont systématiques et les tests d’acceptation sont plutôt le département commercial qui teste la chose.
Public. Les tests fonctionnels ont pour but d’assurer aux membres de l’équipe qui produit le logiciel qu’ils font ce qu’ils attendent. Les tests d'acceptation permettent de garantir au consommateur qu'ils répondent à ses besoins.
Portée. Les tests fonctionnels ne testent que les fonctionnalités d'un composant à la fois. Les tests d'acceptation couvrent tous les aspects du produit qui importent suffisamment pour que le consommateur teste avant d'accepter le logiciel (c'est-à-dire tout ce qui vaut le temps ou l'argent nécessaire pour le tester afin de déterminer son acceptabilité).
Le logiciel peut réussir les tests fonctionnels, les tests d'intégration et les tests système. é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é la spécification. Le logiciel pourrait également échouer à certains tests fonctionnels, mais réussir les tests d'acceptation, car le client est prêt à traiter certains bugs fonctionnels, à condition que le logiciel réponde de manière satisfaisante aux tâches essentielles dont il a besoin (le logiciel bêta sera souvent accepté par un sous-ensemble est complètement fonctionnel).
Test fonctionnel: Application des données de test dérivées des exigences fonctionnelles spécifiées, sans tenir compte de la structure finale du programme. Également appelé test de la boîte noire
Tests d'acceptation: Les tests formels menés pour déterminer si un système satisfait ou non à ses critères d'acceptation - permettent à 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 à des exigences prédéfinies. Il est effectué et vérifié par les personnes responsables du développement du système.
Un test d'acceptation est signé par les utilisateurs. Dans l’idéal, les utilisateurs diront ce qu’ils veulent tester, mais dans la pratique, il s’agit probablement d’un test fonctionnel, car les utilisateurs n’investissent pas suffisamment de temps. Notez que cette vue provient des utilisateurs professionnels que je traite avec d’autres ensembles d’utilisateurs, par exemple. l’aviation et d’autres aspects critiques de la sécurité pourraient bien ne pas avoir cette différence,
... les tests en boîte noire sont effectués 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 appelé test fonctionnel, test de boîte noire, acceptation de version, test d'assurance qualité, test d'application, test de confiance, test final, test de validation ou test d'acceptation en usine.
avec une marque "citation nécessaire".
Test fonctionnel (qui redirige réellement vers le test du système):
conduite sur un système complet et intégré pour évaluer la conformité du système à ses exigences spécifiées. Les tests du système entrent dans le champ des tests de la boîte noire et, en tant que tels, ne nécessitent aucune connaissance de la conception interne du code ou de la logique.
Donc, de 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 de validation formelle par le client, tandis que les tests fonctionnels/système sont ceux exécutés par le développeur/le service d'assurance qualité.
Le test d'acceptation est simplement un test effectué par le client, et comprend d'autres types de tests:
- Test fonctionnel: "Ce bouton ne fonctionne pas"
- Tests non fonctionnels: "cette page fonctionne mais est trop lente"
Pour les tests fonctionnels par rapport aux tests non fonctionnels (leurs sous-types) - voir ma réponse à cette SO question .
La relation entre les deux: Le test d'acceptation comprend généralement des tests fonctionnels, mais peut inclure des tests supplémentaires. Par exemple, vérifier les exigences en matière d'étiquetage/documentation.
Test fonctionnel est le moment où le produit à tester est placé dans un environnement de test pouvant produire une variété de stimulations (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 du tester.
Pour un produit physique (pas un logiciel), il existe deux types principaux de Tests de réception : tests de conception et 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 désignés par validation, lorsque le produit est placé dans l'environnement réel du consommateur.