Test d'acceptation Le test d'acceptation est
simplement une forme de oui ou aucun test. Devrions-nous accepter le logiciel… oui ou non Les
tests d'acceptation devraient donc
répondre aux questions «Le système peut-il être libéré et déployé? », Objectifs des tests d'acceptation Les tests d'acceptation, comme les
tests système, se concentrent généralement sur le comportement et les capacités
des un système ou un produit entier. Les objectifs des tests d'acceptation sont
les suivants: • Instaurer la confiance dans la
qualité du système dans son ensemble • Valider que
le système est complet et fonctionnera comme prévu • Vérifier que
les comportements fonctionnels et non fonctionnels du système sont tels que spécifiés N'oubliez donc pas que
l'objectif principal des tests d'acceptation est l'acceptation… oui ou non… être trouvés lors des
essais de réception, mais la recherche de défauts n'est souvent pas un objectif, l'objectif principal des composants, de l'intégration
et des tests du système est de détecter les défauts. Donc, nous disons que les niveaux de test ont des objectifs différents.
Les tests d'acceptation peuvent produire des informations pour évaluer l'état de préparation du système au déploiement
et à l'utilisation par le client (utilisateur final). Découverte un nombre important de défauts lors des essais de réception peut
dans certains cas être considéré risque de projet majeur. Les tests d'acceptation peuvent également
satisfaire aux exigences légales ou réglementaires ou normes.
Base de test Exemples de produits de travail pouvant être utilisés
comme base de test pour toute forme d'acceptation les tests incluent: •
Processus commerciaux • Exigences de l'utilisateur ou
de l'entreprise • Règlements, contrats et normes juridiques • Cas d'utilisation •
Configuration requise • Documentation système ou utilisateur • Procédures
d'installation • Rapports d'analyse des risques Objets de test typiques
Les objets de test typiques pour toute forme de test d'acceptation comprennent:
• Système sous test
• Configuration et configuration du système
data • Processus métier pour une intégration complète système
• Systèmes de récupération et sites chauds (pour les entreprises tests de continuité et de reprise après
sinistre) • Processus d'exploitation et de maintenance •
Formulaires • Rapports • Données de production existantes et converties Défauts et défaillances typiques Exemples
de défauts typiques pour toute forme de test d'acceptation: •
Les flux de travail du système ne répondent pas
aux exigences de l'entreprise ou des utilisateurs • Les règles commerciales ne
sont pas correctement mises en œuvre • Le système ne
satisfait pas aux exigences contractuelles ou exigences réglementaires • Défaillances non fonctionnelles telles que la
sécurité vulnérabilités, efficacité insuffisante des performances sous des charges élevées ou mauvais fonctionnement sur
une plateforme supportée Approches et responsabilités spécifiques Les tests d'acceptation sont souvent la responsabilité des clients,
des utilisateurs professionnels, du produit les propriétaires ou les exploitants d'un système et d'autres parties
prenantes peuvent également être impliqués. Le test d'acceptation est souvent considéré comme le dernier niveau de
test dans un développement séquentiel cycle de vie, mais n'oubliez pas que les tests d'acceptation sont un type de test oui ou
non, donc n'importe où si nous testions quelque chose pour obtenir une réponse oui ou non, c'est une forme de test d'acceptation, qui peut également se produire
à d'autres moments, par exemple: • Test d'acceptation d'un logiciel COTS le produit peut se produire lorsqu'il est installé ou
intégré • Les tests d'acceptation d'une nouvelle amélioration fonctionnelle peuvent avoir
lieu avant les tests du système
Les tests d'acceptation peuvent
produire des informations pour évaluer l'état de préparation du
système au déploiement et à l'utilisation par le client (utilisateur final). Découverte un nombre important de défauts lors des essais de réception peut dans certains cas
être considéré risque de projet majeur. Les tests d'acceptation
peuvent également satisfaire aux exigences légales ou réglementaires ou normes.
Les formes courantes de tests d'acceptation comprennent les
éléments suivants: • Test d'acceptation par l'utilisateur •
Tests d'acceptation opérationnelle • Acceptation contractuelle et réglementaire
tests • Tests alpha et bêta. Expliquons chacun d'entre eux Test d'acceptation
par l'utilisateur (UAT) Les tests d'acceptation du système par les utilisateurs sont généralement axés sur la validation
de l'aptitude pour une utilisation du système par les utilisateurs prévus dans un environnement
opérationnel réel ou simulé. L'objectif principal est de renforcer
la confiance que les utilisateurs peuvent utiliser le système pour leurs besoins, répondre aux exigences et
exécuter les processus commerciaux avec un minimum de difficulté, coût et risque.
Les utilisateurs peuvent effectuer tous les tests de leur choix, généralement en fonction de leurs
processus métier, cela peut arriver à tout moment du projet, alors oui, vous pouvez faire une démonstration
du logiciel au client au milieu du projet et ils peuvent décide de ne pas continuer.
et bien sûr UAT se produit généralement avant la approbation de l'utilisateur final Test d'acceptation
opérationnelle (OAT) Les tests d'acceptation opérationnelle testent l'acceptation du système par les administrateurs
système. point de vue . il est généralement effectué par le
personnel des opérations ou de l'administration des systèmes et généralement réalisée dans un environnement de production (simulé).
Les tests se concentrent sur les aspects opérationnels, et peut
inclure: • Test de sauvegarde et de restauration • Installation, désinstallation
et mise à niveau • Récupération après
sinistre • Gestion des utilisateurs • Tâches de maintenance
• Tâches de chargement et de migration des données • Vérifie les failles de sécurité • Tests de performance Le
principal objectif de l'acceptation opérationnelle les tests renforcent la confiance que les
opérateurs ou les administrateurs système peuvent garder le système fonctionne correctement pour les
utilisateurs dans l'environnement opérationnel, même dans des conditions exceptionnelles ou difficiles conditions.
Outre la base de test que nous avons mentionnée auparavant, base de
test pour dériver des cas de test pour les tests d'acceptation opérationnelle, un
ou plusieurs des éléments suivants les produits de travail peuvent
être utilisés: • Procédures de sauvegarde et de restauration
• Procédures de reprise après sinistre • Exigences non fonctionnelles • Documentation
d'exploitation • Instructions de déploiement et d'installation • Objectifs de performance • Packages de base de données • Normes ou réglementations de sécurité
Tests d'acceptation des contrats et des réglementations Test d'acceptation du contrat - parfois, les critères d'acceptation d'un
système sont documentés dans un contrat. si un client a besoin d'acheter
un logiciel COTS mais ajoutera une exigence mineure dire d'ajouter le nom et le logo de son
entreprise est le premier écran de démarrage. Alors je suppose que vous acceptez que nous n'avons pas besoin
de modifier le document d'exigence pour cela et passez par le SDLC encore. Un tel changement mineur pourrait être documenté dans
le contrat et c'est tout. Test alors est effectuée pour vérifier que ces
critères sont remplis, avant que le système ne soit accepté. Les tests d'acceptation contractuelle sont souvent
effectués par des utilisateurs ou par des testeurs indépendants.
Essais d'acceptation des réglementations - dans certains les industries, les systèmes doivent répondre aux
normes gouvernementales, légales ou de sécurité. Exemples de ces sont les industries de défense,
bancaires et pharmaceutiques. Par exemple, si
une société de logiciels souhaite ajouter le logo ISO à son logiciel, elle doit suivre les directives
ISO lors du développement du logiciel. Le test est ensuite effectué pour tester si nous devons passer
les directives ISO ou non. Oui ou non. Les tests d'acceptation
réglementaire sont souvent effectués par des utilisateurs ou par des testeurs indépendants, parfois les résultats étant observés
ou vérifiés par des organismes de réglementation. L'objectif principal des tests d'acceptation
contractuelle et réglementaire
est de renforcer la confiance que la conformité contractuelle ou réglementaire a été atteint.
Tests alpha et bêta certains systèmes sont développés pour le
marché de masse, e. g. logiciel commercial standard (COTS), où aucun
client réel ne vous a fourni ses besoins. Mais au lieu de cela l'équipe marketing de votre entreprise vous a
suggéré certaines exigences et vous avez construit le système sur la base de ces suggestions. Vous voulez toujours obtenir des commentaires sur la façon
dont l'utilisateur qui achètera le système se sent lors de l'utilisation du système avant la mise
sur le marché du produit logiciel. Très souvent, ce type de
système subit deux étapes de test d'acceptation. Les tests alpha ont lieu sur
le site du développeur - nous invitons certains utilisateurs potentiels à notre site en utilisant nos machines
et laissez-les jouer avec le logiciel pendant un certain temps et obtenir des commentaires d'eux.
Les tests bêta ont lieu chez le client site - nous envoyons le logiciel à certains
utilisateurs potentiels et leur demandons de jouer avec le logiciel utiliser leurs machines et leur demander de
nous envoyer des commentaires quand ils ont terminé. Les tests bêta peuvent survenir après les tests alpha ou
peuvent se produire sans aucun test alpha précédent. N'oubliez pas que
l'alpha se fait sur le site de développement et la bêta se fait sur le site du client.
L'un des objectifs des tests alpha et bêta est renforcer la confiance des clients potentiels
ou existants et / ou des opérateurs qu'ils peuvent utiliser le système dans des conditions normales
et quotidiennes et dans le ou les environnements opérationnels pour leurs objectifs avec un
minimum de difficulté, de coût et de risque. Un autre objectif peut être la détection
des défauts liés aux conditions et aux environnements dans lesquels le système être utilisé,
en particulier lorsque ces conditions et ces environnements sont difficiles à reproduire par l'équipe de développement.
Alors, ce qui est mieux de votre point de vue, tests alpha ou bêta?
Dans le développement itératif, les équipes de projet peuvent utiliser diverses formes de tests
d'acceptation pendant et à la fin de chaque itération, telles que que ceux axés sur la
vérification d'une nouvelle fonctionnalité par rapport à ses critères d'acceptation et ceux concentré sur la validation
qu'une nouvelle fonctionnalité répond aux besoins des utilisateurs. De plus, les tests alpha et des tests bêta
peuvent se produire, soit à la fin de chaque itération, après la fin de chaque itération, ou après une série d'itérations.
Tests d'acceptation utilisateur, acceptation opérationnelle Des tests, des tests d’acceptation réglementaires et
des tests d’acceptation contractuelle peuvent également la fin de chaque itération, après la fin
de chaque itération, ou après une série d'itérations.