🥇TestRail - Paramètres individuels pour le projet

introduction

Dans de nombreux projets avec lesquels j'ai travaillé, les gens n'ont pas personnalisé TestRail pour eux-mêmes et se sont contentés de paramètres standard. Par conséquent, dans cet article, je vais essayer de décrire un exemple de paramètres individuels qui peuvent vous aider à améliorer l'efficacité de votre travail. Par exemple, prenons un projet de développement d’applications mobiles.

Un petit avertissement. Cet article ne contient pas de description des fonctionnalités de base de TestRail (il existe de nombreux guides à ce sujet) ni d'expressions commerciales décrivant de manière colorée pourquoi vous devez choisir ce fournisseur particulier pour créer un référentiel avec des tests.

Plan de justification (ce qui sera mis en œuvre)

Exigences générales
1. Absolument n’importe qui devrait pouvoir réussir l’affaire.
2. Les affaires doivent rester pertinentes aussi longtemps que possible
3. Les dossiers doivent couvrir les fonctionnalités de l'application mobile de manière aussi complète que possible, dans la mesure où cela ne contredit pas les deux premiers points.
Divisé en TestCase et TestScenario
Génération rapide de TestRun de différents types
1. Fumees
2. Régresser
3. Tests d'impact, etc.
Optimisation du support de cas
1. Abandonner les captures d'écran codées en dur « mortes » et passer aux « données mobiles »

Exigences

Pour modifier les champs, vous aurez besoin d'un accès administrateur

Sélection d'un type de projet

Vous avez le choix entre trois types de projets :

Nous sélectionnerons le type par défaut. Tous les cas y seront disponibles en même temps. Nous utiliserons un filtrage intelligent et gérerons dynamiquement tous les cas en même temps.

Ajout de champs pour afficher une liste de cas de test

Ajoutons un champ pour afficher les cas de tests prioritaires :

Vous pouvez également ajouter d'autres champs.

Configuration des champs et des balises du cas de test

Ouvrez le menu des paramètres :

Nous aurons besoin des champs suivants :

Champ « Résumé » (en-tête du scénario de test)

Ce domaine existe déjà, nous sommes juste en train de systématiser son utilisation. Nous diviserons les cas en TestCase et TestScenario. Pour une meilleure lisibilité d'une liste importante de cas, il est préférable de se mettre d'accord au préalable sur les règles de rédaction d'un résumé.

Scénario de test :

Exemple : TestScenario - Scénario de base pour l'utilisation d'une application mobile

Cas de test:

Exemple : MainScreen – Section Autorisation – Entrer la connexion

Au total, nous retrouvons dans le résumé du cas la compréhension classique : « quoi, où, quand ». Nous séparons également visuellement les scripts de test de haut niveau et les cas de test de bas niveau sous la forme la plus adaptée à l'automatisation.

