acceptance testing documentation with real time scenarios
Documentation des tests d'acceptation (partie II):
Tutoriel précédent | Tutoriel SUIVANT
Ce tutoriel est la suite de notre précédent tutoriel où nous avons discuté de ce qu'est le test d'acceptation, quand il doit être fait, qui le fait, son importance, ses types, son processus, son impact sur différentes équipes, etc.
je veux être un testeur de produits
Les documents jouent un rôle très important dans les tests d'acceptation et tout problème concernant le document a un impact négatif énorme. Lorsqu'une vérification appropriée n'est pas effectuée, cela peut même conduire à la défaillance du produit.
=> Cliquez ici pour une série complète de didacticiels sur le plan de test
Dans ce didacticiel, nous en apprendrons plus sur les différentes documentations impliquées dans les tests d'acceptation, c'est-à-dire le plan de test d'acceptation, la liste de contrôle de révision du plan de test, le modèle de test d'acceptation, des exemples basés sur des scénarios en temps réel, comment identifier et écrire des tests d'acceptation, etc. .
Ce que vous apprendrez:
- Plan de test d'acceptation
- Modèle de plan de test d'acceptation
- Révision du plan de test d'acceptation
- Tests d'acceptation
- Révision des tests d'acceptation
- Conclusion
- lecture recommandée
Plan de test d'acceptation
Comme tout autre plan de test, le plan de test d'acceptation comprend également certains composants tels que la portée, l'approche, l'environnement de test, les ressources, les responsabilités, les références des tests d'acceptation, les critères d'entrée, les critères de sortie, les outils, etc.
La seule chose qui différencie le plan de test d'acceptation d'un plan de test régulier est ses facteurs qui aboutissent à une décision commerciale. Le plan de test d'acceptation est l'un des documents essentiels qui fournit des conseils sur la façon d'effectuer les tests d'acceptation pour un projet particulier.
Le plan de test d'acceptation doit être revu et approuvé avant l'exécution du test d'acceptation. Tous les changements ultérieurs doivent à nouveau faire l'objet d'un processus d'examen et d'approbation et doivent être en cours.
L'examen du plan de test d'acceptation est généralement effectué par les gestionnaires / analystes commerciaux / clients.
Points clés à prendre en compte lors de la conception du plan de test d'acceptation:
- Ça devrait être Détaillé et spécifique. Doit inclure uniquement ce qui est requis pour les tests et les informations nécessaires à l'équipe pour effectuer les tests.
- Ça devrait être Clair et concis . Aucune ambiguïté. S'il y a quelque chose qui peut prêter à confusion, élaborez-le, mais soyez bref et efficace.
- Chaque composant dans le document doit être rédigé en gardant à l'esprit uniquement les exigences opérationnelles.
- Fiable et adaptable - Il devrait pouvoir être mis à jour selon les besoins dans les futures versions.
- Cohérent - Il ne devrait pas y avoir plus de changements à l'avenir.
- Suivez le modèle fourni par l'organisation ou le client.
Modèle de plan de test d'acceptation
Ici, nous allons jeter un œil à un modèle commun pour le plan de test d'acceptation qui peut être encore peaufiné selon les exigences du projet.
Titre
Objectif
Historique des révisions / Journal des modifications
< Cela devrait être sous forme de tableau avec les informations ci-dessous:
- Date - La date à laquelle le document a été modifié.
- Modifié par - Qui a modifié le contenu du document.
- But - Pourquoi le document a-t-il été modifié.
- Version - Version actuelle du document après modifications (devient 1.0, 1.1, 1.2, 1.3,… pour une version particulière. La prochaine version commencera à partir de 2, 2.1, 2.2, 2.3,…, La liste est longue).
- Approuvé par - Qui a approuvé les modifications apportées (signifie implicitement que le document a été examiné et approuvé).
La toute première ligne de ce tableau doit contenir les détails du document créé. Suit ensuite le détail des modifications apportées.>
Table des matières
Les références
Portée
introduction
Articles de test
Fonctionnalités à tester
Fonctionnalités à ne pas tester
Approcher
Détails de l'environnement de test
Critères d'admission
Tests - S'il n'y a pas de tests d'acceptation séparés écrits
Chaque test doit inclure:
- Test #.
- Une description de ce qui est testé ( Exemple : Vérifiez si un utilisateur est en mesure de créer un compte avec succès).
- Exigence commerciale à laquelle ce test correspond ( Matrice de traçabilité ) - Très important.
- Pré-conditions:
- État du produit avant de commencer le test (l'utilisateur doit être enregistré avec succès mais pas activé le compte, l'utilisateur doit avoir accédé au produit il y a au moins 30 jours, etc.)
- Toutes les conditions du serveur - Le serveur doit-il être arrêté pendant un certain temps.
- Étapes du test: Flux numéroté détaillé ( Exemple: voir ci-dessous
- Ouvrez l'application.
- Essayez de vous connecter avec des informations d'identification valides en cochant la case Se souvenir de moi).
- résultat attendu : Quel est le comportement attendu de l'étape>
Tests d'acceptation - S'il y a des tests d'acceptation séparés écrits
Critère de sortie
Ressources
Rôles et responsabilités
Outils
Facteurs de décision commerciale
Procédure d'approbation
Point de contact
Le plan de test d'acceptation est considéré comme le Plan directeur de test pour la phase .
Révision du plan de test d'acceptation
Une fois que le plan est prêt, il doit être examiné pour en vérifier l'exhaustivité, la non-ambiguïté, la clarté, la qualité, etc. Il ne fait aucun doute que tout le contenu du plan de test d'acceptation doit être examiné en profondeur pour obtenir des informations appropriées, mais il doit être examiné par rapport à quelques autres points, disons les points de la liste de contrôle.
Ici, classons le contenu et voyons les points de la liste de contrôle par rapport à eux.
| Catégorie | Points de la liste de contrôle |
|---|---|
| Tests d'acceptation | Les tests sont-ils numérotés Les conditions préalables sont-elles numérotées Les étapes du test sont-elles claires à comprendre Les étapes du test sont-elles terminées Le résultat attendu est-il complet Y a-t-il une question ouverte dans les tests (le cas échéant, faites un suivi et complétez-la) La référence aux tests d'acceptation (si elle est écrite séparément) est-elle valide et existante La traçabilité est-elle correcte Y a-t-il une exigence commerciale manquée pour couvrir le test |
| Titre | Le titre correspond-il au titre du projet comme référencé partout Le titre respecte-t-il les conventions de dénomination du projet |
| Historique des révisions, table des matières | Toutes les modifications de version sont-elles correctement suivies pour le plan Chaque changement de version a-t-il fait l'objet d'un examen approprié et est-il mentionné La convention de gestion des versions est-elle correcte La table des matières correspond-elle au contenu réel du plan Le numéro de page de chaque contenu est-il correct Le numéro de page est-il mis à jour si les modifications apportées au plan ont changé le numéro de page du contenu |
| Les références | Les références sont-elles existantes et valides Correspondent-ils à la portée Sont-ils complets et pris en compte pour l'identification des tests |
| Éléments de test, fonctionnalités à tester, fonctionnalités à ne pas tester | Sont-ils numérotés Chaque fonctionnalité / module / sous-module relève-t-il de la portée Le calendrier prévu peut-il couvrir tous les éléments de test identifiés |
| Critères d'entrée, critères de sortie | Sont-ils numérotés Chaque critère est-il mentionné en détail |
| Détails de l'environnement de test | Est-ce qu'il a toutes les configurations requises mentionnées La version de chaque configuration est-elle spécifique ou la dernière à prendre en compte Est-ce que les VMs, l'environnement existe (sinon, mentionner la date possible pour sa disponibilité) La méthode de partage des informations d'identification pour l'accès à un environnement particulier est-elle mentionnée |
| Ressources, rôles et responsabilités | Les responsabilités pour chaque rôle sont-elles numérotées Les responsabilités peuvent-elles être acquises La ressource identifiée est-elle capable d'assumer les responsabilités mentionnées |
| Outils | Tous les outils mentionnés Tous les outils sont-ils numérotés Tous les outils sont-ils versionnés L'un des outils a-t-il besoin d'une licence ou de la licence existante valide pendant la phase Le guide d'utilisation de l'outil est-il correct et suffisant |
| Facteurs de décision commerciale | A tous les facteurs mentionnés Tous les facteurs sont-ils numérotés |
| Procédure d'approbation | La procédure est-elle valide La procédure est-elle acceptable La procédure est-elle claire à comprendre |
| Point de contact | La ressource identifiée comme point de contact est-elle disponible dans l'organisation pendant la phase La ressource identifiée est-elle capable de gérer la phase |
Tout plan de test satisfaisant au document de liste de contrôle ci-dessus servira également de document solide pour les audits internes.
Tests d'acceptation
Les tests d'acceptation étaient auparavant connus sous le nom de tests fonctionnels. Afin de rendre le nom plus approprié pour la phase de test d'acceptation et de servir l'objectif, il a été renommé comme Tests d'acceptation. Parfois, il est également appelé Tests clients.
Les tests d'acceptation sont toujours dérivés des user stories, des critères d'acceptation et des cas d'utilisation. Ce sont des tests système en boîte noire et ne représentent que les tests métier qui doivent être vérifiés. Ceux-ci doivent être principalement destinés au comportement, à l'utilisation et aux flux du produit.
Les tests d'acceptation conçus peuvent également être pris en compte pour la phase de test du système dans les cycles de régression pour gagner en confiance sur le produit avant de le remettre à la phase de test d'acceptation.
Points clés à retenir avant d'écrire des tests d'acceptation:
- Gardez tous les documents de référence en place: Spécification des exigences logicielles, document des exigences commerciales, cas d'utilisation, histoires d'utilisateurs, matrice de données (en cas de logique impliquée), etc.
- Concentrez-vous uniquement sur les exigences métier (exigences métier testables).
- Effacez tous les doutes, les requêtes sur les besoins de l'entreprise au plus tôt.
- Assurez-vous qu'il n'y a au moins aucun changement sur les exigences de la version actuelle.
Modèle général et simple pour écrire des tests d'acceptation:
Ce modèle peut à nouveau être modifié selon les besoins du projet et avec plus d'informations à inclure.
Maintenant, prenons quelques scénarios courants et voyons comment les scénarios de test d'acceptation peuvent être écrits dessus.
Cas 1: gestion du compte utilisateur
Il s'agit du scénario dans lequel les utilisateurs sont autorisés à créer, afficher, mettre à jour et désactiver leur compte. En général, il s'agit d'une opération CRUD (créer, lire, mettre à jour et supprimer). Nous allons donc directement tester 4 scénarios majeurs.
Parallèlement à cela, dans la gestion des comptes d'utilisateurs en temps réel, nous avons de nombreux domaines en matière de visualisation et de mise à jour.
Procéder à la rédaction des tests d'acceptation:
Test 1: Inscription / Inscription / Créer un compte, vérifiez si un utilisateur est capable de:
- Créez le compte.
- Activez le compte.
- Activez le compte une seule fois (ici, le lien d'activation doit être testé pour 2ndMême s'il s'agit d'un test négatif, c'est l'un des principaux points de vérification à considérer).
Test 2: pour accéder et afficher les informations du compte, vérifiez si un utilisateur est capable de:
- Connectez-vous au compte.
- Afficher différentes sections dans le profil (si la section Profil est catégorisée, chaque catégorie doit être visible).
- Vérifiez que les données affichées dans le profil sont correctes selon l'entrée de l'utilisateur.
Test 3: pour mettre à jour les informations de compte, vérifiez si un utilisateur est capable de:
- Mettre à jour les informations de compte (profil):
- Mettez à jour chaque catégorie du profil.
- Vérifiez que les informations de mise à jour sont correctement reflétées dans le profil.
- Vérifiez si l'utilisateur n'est pas en mesure de mettre à jour les informations dans le profil (dans certaines applications, le prénom, le nom, le nom d'utilisateur, etc. ne seront pas autorisés à se mettre à jour. Même s'il s'agit d'un test négatif, c'est l'un des principaux points de vérification. à prendre en considération).
- Annulez le flux de mise à jour (même s'il s'agit d'un test négatif, c'est également l'un des principaux points de vérification à prendre en compte).
Test 4: Si la désactivation du compte est autorisée, vérifiez si un utilisateur est capable de:
- Désactivez le compte.
- Annuler le flux de désactivation (même s'il s'agit d'un test négatif, c'est l'un des principaux points de vérification à prendre en compte).
- Accédez au compte après avoir annulé la désactivation.
Test 5: Si des vérifications sont nécessaires pour une adresse e-mail ou des numéros de téléphone, vérifiez si un utilisateur est en mesure de:
meilleure suppression de logiciels malveillants pour windows 7
- Mettez à jour l'adresse e-mail avec l'autre adresse valide.
- Vérifiez 'l'adresse e-mail mise à jour.
- Vérifiez si l'adresse e-mail mise à jour et «vérifiée» est prise en compte plus avant - Envoyez des e-mails depuis l'application et vérifiez son arrivée à l'adresse e-mail mise à jour. L'ancien ne devrait pas recevoir d'e-mails.
- Ajoutez le nouveau numéro de téléphone.
- Vérifiez le numéro de téléphone ajouté par appel.
- Vérifiez le numéro de téléphone ajouté par SMS.
- Vérifiez que le numéro de téléphone ajouté et «vérifié» se reflète dans le compte.
- Mettez à jour le numéro de téléphone.
- Vérifiez le numéro de téléphone mis à jour par appel.
- Vérifiez 'le numéro de téléphone mis à jour par SMS.
- Vérifiez si le numéro de téléphone mis à jour et «vérifié» se reflète dans le compte.
Cas 2: achat d'un produit
L'achat du produit suit généralement le flux général.
Voici quelques scénarios généraux que regardent les utilisateurs finaux:
Condition préalable: L'utilisateur doit être connecté à l'application.
Test 1: Détails du produit, vérifiez si un utilisateur est capable de:
- Consultez la page des détails du produit.
- Affichez toutes les sous-sections de la page Détails du produit (Description, Fonctionnalité, Informations sur la marque, etc.).
- Sélectionnez la quantité du produit, la couleur, la taille, etc. disponibles dans la page de détails du produit.
- Accédez aux pages de catégorie et de sous-catégorie à partir de la page Détails du produit (si disponible dans la page Détails du produit).
- Accédez à la page de détails de l'autre produit (si la section des produits pertinents est fournie).
- Afficher les commentaires et les évaluations sur le produit.
- Trier les commentaires du produit en fonction des notes.
- Afficher la note globale du produit.
- Ajoutez un commentaire sur le produit.
- Mettez à jour son commentaire sur le produit.
- Supprimer son commentaire sur le produit (s'il est fourni).
Test 2: Ajouter au panier, vérifier si un utilisateur est:
- Capable d'ajouter le produit au panier:
- Via la page de détails du produit.
- Via la page de liste de produits.
- Capable d'ajouter la quantité requise au panier (1 à la limite maximale définie).
- Impossible d'ajouter le produit au panier en cas de rupture de stock.
Test 3: dans la page Panier, vérifiez si un utilisateur est capable de:
- Voir le produit dans le panier avec les détails du prix pour la quantité ajoutée.
- Mettre à jour la quantité (1 à la limite maximale définie).
- Retirez le produit du panier.
- Revenez aux achats.
- Continuez à payer.
- Afficher le panier vide lorsqu'aucun produit n'est ajouté,
Test 4: dans la page Détails du compte, vérifiez si un utilisateur est capable de:
- Continuez avec les détails d'expédition existants.
- Mettre à jour l'adresse de livraison.
- Ajouter une nouvelle adresse d'expédition.
- Continuez avec le numéro de téléphone existant.
- Mettre à jour le numéro de téléphone de la commande.
- Ajoutez un nouveau numéro de téléphone pour la commande.
- Revenez à la page Panier.
- Accédez à la page Paiement.
Test 5: Sur la page Paiements, vérifiez si un utilisateur est capable de:
- Vérifiez l'exactitude du montant à facturer.
- Traitez la commande avec toutes les options disponibles (une option pour chaque commande distincte).
- Traiter la transaction avec succès. Accédez à la page de confirmation de commande.
- Échec de la transaction (même s'il s'agit d'un test négatif, il doit être considéré comme un scénario majeur).
- Appliquer des coupons:
- Coupons valides - Succès. Vérifiez ici la modification du montant à facturer.
- Coupons non valides - Échec
- Coupons expirés - Échec.
- Revenez à la page des détails du compte.
Révision des tests d'acceptation
La révision des tests d'acceptation est une tâche importante car elle doit être correcte et au point par rapport aux exigences de l'entreprise. Comme ceux-ci peuvent être effectués par les clients eux-mêmes et / ou les utilisateurs finaux, il est absolument nécessaire d'être complet, non ambigu, correct et suffisamment détaillé pour que quiconque puisse le comprendre et l'exécuter.
La révision des tests d'acceptation doit être effectuée par les analystes commerciaux, les clients et tous les commentaires de révision doivent être intégrés en haute priorité.
Au niveau du test individuel, l'examen doit être effectué par rapport à ce qui suit:
- Si le test couvre les besoins commerciaux ou non.
- Les conditions préalables sont-elles claires?
- Les étapes du test sont-elles faciles à comprendre et détaillées?
- Le résultat attendu est-il correct et clair?
- Est-il mis en correspondance avec les exigences de l'entreprise en matière de traçabilité?
- Le test est-il suffisamment complet pour couvrir le flux ou l'utilisation particulier?
- Le test particulier est-il requis dans le cadre des tests d'acceptation.
- Y a-t-il un point de vérification qui n'est pas nécessaire pour les tests d'acceptation.
- Est-ce purement fonctionnel ou une interface graphique est couverte à l'intérieur (elle ne devrait être que fonctionnelle).
- Les données d'entrée spéciales sont-elles nécessaires? Si oui, est-il fourni pour les détails?
Dans l'ensemble, l'ensemble de la revue de la suite de tests d'acceptation devrait couvrir:
- Traçabilité bidirectionnelle: Exigences commerciales aux tests ET tests aux exigences commerciales.
- Chaque exigence commerciale est-elle couverte?
- Chaque besoin métier est-il couvert par un ou plusieurs tests?
- Les règles métier sont-elles couvertes?
- Le cas de données spécial est-il traité?
- Combien de tests sont écrits pour couvrir chaque exigence ou règle?
- Les tests peuvent-ils être regroupés et classés pour les flux?
- Les tests sont-ils correctement séquencés pour que l'exécution soit efficace?
Conclusion
En un mot, comme mentionné précédemment, les documents jouent un rôle très radical dans les tests d'acceptation.
Par conséquent, tout test d'acceptation qui est écrit doit être bien structuré et suivre son utilisation, de sorte que les testeurs d'acceptation restent intéressés par ce qu'ils testent et comment ils le font. Ceci, à son tour, entraînerait automatiquement le succès.
=> Visitez ici pour une série complète de didacticiels sur le plan de test
Tutoriel précédent | Tutoriel SUIVANT
Restez à l'écoute et surveillez le prochain didacticiel de test d'acceptation pour en savoir plus sur les rapports de test d'acceptation ainsi que sur certains modèles génériques. Aussi, faites-nous savoir si vous avez des questions.
lecture recommandée
- Meilleurs outils de test de logiciels 2021 (Outils d'automatisation des tests QA)
- Test positif: explication de la signification et des mérites avec des scénarios de test réels
- Téléchargement de l'e-book 'Testing Primer'
- TimeShiftX est sorti pour simplifier les tests de décalage temporel
- Qu'est-ce que le test d'acceptation (un guide complet)
- Exemple de modèle de rapport de test d'acceptation avec des exemples
- Êtes-vous un expert en tests manuels ou automatisés? Travaillez à temps partiel pour nous!
- Test de charge avec les didacticiels HP LoadRunner