Qu’est-ce qu’un Cas de Test ?
Dans le contexte des tests de logiciels, un scénario de test fait référence à la séquence d’actions requises pour vérifier une fonctionnalité ou une fonctionnalité spécifique. Essentiellement, le scénario de test détaille les étapes, les données, les prérequis et les postconditions nécessaires pour vérifier une fonctionnalité.
Il exposera des variables particulières dont les QAs ont besoin pour comparer les résultats attendus et réels pour conclure si la fonctionnalité fonctionne comme il se doit. Les composants du scénario de test mentionnent l’entrée, l’exécution et la sortie/réponse attendue. Fondamentalement, il indique aux ingénieurs quoi faire, comment le faire et quels résultats sont acceptables.
En savoir plus: Comment créer des Scénarios de test avec des Exemples
L’Objectif d’Écrire des Cas de test
- Pour valider des fonctionnalités et fonctions spécifiques du logiciel.
- Pour guider les testeurs dans leur activité pratique quotidienne.
- Pour enregistrer un catalogue des étapes entreprises, qui peut être revisité en cas d’apparition d’un bug.
- Fournir un plan pour les futurs projets et testeurs afin qu’ils n’aient pas à commencer à travailler à partir de zéro.
- Pour aider à détecter les problèmes d’utilisabilité et les lacunes de conception dès le début.
- Pour aider les nouveaux testeurs et développeurs à reprendre rapidement les tests, même s’ils se joignent au milieu d’un projet en cours.
Format standard du Scénario de test
- ID Du Scénario de test
- Scénario de test
- Étapes du test
- Conditions préalables
- Données de test
- Résultats attendus / attendus
- Résultats réels
- Statut du test – Réussite/ Échec
Lors de l’écriture de cas de test, n’oubliez pas d’inclure:
- Une description raisonnable de l’exigence
- Une description du processus de test
- Détails liés à la configuration du test: version du logiciel testé, points de données, système d’exploitation, matériel, habilitation de sécurité, date, heure, conditions préalables, etc.
- Tout document ou pièce jointe connexe les testeurs nécessiteront
- Une alternative aux prérequis, s’ils existent
Caractéristiques communes des Cas de test
- Susceptibles d’être révisés et mis à jour régulièrement. Les exigences logicielles peuvent changer en fonction des priorités commerciales ou des préférences des clients. Si les exigences changent, les scénarios de test devront être modifiés en conséquence. La détection des bogues et les étapes de débogage peuvent également nécessiter la modification des cas de test.
- Susceptibles d’impliquer un regroupement. Les cas de test dans un scénario de test unique doivent généralement être exécutés dans une séquence spécifique ou dans un groupe. Dans ce cas, les conditions préalables particulières d’un cas de test s’appliqueront à d’autres cas de test dans la même séquence.
- Susceptibles d’être interdépendants. Souvent, les cas de test peuvent dépendre les uns des autres. Cela est particulièrement vrai pour les applications en couches avec une logique métier à plusieurs niveaux.
- Susceptibles d’être utilisés par les testeurs ainsi que les développeurs. Les cas de test sont utiles pour les développeurs ainsi que pour les testeurs. Par exemple, lorsque les développeurs corrigent des bogues, les cas de test peuvent être très utiles pour répliquer ledit bogue. Dans le développement piloté par les tests (TDD), les développeurs créent des cas de test pour élaborer une logique métier, couvrir plusieurs scénarios de test et commencer à écrire du code.
Exemple de cas de test
Construisons un exemple de cas de test basé sur un scénario spécifique. Voici un exemple de cas.
- ID du cas de test: #BST001
- Scénario de test: Pour authentifier une connexion utilisateur réussie sur Gmail.com
- Étapes de test:
- L’utilisateur accède à Gmail.com .
- Dans le champ ’email’, l’utilisateur entre une adresse e-mail enregistrée.
- L’utilisateur clique sur le bouton » Suivant « .
- L’utilisateur saisit le mot de passe enregistré.
- L’utilisateur clique sur » Se connecter « .’
- Prérequis : Un identifiant Gmail enregistré avec un nom d’utilisateur et un mot de passe uniques.
- Navigateur : Chrome v 86. Appareil: Samsung Galaxy Tab S7.
- Données de test: Nom d’utilisateur et mot de passe légitimes.
- Résultats attendus/attendus: Une fois le nom d’utilisateur et le mot de passe saisis, la page Web redirige vers la boîte de réception de l’utilisateur, affichant et mettant en évidence les nouveaux e-mails en haut.
- Résultats réels: Comme prévu
- Statut du test – Réussite / Échec: Réussite
Meilleures pratiques pour la rédaction de cas de test
- Priorisez la clarté et la transparence. Soyez clair, concis et affirmatif en décrivant ce que le testeur doit faire et les résultats qu’il devrait idéalement obtenir.
- Concentrez-vous sur les exigences de l’utilisateur final lors de la rédaction d’exemples de cas de test. Mappez les cas de test pour refléter tous les aspects du parcours de l’utilisateur. Utilisez le Document de spécifications et le Document d’exigences pour le faire.
- Évitez les répétitions. Si plusieurs tests peuvent être exécutés avec le même scénario de test, utilisez l’ID du scénario de test pour faire référence au scénario de test requis.
- Gardez les étapes de test aussi minimes que possible. Idéalement, gardez-le à 10-15 étapes, si possible.
- Concentrez-vous sur la couverture maximale des tests. Bien que la couverture des tests à 100% soit rarement réalisable, un pourcentage élevé peut être atteint avec les bonnes stratégies.
En savoir plus: Comment assurer une couverture de test maximale?
- Créez des cas de test autonettoyants. Cela signifie que les cas de test doivent rétablir l’environnement de test dans un état vierge de pré-test. Les tests ne doivent pas laisser de restes d’eux-mêmes dans l’environnement lorsqu’ils sont terminés. Ceci fait partie intégrante de la Gestion de la configuration. Pour mieux comprendre : Qu’est-ce que la gestion de la configuration dans DevOps ?
- Formatez les cas de test pour les tests qui renvoient les mêmes résultats, peu importe qui les exécute. Assurez-vous que les tests sont autonomes.
Une fois les cas de test formés, les tests correspondants doivent être exécutés sur de vrais navigateurs, périphériques et systèmes d’exploitation. N’oubliez pas que la fragmentation des appareils est une préoccupation importante pour chaque développeur et testeur. Chaque site Web doit fonctionner de manière transparente sur plusieurs combinaisons appareil-navigateur-système d’exploitation. Avec plus de 9000 appareils distincts utilisés pour accéder à Internet dans le monde entier, tous les logiciels doivent être optimisés pour différentes configurations, fenêtres et résolutions d’écran.
Essayez de tester gratuitement sur un vrai Device Cloud
Dans cet état, aucun émulateur ou simulateur ne peut reproduire les conditions réelles de l’utilisateur. Le logiciel doit être testé sur des appareils réels pour fonctionner dans des circonstances réelles telles qu’une batterie faible, des appels entrants, une faible puissance du réseau, etc. Si un laboratoire interne n’est pas accessible, optez pour une option de test basée sur le cloud qui propose de vrais appareils.
La grille de sélénium cloud de BrowserStack offre plus de 2000 appareils et navigateurs réels pour des tests automatisés. Cela signifie que les utilisateurs peuvent exécuter des tests sur plusieurs appareils et navigateurs réels en s’inscrivant simplement, en se connectant et en sélectionnant les combinaisons requises. Les testeurs peuvent également effectuer des tests Cypress sur plus de 30 versions de navigateur réelles sur Windows et macOS. Détectez les bugs avant les utilisateurs en testant le logiciel dans des conditions réelles avec BrowserStack.
La création de cas de test bien structurés et axés sur les résultats est fondamentale pour réussir les tests. De plus, ils garantissent une couverture complète des tests et fournissent un plan clair pour la QAs à suivre. Utilisez cet article pour apprendre les bases de la création de cas de test efficaces et commencer à exécuter des tests conçus pour optimiser et offrir des expériences utilisateur haut de gamme.