Bonnes pratiques
Des noms, des scénarios, des notes, une description et un environnement de test dédié : ce qui fait durer les tests.
Un test est lu plus souvent qu'il n'est écrit
Un enregistrement vous donne un test qui fonctionne en quelques minutes.Quelques minutes de plus dans GUI Test Studio en font un test que toute votre équipe peut lire : dans la chronologie, dans le rapport de confiance, et dans les rapports d'anomalie qu'il produit.
Tout ce qui suit se retrouve dans le rapport.Un rapport qui dit « Assertion bouton Enregistrer a échoué dans Paiement » indique à un développeur ce qui a cassé avant qu'il n'ouvre quoi que ce soit.
Nommer ce qui compte
Chaque étape reçoit un nom d'elle-même, comme « Clic » ou « Assertion visuelle ».Donnez aux plus importantes un nom à vous : sélectionnez le bloc et appuyez sur F2.
| Au lieu de | Nommez-le |
|---|---|
| Assertion visuelle | Assertion bouton Nouveau ticket |
| Assertion de texte | Assertion message de commande confirmée |
| Saisie de texte | Saisir le nom du client |
| Clic | Cliquer sur Valider |
Grouper les étapes en scénarios
Sélectionnez les étapes d'une partie du parcours et appuyez sur Ctrl+G : « Connexion », « Ajouter au panier », « Payer ».Un long test devient quelques chapitres colorés, le rapport dit dans lequel une exécution s'est arrêtée, et un scénario comme « Connexion » peut être réutilisé dans d'autres tests.
Pour en savoir plus : Scénarios : réutiliser des groupes d'étapes.
Laisser des notes
Un marqueur est une note sur la chronologie (M).Utilisez-le pour ce que la personne suivante ne peut pas deviner : pourquoi une assertion est assouplie, de quelles données l'étape a besoin, quoi faire quand elle échoue.
Décrire le test
Ouvrez Paramètres, Paramètres du projet et écrivez la description : ce que le test couvre, l'état d'où il part, les données dont il a besoin.
« Paiement avec une carte enregistrée.Départ : déconnecté, sur la page d'accueil, utilisateur de test qa-01 avec un panier vide.Nécessite la passerelle de paiement de test ».
Utiliser un environnement de test dédié
Les tests ne sont pas plus stables que ce sur quoi ils s'exécutent.Exécutez-les sur une machine et avec des données réservées aux tests, pas sur l'ordinateur sur lequel vous travaillez.
Un environnement dédié
- Une machine de test ou une machine virtuelle avec une taille d'écran et une mise à l'échelle fixes
- Une copie de test de votre application, avec des données réinitialisées avant chaque exécution
- Des comptes de test que personne d'autre n'utilise
- Pas de notifications, de mises à jour ni de fenêtres surgissantes pendant une exécution
Un environnement partagé ou personnel
- Votre propre bureau, où les fenêtres et les réglages changent chaque jour
- Des données de production que d'autres personnes modifient
- Un compte partagé dont le panier ou l'historique change sans cesse
- Une machine qui se met en veille, se verrouille ou installe des mises à jour en pleine exécution
Garder des tests petits et indépendants
Un test, un parcours.Dix tests courts vous disent exactement ce qui a cassé ; un long test vous dit seulement que quelque chose a cassé, et tout ce qui suit son premier échec reste non vérifié.
Chaque test doit préparer son propre état de départ, avec une étape Lancer une application ou Exécuter un script Python à son début, et ne jamais dépendre de l'exécution préalable d'un autre test.
Une liste de contrôle avant de partager un test
- Le test a une description : ce qu'il couvre et d'où il part
- Ses étapes sont groupées en scénarios nommés
- Chaque assertion a un nom qu'un développeur comprendrait
- Les valeurs qui changent (dates, totaux, numéros de commande) sont vérifiées par type, pas par valeur
- Il part d'un état connu, de lui-même
- Il a réussi deux fois de suite sur la machine de test
Toujours bloqué ?Dites-nous ce que vous essayiez de faire, et nous répondons sous un jour ouvré.Ask our team