Tests d'acceptation

En ingénierie et dans ses diverses sous-disciplines , les tests d'acceptation sont des tests effectués pour déterminer si les exigences d'une spécification ou d'un contrat sont respectées. Il peut s'agir de tests chimiques , de tests physiques ou de tests de performance .

En ingénierie des systèmes , cela peut impliquer des tests en boîte noire effectués sur un système (par exemple : un logiciel , de nombreux lots de pièces mécaniques fabriquées ou des lots de produits chimiques) avant sa livraison.

Dans les tests logiciels , l' ISTQB définit les tests d'acceptation comme :

Des tests formels concernant les besoins, les exigences et les processus métier des utilisateurs sont effectués pour déterminer si un système satisfait aux critères d'acceptation et pour permettre à l'utilisateur, aux clients ou à toute autre entité autorisée de déterminer s'il faut accepter le système.

—  Glossaire standard des termes utilisés dans les tests de logiciels

Le test final du cycle de vie de l'assurance qualité, le test d'acceptation utilisateur, est effectué juste avant la version finale pour évaluer si le produit ou l'application peut gérer des scénarios réels. En reproduisant le comportement de l'utilisateur, il vérifie si le système répond aux exigences de l'entreprise et rejette les modifications si certains critères ne sont pas remplis.

Les tests d'acceptation sont notamment les tests d'acceptation utilisateur (UAT), les tests utilisateur final, les tests d'acceptation opérationnels (OAT), le développement piloté par les tests d'acceptation (ATDD) et les tests sur le terrain (acceptation). Les critères d'acceptation sont les critères qu'un système ou un composant doit satisfaire pour être accepté par un utilisateur, un client ou une autre entité autorisée.

Les tests sont un ensemble d'activités menées pour faciliter la découverte et/ou l'évaluation des propriétés d'un ou plusieurs éléments testés. Chaque test, appelé cas de test, exerce un ensemble d'activités de test prédéfinies, développées pour piloter l'exécution de l'élément de test afin d'atteindre les objectifs de test ; y compris la mise en œuvre correcte, l'identification des erreurs, la vérification de la qualité et d'autres détails importants. L' environnement de test est généralement conçu pour être identique, ou aussi proche que possible, de l'environnement de production prévu. Il comprend toutes les installations, le matériel, les logiciels, les micrologiciels, les procédures et/ou la documentation destinés ou utilisés pour effectuer les tests de logiciels.

Les cas de test UAT et OAT sont idéalement élaborés en collaboration avec les clients commerciaux, les analystes commerciaux, les testeurs et les développeurs. Ces tests doivent inclure à la fois des tests de logique commerciale et des conditions d'environnement opérationnel. Les clients commerciaux (propriétaires de produits) sont les principales parties prenantes de ces tests. Lorsque les conditions de test répondent avec succès à leurs critères d'acceptation, les parties prenantes sont rassurées quant au fait que le développement progresse dans la bonne direction.

• Les critères de test d'acceptation utilisateur (UAT) (dans le développement logiciel agile ) sont généralement créés par les clients professionnels et exprimés dans un langage de domaine métier . Il s'agit de tests de haut niveau permettant de vérifier l'exhaustivité d'une ou plusieurs histoires utilisateur « jouées » au cours d'un sprint/itération.
• Les critères des tests d'acceptation opérationnelle (OAT) (indépendamment de l'utilisation du développement agile, itératif ou séquentiel) sont définis en termes d' exigences fonctionnelles et non fonctionnelles ; couvrant les attributs de qualité clés de la stabilité fonctionnelle , de la portabilité et de la fiabilité .

La suite de tests d'acceptation peut devoir être exécutée plusieurs fois, car tous les cas de test peuvent ne pas être exécutés dans une seule itération de test.

La suite de tests d'acceptation est exécutée à l'aide de procédures de tests d'acceptation prédéfinies pour indiquer aux testeurs les données à utiliser, les processus étape par étape à suivre et le résultat attendu après l'exécution. Les résultats réels sont conservés pour être comparés aux résultats attendus. Si les résultats réels correspondent aux résultats attendus pour chaque cas de test, le cas de test est dit réussi. Si la quantité de cas de test non réussis ne dépasse pas le seuil prédéterminé du projet, la suite de tests est dite réussie. Si c'est le cas, le système peut être rejeté ou accepté selon des conditions préalablement convenues entre le sponsor et le fabricant.

Le résultat attendu d'une exécution de test réussie :

