Introduction
Dans de nombreux projets sur lesquels j'ai travaillé, les gens n'ont pas configuré TestRail selon leurs besoins et ont utilisé les paramètres par défaut. Dans cet article, je vais donc essayer de décrire un exemple de configurations personnalisées qui peuvent vous aider à améliorer l'efficacité de votre travail. Prenons comme exemple un projet de développement d'application mobile.
Un petit disclaimer. Cet article ne décrit pas les fonctionnalités de base de TestRail (il existe de nombreux guides à ce sujet) ni d'expressions vendeuses décrivant de manière colorée pourquoi vous devriez choisir ce fournisseur pour créer un référentiel de tests.
Plan de justification (ce qui sera réalisé)
Exigences générales
Le cas doit pouvoir être traversé par absolument n'importe qui
Les cas doivent rester pertinents aussi longtemps que possible
Les cas doivent couvrir le fonctionnement de l'application mobile de manière aussi exhaustive que possible, tant que cela ne contredit pas les deux premiers points
Séparation en TestCase et TestScenario
Création rapide de TestRun de différents types
Smoke
Regression
Tests d'impact, etc.
Optimisation du support des cas
Abandon des captures d'écran « mortes » en dur et passage aux « données mouvantes »
Exigences
Pour éditer les champs, vous aurez besoin d'un accès administrateur
Choix du type de projet
Trois types de projet sont disponibles :
Nous choisirons le type par défaut. Tous les cas seront disponibles simultanément. Nous utiliserons une filtration intelligente et gérerons dynamiquement tous les cas à la fois.
Ajout de champs pour afficher la liste des test cases
Ajoutons un champ pour afficher la priorité des test cases :
D'autres champs peuvent également être ajoutés.
Configuration des champs et des tags du test case
Ouvrons le menu de configuration :
Nous aurons besoin des champs suivants :
Champ « Résumé » (en-tête du test case)
Ce champ existe déjà, nous allons seulement systématiser son utilisation. Nous allons séparer les cas en TestCase et TestScenario. Pour une meilleure lisibilité d'une longue liste de cas, il est préférable de convenir à l'avance d'un règlement pour la rédaction du résumé.
TestScenario :
Exemple : TestScenario — Scénario principal d'utilisation de l'application mobile
TestCase :
Exemple : MainScreen — Section d'authentification — Saisie du nom d'utilisateur
Ainsi, nous voyons dans le résumé du cas une compréhension classique : « quoi, où, quand ». Nous séparons également visuellement les scénarios de test de haut niveau et les test cases de bas niveau dans la forme la plus adaptée à l'automatisation.
L'étiquette «StartScreen» (l'écran à partir duquel commence le TestScenario, de nombreux cas de test peuvent également toucher les écrans adjacents)
À quoi cela peut-il servir : nous allons retirer du texte des cas de test les étapes types qui amènent l'utilisateur à l'écran du cas de test actuel. (étapes types pour créer une situation de test spécifique) Toutes les étapes types pour tous les cas de test seront rédigées dans un fichier unique. J'en parlerai plus en détail séparément.
Créons un nouveau champ :
Remplissons les composants du nouveau champ :
Dans ce cas, nous créons un champ de sélection parmi une liste de valeurs. Nous saisissons les valeurs de ce champ :
Veuillez noter que les identifiants des valeurs ne commencent pas par un et ne sont pas consécutifs. Pourquoi est-ce fait ? Parce que si nous avons des cas de test enregistrés avec un identifiant donné,
et après cela, nous devrons créer un troisième écran entre deux existants,
nous devrons réécrire les identifiants, et comme ils sont déjà liés aux étiquettes des cas de test existants, ceux-ci seront tout simplement supprimés. Ce sera très désagréable.
L'étiquette «Screen» (nom de l'écran concerné par le TestCase)
À quoi cela peut-il servir : un des ancres pour les tests d'impact. Par exemple, les développeurs ont créé une nouvelle fonctionnalité géniale. Nous devons la tester, mais pour cela, il faut comprendre quelles fonctionnalités pourraient être touchées. Par défaut, nous pouvons partir de la parabole selon laquelle différents écrans (Activity) de l'application ont différentes classes et, par conséquent, composent différents composants de l'application. Bien sûr, dans ce cas, une approche individuelle est nécessaire.
Exemple : home_screen, MapScreen, PayScreen, etc.
Champ «MovableData» (lien sur la base de données proxy avec des données de test modifiables)
Ensuite, nous allons essayer de résoudre le problème du maintien de la pertinence des données dans les cas de test :
Liens vers des maquettes actuelles (c'est bien mieux que de faire des captures d'écran mortes)
Étapes types vers l'écran de situation de test
Requêtes SQL
Liens vers des données externes et autres données
Au lieu de coder des données de test directement dans chaque cas de test, nous allons créer un fichier externe et y référencer tous les cas de test. Lors de la mise à jour de ces données, nous n'aurons pas besoin de passer en revue tous les cas de test pour les modifier, mais nous pourrons simplement changer ces données à un seul endroit. Si une personne non préparée ouvre un cas de test, elle verra dans le corps du cas de test un lien vers le fichier et un indice qu'il faut s'y rendre pour les données de test.
Nous regrouperons toutes ces données dans un seul fichier externe, qui sera accessible à tous les intéressés dans le projet. Par exemple, nous pouvons utiliser Google Sheet ou Excel et configurer la recherche dans le fichier. Pourquoi ces fournisseurs en particulier ? C'est parce que nous partons du principe que toute personne de l'équipe doit pouvoir ouvrir et suivre un cas de test sans avoir besoin d'installer diverses outils au préalable.
Pour Google Sheet il est possible d'utiliser des requêtes SQL. Exemple :
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")Pour Excel vous pouvez configurer des macros pratiques pour une recherche instantanée. (filtrage) Exemple .
En fait, l'idée n'est pas nouvelle et est décrite dans le premier livre du testeur « Test de dot com ». (auteur Roman Savin) Nous intégrons simplement dans TestRail les méthodes proposées par Roman Savin. Pour cela, nous allons créer un champ avec un lien vers le fichier créé :
nous remplissons la valeur par défaut du lien, afin qu'il y ait déjà un lien dans chaque nouveau cas de test :
Si l'emplacement du fichier externe change (nous prévoyons tous les cas de force majeure), il sera facile de modifier un ou plusieurs champs dans tous les cas de test à la fois :
Champ « Descriptions » (description ou idée du cas de test, instructions types)
À quoi cela peut-il servir : Dans ce champ de texte, nous intégrerons une brève description du cas de test et des instructions types.
Exemple : Toutes les données de test (maquettes actuelles, utilisation des outils et autres données) de ce cas de test sont indiquées par des liens {…} et se trouvent dans le fichier MovableData. Le lien vers MovableData est dans le champ correspondant en haut.
Tag « Component » (composant de l'application mobile)
À quoi cela peut-il servir : pour les tests d'impact. Si l'application mobile peut être divisée en composants (qui s'affectent le moins possible les uns les autres), il suffira de vérifier les modifications dans un composant (avec certains risques) dans le cadre de ce même composant, ce qui réduira les raisons de procéder à des régressions générales de tout et de tous. S'il y a des informations indiquant qu'un composant peut affecter un autre, une matrice de test d'impact est établie.
Exemple de composants : GooglePay, Commande, Utilisateurs, Carte, Authentification, etc.
Tag «TAG» (autres tags pour le filtrage)
Étiquetage des cas de test avec des labels pour un filtrage arbitraire.
Très utile pour :
la création rapide de TestRun pour diverses tâches types : smoke, régression, etc.
s'il y aura des tests automatisés ou s'ils sont déjà automatisés
tous les autres tags
Exemple : Smoke, Automatisé, WhiteLabel, PourSuppression, etc.
Configuration de l'ordre d'affichage des champs dans le cas de test
Nous avons créé de nombreux nouveaux champs, il est temps de les organiser de manière pratique :
Création d'un TestRun
Nous allons maintenant créer un nouveau test run avec des cas pertinents pour effectuer des tests smoke en trois clics :
Autres conseils utiles
Si plusieurs projets sont présents dans TestRail, n'oubliez pas de créer de nouveaux champs uniquement pour votre projet, sinon vos collègues des équipes voisines pourraient être très surpris par l'apparition de nouveaux champs inhabituels. Des évanouissements locaux peuvent survenir.
2. Il est plus facile de copier des cas avec un grand nombre de champs d'un groupe similaire que de créer de nouveaux cas :
3. Il est possible d'utiliser des comptes en commun. Par exemple : un compte administrateur, plusieurs comptes utilisateurs.
Conclusion
Les exemples ci-dessus ont été implantés dans plusieurs projets et ont montré leur efficacité. J'espère qu'ils vous aideront à améliorer votre compréhension de cet outil et à créer des « banques de tests » efficaces et pratiques. Je vous serais très reconnaissant si vous pouviez partager votre expérience d'utilisation de TestRail et vos conseils utiles dans les commentaires.
Liens :
Livre :
Merci beaucoup pour votre attention !
Source : habr.com
