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

Question

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

Quels sont les points forts ou les objectifs de chacun ? Partout où je lis, ils se ressemblent de façon ambiguë.

Answer 1

Dans mon monde, nous utilisons les termes comme suit :

tests de fonctionnement : C'est un vérification activité ; avons-nous construit un produit fonctionnant 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 si ce scénario a peu de chances d'exister "dans le monde réel". Lorsque nous effectuons ce type de test, nous visons une couverture maximale du code. Nous utilisons tout environnement de test que nous pouvons saisir à ce moment-là, il n'est pas nécessaire qu'il soit de calibre "production", tant qu'il est utilisable.

test d'acceptation : C'est un validation activité ; avons-nous construit la bonne chose ? Est-ce que c'est ce dont le client a vraiment besoin ?

Cela se fait généralement en coopération avec le client, ou par un mandataire interne du client (propriétaire du produit). Pour ce type de test, nous utilisons des cas de test qui couvrent les scénarios typiques dans lesquels nous nous attendons à ce que le logiciel soit utilisé. Ce test doit être réalisé dans un environnement de type "production", sur un matériel identique ou proche de celui qu'utilisera le client. C'est à ce moment-là que nous testons nos "capacités" :

• Fiabilité, disponibilité : Validé par un stress test.

• Scalabilitiy : Validé par un test de charge.

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

• Sécurité (alias, la sécurisation, juste pour s'intégrer) : Validé par une démonstration. Il arrive qu'un client fasse appel à une entreprise extérieure pour réaliser un audit de sécurité et/ou un test d'intrusion.

• Maintenabilité : Validé par la démonstration de la manière dont nous délivrerons les mises à jour/patchs logiciels.

• Configurabilité : Validé par la démonstration de la manière dont le client peut modifier le système pour l'adapter à ses besoins.

Ce n'est en aucun cas la norme, et je ne pense pas qu'il existe une définition "standard", comme le montrent les réponses contradictoires données ici. Le plus important pour votre organisation est de définir précisément ces termes et de vous y tenir.

Answer 2

J'aime la réponse de Patrick Cuff. Ce que j'aime ajouter, c'est la distinction entre une niveau de test et un type de test ce qui m'a ouvert les yeux.

niveaux de test

Niveau de test est facile à expliquer en utilisant le modèle en V, un exemple : Chaque niveau de test a son correspondant niveau de développement . Ils ont une caractéristique temporelle typique, ils sont exécutés à une certaine phase du cycle de vie du développement.

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

types de tests

A type de test est une caractéristique, elle se concentre sur un objectif de test spécifique. Types de tests mettez l'accent sur vos aspects qualitatifs, également connus sous le nom d'aspects techniques ou non fonctionnels. Types de tests peut être exécuté à tout moment niveau de test . J'aime utiliser comme types de tests les caractéristiques de qualité mentionnées dans la norme ISO/CEI 25010:2011.

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

Pour le rendre complet. Il y a aussi quelque chose qui s'appelle test de régression . C'est une classification supplémentaire à côté de niveau de test et type de test . A test de régression est un test que vous voulez répéter parce qu'il touche à quelque chose de critique dans votre produit. C'est en fait un sous-ensemble de tests que vous avez défini pour chaque niveau de test . Si un petit bug est corrigé dans votre produit, on n'a pas toujours le temps de répéter tous les tests. Tests de régression est une réponse à cela.

Answer 3

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 remplit une fonction dans les limites de la façon dont vous avez résolu le problème. Il s'agit d'une partie intégrante du développement d'un logiciel, comparable aux tests effectués sur les produits de masse 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.

Les tests d'acceptation vérifient que le produit résout effectivement le problème qu'il est censé résoudre. Le meilleur moyen d'y parvenir est de demander à l'utilisateur (client) d'effectuer les tâches pour lesquelles le logiciel l'aide. Si le logiciel passe ce test en situation réelle, 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 plusieurs jours ou semaines d'utilisation.

Essais fonctionnels - tester 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.)

Essais d'acceptation - tester le produit dans son contexte, ce qui nécessite une (simulation de) l'interaction humaine, tester qu'il a l'effet désiré sur le(s) problème(s) initial(aux).

Answer 4

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

test fonctionnel : prendre les exigences de l'entreprise et tester tout cela de manière approfondie d'un point de vue fonctionnel.

test d'acceptation : le client "payeur" effectue les tests qu'il souhaite effectuer afin de 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 les résultats des tests effectués lors des phases précédentes et leur font confiance.

Comme je l'ai dit, il s'agit de mon point de vue et de mon expérience. Les tests fonctionnels sont systématiques et les tests d'acceptation sont plutôt effectués par le département commercial.

Answer 5

1. Audience. Les tests fonctionnels ont pour but de garantir aux membres de l'équipe qui produit le logiciel que celui-ci répond à leurs attentes. Les tests d'acceptation visent à garantir au consommateur que le logiciel répond à ses besoins.

2. Portée. Les tests fonctionnels ne testent que la fonctionnalité d'un seul composant à la fois. Les tests d'acceptation couvrent tout aspect du produit qui est suffisamment important pour le consommateur pour être testé 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é).

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