• les cas de test sont exécutés à l'aide de données prédéterminées
• les résultats réels sont enregistrés
• les résultats réels et attendus sont comparés, et
• les résultats des tests sont déterminés.

L'objectif est de garantir que le produit développé répond à la fois aux exigences fonctionnelles et non fonctionnelles. L'objectif des tests d'acceptation est qu'une fois terminés et à condition que les critères d'acceptation soient remplis, les sponsors doivent approuver le développement/l'amélioration du produit comme satisfaisant aux exigences définies (préalablement convenues entre l'entreprise et le fournisseur/développeur du produit).

Les tests d'acceptation utilisateur (UAT) consistent à vérifier qu'une solution fonctionne pour l'utilisateur. Il ne s'agit pas de tests système (qui garantissent que le logiciel ne plante pas et répond aux exigences documentées), mais plutôt de vérifications que la solution fonctionnera pour l'utilisateur (c'est-à-dire de tests que l'utilisateur accepte la solution) ; les éditeurs de logiciels appellent souvent cela des « tests bêta ».

Ces tests doivent être effectués par l' utilisateur final prévu ou par un expert en la matière (SME), de préférence le propriétaire ou le client de la solution testée, et fournir un résumé des résultats pour confirmation, puis procéder après un essai ou un examen. Dans le développement de logiciels , l'UAT, l'une des dernières étapes d'un projet, se produit souvent avant qu'un client n'accepte le nouveau système. Les utilisateurs du système effectuent des tests conformes à ce qui se produirait dans des scénarios réels.

Les documents remis au testeur doivent être similaires à ceux dont disposera l'utilisateur final. Les testeurs doivent recevoir des scénarios réels tels que les trois tâches les plus courantes ou les plus difficiles que les utilisateurs qu'ils représentent devront entreprendre.

L'UAT sert de vérification finale des fonctionnalités métier requises et du bon fonctionnement du système, en imitant les conditions du monde réel pour le compte du client payant ou d'un client important spécifique. Si le logiciel fonctionne comme prévu et sans problème lors d'une utilisation normale, on peut raisonnablement extrapoler le même niveau de stabilité en production.

Les tests utilisateurs, généralement effectués par les clients ou par les utilisateurs finaux, ne se concentrent généralement pas sur l'identification de simples problèmes cosmétiques tels que les fautes d'orthographe, ni sur les défauts majeurs , tels que les pannes de logiciels ; les testeurs et les développeurs identifient et corrigent ces problèmes lors des phases antérieures de tests unitaires , de tests d'intégration et de tests système.

L'UAT doit être exécuté sur la base de scénarios de test. Les scénarios de test diffèrent généralement des cas de test système ou fonctionnels dans la mesure où ils représentent un parcours de « joueur » ou d'« utilisateur ». La nature large du scénario de test garantit que l'accent est mis sur le parcours et non sur les détails techniques ou spécifiques au système, en évitant les étapes de test « clic par clic » pour permettre une variation du comportement des utilisateurs. Les scénarios de test peuvent être décomposés en « jours » logiques, qui correspondent généralement aux changements d'acteur (joueur/client/opérateur) ou de système (backoffice, front-end).

Dans l'industrie, un UAT courant est un test d'acceptation en usine (FAT). Ce test a lieu avant l'installation de l'équipement. La plupart du temps, les testeurs vérifient non seulement que l'équipement répond aux spécifications, mais aussi qu'il est entièrement fonctionnel. Un FAT comprend généralement un contrôle d'intégralité, une vérification par rapport aux exigences contractuelles, une preuve de fonctionnalité (par simulation ou par un test de fonctionnement conventionnel) et une inspection finale. Les résultats de ces tests donnent aux clients confiance dans la façon dont le système fonctionnera en production. Il peut également y avoir des exigences légales ou contractuelles pour l'acceptation du système.

Les tests d'acceptation opérationnelle (OAT) sont utilisés pour évaluer l'état de préparation opérationnelle (pré-lancement) d'un produit, d'un service ou d'un système dans le cadre d'un système de gestion de la qualité . Les OAT sont un type courant de tests logiciels non fonctionnels , principalement utilisés dans les projets de développement et de maintenance de logiciels . Ce type de test se concentre sur l'état de préparation opérationnelle du système à prendre en charge et/ou à intégrer l'environnement de production.

Les tests d'acceptation sont un terme utilisé dans les méthodologies de développement de logiciels agiles , en particulier la programmation extrême , faisant référence aux tests fonctionnels d'une histoire utilisateur par l'équipe de développement de logiciels pendant la phase d'implémentation.

Le client spécifie des scénarios à tester lorsqu'une histoire utilisateur a été correctement implémentée. Une histoire peut avoir un ou plusieurs tests d'acceptation, selon ce qui est nécessaire pour garantir le bon fonctionnement de la fonctionnalité. Les tests d'acceptation sont des tests système en boîte noire. Chaque test d'acceptation représente un résultat attendu du système. Les clients sont responsables de vérifier l'exactitude des tests d'acceptation et d'examiner les résultats des tests pour décider quels tests échoués sont de la plus haute priorité. Les tests d'acceptation sont également utilisés comme tests de régression avant une mise en production. Une histoire utilisateur n'est pas considérée comme terminée tant qu'elle n'a pas réussi ses tests d'acceptation. Cela signifie que de nouveaux tests d'acceptation doivent être créés pour chaque itération, sinon l'équipe de développement signalera une progression nulle.

Les types typiques de tests d’acceptation incluent les suivants

Tests d'acceptation des utilisateurs

Cela peut inclure des tests d'acceptation en usine (FAT), c'est-à-dire des tests effectués par un fournisseur avant que le produit ou le système ne soit déplacé vers son site de destination, après quoi des tests d'acceptation sur site (SAT) peuvent être effectués par les utilisateurs sur le site.

Tests d'acceptation opérationnelle

Également connu sous le nom de test de préparation opérationnelle, ce test fait référence à la vérification effectuée sur un système pour s'assurer que les processus et les procédures sont en place pour permettre l'utilisation et la maintenance du système. Cela peut inclure des contrôles effectués sur les installations de secours, des procédures de reprise après sinistre, des formations pour les utilisateurs finaux, des procédures de maintenance et des procédures de sécurité.

Tests d'acceptation des contrats et des réglementations

Lors des tests d'acceptation de contrat, un système est testé en fonction des critères d'acceptation tels que documentés dans un contrat, avant que le système ne soit accepté. Lors des tests d'acceptation réglementaires, un système est testé pour s'assurer qu'il répond aux normes gouvernementales, légales et de sécurité.

Tests d'acceptation en usine

Tests d'acceptation effectués sur le site où le produit est développé et réalisés par les employés de l'organisation fournisseur, pour déterminer si un composant ou un système satisfait aux exigences, incluant normalement le matériel ainsi que les logiciels.

Tests alpha et bêta

Les tests alpha ont lieu sur les sites des développeurs et impliquent que le système opérationnel soit testé par le personnel interne, avant qu'il ne soit diffusé aux clients externes. Les tests bêta ont lieu sur les sites des clients et impliquent des tests effectués par un groupe de clients qui utilisent le système dans leurs propres locaux et fournissent des commentaires, avant que le système ne soit diffusé à d'autres clients. Ce dernier est souvent appelé « test sur le terrain ».

Selon le Project Management Institute , les critères d'acceptation sont un « ensemble de conditions qui doivent être remplies avant que les livrables soient acceptés ». Les exigences trouvées dans les critères d'acceptation pour un composant donné du système sont généralement très détaillées.

• Concordion , Cadre de spécification par l'exemple (SbE)
  • Concordion.NET, tests d'acceptation en .NET
• Concombre , un cadre de test d'acceptation de développement piloté par le comportement (BDD)
  • Capybara, framework de test d'acceptation pour les applications Web Ruby
  • Behat, cadre d'acceptation BDD pour PHP
  • Lettuce, cadre d'acceptation BDD pour Python
• Cyprès
• Fabasoft app.test pour les tests d'acceptation automatisés
• Cadre de référence pour les tests intégrés (Fit)
  • FitNesse , un fork de Fit
• Gauge (logiciel) , cadre d'automatisation des tests de Thoughtworks
• iMacros
• Framework Web Java Ajax ItsNat avec capacités de test Web fonctionnelles intégrées basées sur un serveur.
• Maveryx Test Automation Framework pour les tests fonctionnels, les tests de régression, les tests d'interface graphique, les tests pilotés par les données et sans code des applications de bureau et Web.
• Mocha , un framework de test d'acceptation Web populaire basé sur Javascript et Node.js
• Dramaturge (logiciel)
• Ranorex
• Cadre robotique
• Sélénium
• Spécification par exemple (Specs2)
• Watir