Sujet numéro 1 de ma série de “Quoi de neuf?” sur Visual Studio 2010, les Test cases sont la première étape et un premier pas dans la collaboration avec Team Foundation Server pour les testeurs généralistes.

Vous avez dit Test Case ?

Que sont-ils ? Un type d’élément de travail ou Work Item en anglais. Pour ceux qui ne seraient pas familier avec le concept de work item, il s’agit de “fiches” contenant des informations nécessaires à la gestion d’un projet et sont un point charnière au sein d’une équipe. Ils leur permettent de communiquer, tracer des opérations, reporter sur des métriques de temps ou de qualité, etc.

A quoi sert un test case ? Bien plus qu’un simple type de work item supplémentaire, un test case contient des informations nécessaires à l’exécution d’un test. On y retrouve également des informations un peu plus standards dont principalement :

• Le titre
• La personne à qui le cas de test est associé
• L’état (Design, Ready, Closed)
• L’area et l’itération
• Si le test est manuel ou automatisé (Automation Status)

Quelles sont les informations nécessaires à l’exécution d’un test (manuel) ? Tout simplement les différentes étapes (Action) à réaliser par le testeur, et le résultat attendu (Expected Result) à chacune de ces étapes. Si vous les imaginez et saisissez correctement, n’importe quel utilisateur devrait être capable d’exécuter ce test sans même connaître l’application. Elle sont définies dans l’onglet Steps de la fiche de Work Item :

Factoriser des actions

On imagine facilement qu’on risque rapidement d’avoir certaines étapes qui reviennent assez souvent au travers de nos tests, surtout au sein d’une même application. Si on prend l’exemple d’une application web, la majorité des scénarios débutera par “Rendez-vous sur le site”, “Connecter vous en tant que …”. Pour éviter de trop se répéter, et surtout pour gagner du temps, nous avons la possibilité de factoriser ces actions redondantes grâce aux Shared Steps (action partagées).

Dans l’exemple que vous avez ci-dessus, je souhaite factoriser les deux premières actions. Pour cela, je les sélectionne, effectue un clic droit, puis Create Shared Steps :

Je renseigne un nom pour cet ensemble d’actions (ici Connexion), clic sur OK et me retrouve avec une seule action à la place de deux initialement :

L’idée, c’est que lors de l’exécution de ce test manuel, cet ensemble d’actions sera remplacé par son contenu :).

Vous pouvez d’ailleurs consulter ces Shared Steps directement à partir du cas de test courant, via l’onglet Other Links :

Test Case et traçabilité

Pour aller encore plus loin dans la traçabilité au niveau des tests avec Team Foundation Server, il est possible (et fortement recommandé) de préciser quels work items sont testés par ce cas de test. Pour cela, il suffit de se rendre dans l’onglet Tested Work Items :

Un assistant nous permet d’ajouter un work item. Dans le cas le plus courant, on testera un cas d’utilisation de l’application ou User Story :

On peut bien entendu ajouter plusieurs work items testés, comme vous pouvez le voir ci-dessous :

Grâce à cela, on peut très simplement savoir pour chaque spécification, tâche, bug corrigé, lesquels ont été testés et lesquels ne l’ont pas encore été (ou du moins, ceux pour lesquels aucun test n’a été planifié/prévu). Une des requêtes de work item par défaut, User Stories without Test Cases, nous permet d’ailleurs de savoir cela :

Nous donne rapidement accès à la liste des User Stories non testées :

C’est également au sein des Test Case eux mêmes que nous retrouverons les work items de Bug relevés par les testeurs. Tout est lié ! :)

Les rapports pour les tests

La dernière chose intéressante est le fait que deux rapports par défaut existent pour vos tests :

• Test Case Readiness : vous donne une vision macro des tests prêt à être exécuter au fil du temps. Vous avez vu plus haut que l’état d’origine d’un Test Case était Design, qui correspond à la phase de création du test. Un test est considéré comme Ready quand il passe dans cet état. C’est ce que ce graphique vous présente !

• Test Plan Progress : vous donne une vision macro des tests exécutés au fil du temps, et de la proportion de tests réussis/échoués.

Conclusion

Les tests cases ne sont pas simplement un nouveau type de work items, ils sont le point d’entrée des tests dans l’univers Team System. Vous vous demandez certainement comment vont être utilisés ces éléments, comment vont être exécutés les tests, etc. Nous verrons tout cela dans le billet sur le nouvel outil Camano (aka Microsoft Test and Lab Manager) :)

.Dispose();