Plans de test

Un plan de test est une sélection nommée de cas de test — une playlist, pas un dossier. Les cas de test sont autonomes et de premier ordre ; un plan de test les référence. Le même cas de test peut figurer dans un plan de smoke test et dans un plan de vérification de mise en production, et le corriger une fois le corrige partout.

Les plans de test se trouvent dans Test Plans du tableau de bord. Les cas de test se trouvent dans Test Cases.

Pourquoi des sélections plutôt que du rangement

Si chaque cas de test devait appartenir à un seul plan de test, tout cas nécessaire à deux suites devrait être dupliqué — et les cas dupliqués dérivent. Le référencement résout le problème : une seule définition, plusieurs appartenances, aucune copie à synchroniser.

Un cas de test n'a pas besoin d'un plan de test. Exécuter un cas de test directement, ou désigner un cas de test comme cible par défaut d'un dépôt GitHub, reste un flux de premier ordre.

Exécuter un plan de test

Exécuter un plan de test produit une exécution par cas de test membre, regroupées sous une exécution de plan. L'exécution reste l'unité atomique de preuve — chaque cas de test membre obtient sa propre chronologie, ses artefacts et son espace de preuves, exactement comme s'il avait été exécuté seul.

Le statut de l'exécution de plan est dérivé de ses membres, jamais stocké indépendamment. Ainsi, le résumé ne peut jamais contredire les exécutions sous-jacentes : si un membre est encore en cours, l'exécution de plan est en cours ; si un membre a échoué, l'exécution de plan a échoué.

Ordre

L'appartenance porte un ordre : un plan de test exécute ses cas de test dans la séquence que vous avez définie. Utilisez-le lorsqu'une suite se lit mieux dans un ordre particulier. Ne l'utilisez pas pour transmettre un état entre les cas de test — chaque cas de test doit établir et vérifier son propre parcours, sous peine de voir un seul échec se propager à tout ce qui suit.

Où apparaissent les plans de test

• Dans le tableau de bord, sous forme d'une exécution de plan dont la ligne se déplie en exécutions membres.
• Dans une commande GitHub, sous forme d'un nom que vous pouvez passer : @autonomy run plans "Release readiness".
• Comme cible par défaut d'un dépôt, afin qu'un simple @autonomy test this exécute le plan de test complet. Un dépôt peut avoir pour cible par défaut un cas de test ou un plan de test, mais pas les deux.

Choisir ce qu'il faut regrouper

Gardez les plans de test courts et nommez-les d'après une décision qu'il faut prendre :

• Smoke — les quelques parcours qui doivent fonctionner avant de vérifier quoi que ce soit d'autre.
• Release readiness — ce que vous vérifiez avant de livrer.
• Par surface — paiement, onboarding, facturation.

Évitez un plan « tout inclus ». Un plan de test qui a toujours un échec sans rapport apprend aux relecteurs à l'ignorer.