Balise « StartScreen » (l'écran à partir duquel TestScenario commence ; de plus, de nombreux cas de test peuvent toucher des écrans adjacents)

Pour ce qui peut être nécessaire : nous supprimerons du texte le texte des étapes typiques des cas qui conduisent l'utilisateur à l'écran du scénario de test en cours. (étapes typiques pour créer une situation de test spécifique) Toutes les étapes typiques de tous les cas de test seront écrites dans un seul fichier. J'en parlerai plus en détail séparément.

Créez un nouveau champ :

Remplissez les composants du nouveau champ :

Dans ce cas, nous créons un champ de sélection à partir d'une liste de valeurs. Saisissez les valeurs de ce champ :

Veuillez noter que les valeurs d'identifiant ne commencent pas par un et ne sont pas consécutives. Pourquoi est-ce fait ? Le fait est que si nous avons des cas de test avec l'identifiant saisi enregistré,

et après cela il faudra créer un troisième écran entre les deux existants,

nous devrons alors réécrire l'identifiant, et comme les balises des cas de texte existants y sont déjà attachées, elles seront simplement supprimées. Ce sera très désagréable.

Tag « Screen » (nom de l'écran qui affecte TestCase)

Ce dont vous pourriez avoir besoin : une des ancres pour les tests d’impact. Par exemple, les développeurs ont créé une nouvelle fonctionnalité intéressante. Nous devons le tester, mais pour cela, nous devons comprendre exactement ce que cette fonctionnalité pourrait affecter. Par défaut, on peut partir du paradigme selon lequel les différents écrans (Activités) d'une application ont des classes différentes et constituent donc différents composants de l'application. Bien entendu, dans ce cas, une approche individuelle est nécessaire.

Exemple : home_screen, MapScreen, PayScreen, etc.

Champ « MovableData » (lien vers une base de données proxy avec des données de test modifiables)

Ensuite, nous essaierons de résoudre le problème du maintien de la pertinence des données dans les cas de test :

Liens vers les mises en page actuelles (c'est bien mieux que de prendre des captures d'écran mortes)
Étapes typiques pour accéder à l'écran avec une situation de test
Requêtes SQL
Liens vers des données externes et autres données

Au lieu d'écrire les données de test dans chaque scénario de test, nous créerons un fichier externe et y établirons un lien pour tous les scénarios de test. Lors de la mise à jour de ces données, nous n'aurons pas besoin de parcourir tous les cas de test et de les modifier, mais il sera possible de modifier ces données à un seul endroit. Si une personne non préparée ouvre un scénario de test, elle verra dans le corps du scénario de test un lien vers un fichier et un indice indiquant qu'il doit y accéder pour obtenir des données de test.

Nous regrouperons toutes ces données dans un fichier externe, qui sera accessible à tous les participants au projet. Par exemple, vous pouvez utiliser Google Sheet ou Excel et configurer une recherche dans le fichier. Pourquoi ces fournisseurs en particulier ? Le fait est que nous partons du paradigme selon lequel n’importe quelle personne de l’équipe devrait être capable d’ouvrir et de réussir un scénario de test sans avoir à installer au préalable aucun outil.

Pour Feuille Google vous pouvez 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 de recherche instantanée pratiques. (filtrage) Exemple lien.

En fait, l’idée n’est pas nouvelle et est décrite dans le livre du premier testeur « Testing dot com ». (auteur Savin Roman) Nous sommes en train d'intégrer les méthodes proposées par Roman Savin dans TestRail. Pour cela, créez un champ avec un lien vers le fichier créé :

renseignez la valeur par défaut du lien afin que chaque nouveau scénario de test ait déjà un lien :

Si l'emplacement du fichier externe change (nous prévoyons tout cas de force majeure), vous pouvez alors facilement modifier un ou plusieurs champs à la fois dans tous les cas de test :

Champ « Descriptions » (description ou idée d'un cas de test, instructions standards)

Ce dont vous pourriez avoir besoin : Dans ce champ de texte, nous placerons une brève description du scénario de test et des instructions standard.

Exemple: Toutes les données de test (mises en page actuelles, utilisation des outils et autres données) de ce scénario de test sont indiquées par des liens {...} et se trouvent dans le fichier MovableData. Lien vers MovableData dans le champ correspondant en haut.

Balise « Composant » (composant d'application mobile)

À quoi cela pourrait-il être nécessaire : pour les tests d'impact. Si une application mobile peut être divisée en composants (qui s'influencent le moins possible les uns les autres), alors les modifications apportées à un composant suffiront (avec certains risques) à être vérifiées au sein du même composant, et il y aura moins de raisons de les effectuer. régressions générales de tout. S'il existe des informations selon lesquelles un composant peut en affecter un autre, une matrice de tests d'impact est alors compilée.

Exemples de composants : GooglePay, Commande, Utilisateurs, Carte, Autorisation, etc.

Tag "TAG" (Autres tags pour le filtrage)

Balisage d'un scénario de test avec des balises pour un filtrage arbitraire.

Très utile pour :

compiler rapidement TestRun pour diverses tâches typiques : fumée, régression, etc.
les tests seront-ils automatisés ou déjà automatisés ?
toute autre balise

Exemple : Smoke, Automated, WhiteLabel, ForDelete, etc.

Paramétrage de l'ordre d'affichage des champs dans le scénario de test

Nous avons créé beaucoup de nouveaux champs, il est temps de les organiser dans un ordre pratique :

Création d'un test

Nous allons maintenant créer un nouveau test avec les cas actuels pour effectuer des tests de fumée en trois clics :

Autres conseils

Si TestRail a plusieurs projets, alors n'oubliez pas de créer de nouveaux champs uniquement pour votre projet, sinon les collègues des équipes voisines seront très surpris par l'apparition de nouveaux champs inhabituels. Un évanouissement local est possible.

2. Les cas comportant un grand nombre de champs sont plus faciles à copier à partir d'un type de groupe similaire qu'à en créer de nouveaux :

3. Les comptes peuvent être partagés. Par exemple : un administrateur, plusieurs utilisateurs.

Conclusion

Les exemples décrits ci-dessus ont été mis en œuvre sur 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 « stockages de test » efficaces et pratiques. Je vous serais très reconnaissant si vous décrivez votre expérience d'utilisation de TestRail et des conseils utiles dans les commentaires.

Liens:

Site Web du fournisseur TestRail

Livre: « Tester .COM » (auteur Roman Savin)

Merci beaucoup pour votre attention!

Source: habr.com

TestRail - Paramètres individuels pour le projet