Visual Studio 2010 – Quoi de neuf ? Microsoft Test and Lab Manager !

Anciennement appelé Camano, Microsoft Test and Lab Manager, est le nouvel outil de test de la gamme de produit Team System. Incontournable dans le monde du test au sein de l’univers Team System 2010, il fait l’objet de ce second billet sur les nouveautés autour des tests. Certains articles ont déjà été écrits à ce sujet, mais la version disponible dans la Beta 1 est complètement différente en termes d’interface et certaines fonctionnalités ont été revues.

Le principe de l’outil

Si vous vous êtes déjà intéressé à Camano, vous avez forcément une idée du principe de base : offrir un outil destiné aux testeurs généralistes hors de Visual Studio, tout en restant connecté à Team Foundation Server.

Les mots clés autour de cet outil sont :

  • Planification des campagnes de tests
  • Définition des tests
  • Organisation des tests, des configurations de tests, etc.
  • Reporting des bugs
  • Suivi de l’évolution des tests au travers des builds 
  • Exécution des tests

Camano vous permet de planifier des campagnes de tests. Ces campagnes (ou Test Plan) sont organisées sous forme de groupes de tests appelés Test Suites. Ce sont ces Test Suites qui contiennent les Test Cases dont nous avons parlé dans le billet précédent Visual Studio 2010 – Quoi de neuf ? Les Test Cases !.

Au delà d’un simple planification, Camano permet également d’exécuter les cas de tests définis. Pour cela, un nouvel exécuteur de tests manuel apparait, le Microsoft Test Runner. Cet outil n'a rien à envier à son grand frère qu’on trouvait déjà dans l’édition Team Test de Visual Studio 2008. Il guide le testeur, récolte tous les indicateurs importants et construit pour lui le work item de Bug si un report à besoin d’être fait vers l’équipe de développement suite à un problème rencontré sur l’application lors du test.

Et cela ne s’arrête par là ! Non content de vous aider avant et pendant les tests, Camano vous assiste également après ceux-ci. Il vous donne accès à des rapports de l’évolution des différentes exécutions qui ont eu lieu au cours du temps.

Cerise sur le gâteau : couplé à System Center Virtual Machine Manager 2008 et Hyper-V, il permet de gérer et d’exécuter vos tests sur des machines virtuelles, qui constituent alors votre laboratoire de test (d’où le Lab dans Microsoft Test and Lab Manager :)).

Comprendre l’organisation de l’outil

La première chose que l’on remarque lorsqu’on lance cette nouvelle version de Camano, c’est que le design et l’ergonomie ont complètement été revues depuis la version d’octobre 2008. Ceci est plutôt une bonne idée, car l’organisation est beaucoup plus logique désormais ce qui n’est pas simple à réaliser car vous allez le voir, beaucoup d’éléments sont interconnectés et se croisent dans cet outil.

image

Comment est organisée cette interface ?

On retrouve en premier une Vue (2) qu’on retrouve ici en haut à gauche Testing Center. On retrouvera deux autre vues : Lab Center et Organize. Associé à cette vue, on retrouve un Contexte (1). Ce contexte défini la liste des éléments sur lesquels vous travaillez. Pour la vue Testing Center, on retrouve “Nom du Team project – Nom de la campagne de test” (ici : le Team Project Demonstrations, et la campagne Campagne de tests côté client). nb : pour changer de serveur/team project, cliquez sur le nom du projet dans le context (1).

Une vue est constituée de plusieurs Onglets (3). Chacun de ces onglets définit une catégorie contenant les outils relatifs à cette catégorie. Ces Outils (4) permettent d’avoir accès à des listes (de tests, de configurations, etc.), de créer des éléments, etc.

Dans ce billet, nous allons nous concentrer sur les vues Testing Center et Organize.

La vue Testing Center

Cette vue est celle qui apparaît par défaut lorsqu’on lance Camano. Du fait qu’il est fortement lié à Team Foundation Server, il est impossible d’utiliser cet outil sans avoir au préalable défini un context. Pour cela, choisissez tout d’abord un Team Project dans une Collection d’un serveur TFS :

image

Une fois ceci fait, vous êtes redirigé vers l’outil Set Plan Context:

image

Ouvrez l’assistant de création d’un plan en cliquant sur New.

Comment est définit une campagne de tests ? Via :

  • Un nom, qui permet de l’identifier au fil des outils
  • Une description
  • Une area et une itération (classification des work items)
  • Une configuration d’exécution pour les tests manuels et une pour les tests automatisés
  • Des configurations cibles pour l’exécution (purement informatif, pouvant contenir différents paramètres, voir plus loin dans le billet)
  • La build utilisée (facultatif)
  • L’état de la campagne (pouvant être  : Actif ou Inactif)
  • Une date de début et une date de fin

image

Elément important pour la suite (notamment pour l’exécution du plan de test) : il est possible de modifier ici la configuration du test par défaut en cliquand sur Open à droite de Local Test Run.

Dans l’onglet Data ang Diagnostics, nous avons la possibilité de choisir ce qui sera automatiquement enregistré lors du test (nb : par défaut, la vidéo n’est pas sélectionnée) :

image

Cliquez sur Finish.

Au niveau de la campagne, cliquez sur Save and Close. Une fois terminé, sélectionnez la campagne venant d’être créée puis sur Set context :

image

Le contexte est maintenant configuré :)

Voyons plus en détail cette vue Testing Center. L’onglet Plan vous permet d’avoir une vue sur la campagne sélectionnée dans le contexte courant. L’onglet Contents, vous présente les différents cas de tests contenus dans la campagne courante. Ces cas de tests sont organisés dans des Test Suites (a gauche) :

image

La partie gauche contient la liste des test suites, que vous pouvez organiser sous forme d’arborescence : une suite pouvant en contenir d’autres. La partie droite contient les cas de tests contenus dans la suite sélectionnée.

Pour ajouter des cas de tests, vous avez deux possibilités :

  • Via le bouton Add Requirements qui va ajouter un work item de type User Story directement dans la campagne et les tests qui lui sont associés (à droite dans la vue des tests). La User Story est alors considéré comme un type particulier de Test Suite :

image

image

  • Via le bouton Add dans la vue des tests. Ceci n’a pas pour résultat d’ajouter le work item User Story testé par le ou les cas de tests ajouté(s) :

image

Remarquez sur l’on peut également :

  • Assigner un testeur à la suite
  • Créer un nouveau Test Case (bouton Add dans la partie droite)
  • Modifier les Configurations cibles à utiliser pour exécuter ces tests
  • Importer des suites de tests à partir d’une autre campagne (bouton Import) dans la partie gauche

On nous présente également l’état d’avancement de la suite, en haut à droite (le bleu signifiant qu’aucun test n’a été exécuté, vert la proportion de tests réussis, et rouge celle échouée).

L’onglet Test permet de gérer les exécution des tests inclut dans les Test Suites de vos campagnes. Il s’agit d’un tableau de bord offrant un suivi de l’état des tests :

image

Remarquez qu’automatiquement, nous avons à exécuter chaque cas de test une fois par type de configuration : Windows 7, et Vista and IE 7. (Que nous avons défini au niveau de la campagne de test). On voit donc les tests à exécuter en Bleu, les tests dont la dernière exécution est réussie en Vert, et ceux qui ont échoués, ou qui ne sont pas à exécuter en Rouge.

Nous reviendrons plus tard sur l’exécuteur de tests, mais c’est à partir de cet outil Run Tests que cela se passe :)

L’outil Analyze Test Runs, nous donne une vue des différentes exécutions de tests que nous avons déjà effectuées. Il faut savoir qu’on peut demander d’exécuter plusieurs tests à la suite, ce qui constitue une “exécution de tests” :

image

En faisant un clic droit puis Open Test Run nous avons accès à un rapport complet de l’exécution de tests. Cela nous permet d’avoir une vision claire et instantanée de ce qui s’est passé lors de cette exécution :

image

Par exemple, sur le rapport ci-dessus, on voit que 3 test cases ont été exécutés, que ont été un succès et un a échoué. Ce rapport est également accessible durant l’exécution, ce qui permet d’avoir un rapport temps réel ! :)

Le dernier outil de cet onglet Test permet de suivre les bugs qui ont été reportés.

image

Ici, on voit que 2 work items de type Bug ont été créés par l’utilisateur courant (Created by me). Au delà d’un simple outil de supervision, My Bugs permet d’aller plus loin et nous propose de vérifier qu’une correction est bien valide : en sélectionnant un bug et en cliquant sur Verify dans la barre supérieure, on rejoue directement le Test case correspondant au bug ! De plus, si on estime qu’un problème mérite d’avoir son propre cas de test, on peut en créer un directement à partir de cette interface (Create test case from bug). (On peut imaginer que la partie Connexion à l’application à échoué lors d’un test plus complet, et qu’on veut alors créer un cas de test uniquement pour cette connexion).

Un testeur travaille très souvent par rapport à une version précise de l’application ou Build. Il est donc logique d’avoir la possibilité d’associer une campagne à une build particulière. De plus, l’outil va nous proposer les tests pertinents à exécuter en fonction de certains paramètres. C’est au niveau de l’onglet Track de cette première vue Testing Center que cela se passe :

image

Sans entrer dans les détails, cet onglet nous propose 3 outils :

  • Recommended Tests : qui nous donne une liste de cas de tests dont les fonctionnalités testées ont été modifiée depuis une ancienne build
  • Queries : qui permet de gérer les requêtes sur les work items (de la même manière que le permet le Team Explorer dans Visual Studio)
  • Select Build : qui permet de sélectionner la version sur laquelle on souhaite travailler

Exécuter une batterie de tests

Un des aspects les plus intéressants de l’outil Camano est le nouvel exécuteur de tests manuels. Il permet d’exécuter un ou plusieurs tests fonctionnels et récolte un grand nombre d’informations nécessaires à la correction d’un potentiel bug. C’est le point central du crédo de l’équipe qui l’a développé : No More No Repro ! Soit en clair : plus jamais un bug non reproductible ! Plus de fiche de bug à moitié saisie, pas claire pour le développeur qui s’arrache les cheveux à essayer de reproduire les problèmes de type : “J’ai eu un message d’erreur quand j’ai cliqué là, mais je sais plus ce que j’ai fait avant…”. Attention, je ne jette pas la pierre aux testeurs, ils ont énormément de travail et on peut comprendre qu’il n’aient pas forcément le temps de tout faire. Mais plus d’excuses pour eux désormais !

Pour exécuter une batterie de tests, rendons nous dans la vue Testing Center onglet Test outil Run Tests :

image

Sur un test, ou plusieurs comme dans la capture ci-dessus, on peut exécuter le test via un clic droit et Run. Microsoft Test and Lab Manager est alors réduit, et se “transforme” en Test Runner ! On nous offre alors deux (ou trois (*)) choix : exécuter simplement le test, ou exécuter et enregistrer des informations complémentaires :

image

(*) Nous avons un choix supplémentaire comme vous pouvez le voir sur la capture, si le cas de test a déjà été exécuté et que les actions avaient été enregistré à ce moment. On peut alors demander à l’exécuteur de jouer automatiquement ce que l’on avait enregistré à l’époque. Idéal pour valider une correction de bug !

Nous choisissons bien évidemment la seconde option, pour avoir tout ce qui sera nécessaire à la résolution d’un potentiel bug. Les différents éléments que l’on enregistre sont à définir dans la configuration d’exécution. Celle-ci est définie au niveau du plan de test. Nous avons vu précédemment comment la modifier pour activer plus ou moins d’éléments à sauvegarder. Pour la démonstration, j’ai choisi :

  • Action Log : un fichier texte contenant la liste de toutes les actions ayant été réalisées
  • Action Recording : un fichier .uitest qui contient les informations permettant de rejouer automatiquement ce que l’on va faire manuellement. Dans le prochain billet sur les tests d’interfaces graphiques nous verrons qu’on pourra utiliser ce fichier pour générer un test automatiquement !
  • Video : un enregistrement de la vidéo de ce qu’il se passe sur l’écran du testeur. Idéal pour que le développeur puisse voir tout ce que fait le testeur, et comprendre plus rapidement l’origine du problème (s’il y en a un)

Voyons maintenant comment se présente l’outil :

image

On y retrouve 3 sections :

  • Tests : partie supérieure qui contient la liste des tests à exécuter. Cela correspond aux tests que nous avons sélectionné plus haut. On voit facilement quel test est en cours d’exécution, ceux qui sont encore à exécuter (en bleu) et on verra une fois un test exécuter s’il est un échec ou une réussite. On y voit également une roue crantée définissant que le test possède déjà une version automatisée
  • Test Steps : contient les différentes étapes à réaliser pour ce test. Il s’agit des étapes qui ont été définies dans le Test Case correspondant. Chacune des étapes peut être marquée comme réussie ou échouée via le bouton à sa droite. Remarquez également qu’on distingue les Shared Steps et qu’on peut choisir également le mode de test (enregistrement, ou pas)
  • Properties : cette partie est présentée sous forme d’onglet. On y retrouve un certain nombre d’informations et principalement le résultat attendu pour l’étape du test en cours de réalisation. Ceci correspond bien entendu au résultat attendu qui a été spécifié dans le cas de test.

Vous comprenez bien que plus le test est détaillé, plus il est simple pour le testeur de le réaliser. Cette phase d’exécution ne doit pas être une phase de réflexion, qui est réservée à l’écriture du cas de test.

Pour chacune des étapes, le testeur valide que le résultat qu’il obtient correspond bien à ce qu’on lui précise et indique l’état de l’étape courante :

image

Une fois le test terminé, on clic sur End Test et les enregistrements sont finalisés. On a alors la possibilité de créer un bug (s’il y a eu un problème, bien sûr…) :

image

Un formulaire s’ouvre, correspondant à celui que l’on retrouverait directement à partir du Team Explorer. Il est pré-rempli avec les informations qui ont été récoltées :

image 

La partie haute du work item est tout ce qu’il y a de plus standard (un titre, un état, etc.). Par contre la partie basse est enrichie avec un tableau contenant la liste des différentes étapes, si elles ont échouées ou non, la liste des actions réalisées, et un marque page dans la vidéo sous forme de lien qui permet au développeur d’ouvrir cet enregistrement directement au moment où l’action à été effectuée !

Nous avons également accès à une liste d’informations sur le système sur lequel a été effectué le test via l’onglet System Info. La liste des cas de tests correspondant via l’onget Test Cases et les différentes données enregistrées sous forme de liens dans l’onglet Other Links :

image

On retrouve ici le fichier .uitest, qui permettra de rejouer automatiquement le test.

A noter qu’en plus des informations enregistrées automatiquement, nous avons la possibilité d’ajouter des fichiers supplémentaires ou de prendre une capture d’écran (ou d’un morceau de l’écran). Ces fichiers seront automatiquement ajoutés en fichier joint au work item de type bug.

image

Cerise sur le gâteau, vous pouvez voir ci-dessus que le testeur à la possibilité de demander de rejouer automatiquement ce qu’il vient de réaliser :)

La vue “Organize”

Cette vue, comme son nom l’indique, permet de gérer vos campagnes de tests, vos cas de tests, etc. Elle relativement importante car c’est à cet endroit que vous aller pouvoir gérer de façon macro vos tests.

Chose importante à noter : le contexte de cette vue n’inclut pas la campagne de test. Vous pouvez donc y gérer toutes vos campagnes, contrairement à la vue Testing Center qui ne s’applique qu’à une campagne en particulier.

Le premier onglet Test Plans donne accès à la liste des différentes campagnes. Vous pouvez en créer de nouvelles, ou modifier les existantes.

image 

L’onglet Configurations permet de définir les environnements cibles pour les campagnes. Je vous en ai parlé plus haut, un test est destiné à être exécuté sur une configuration précise, “Windows 7 et IE8” ou “Windows Vista et IE 7”, etc.

image

Une configuration cible est définie par un ensemble de variables de configuration (ici Browser et Operating System). Ces variables et la liste de leurs valeurs sont définies à l’avance, via l’assistant accessible à partir du bouton Manage configuration variables :

image

A gauche, on retrouve la liste des variables, et à droite la liste de leurs valeurs. Encore une fois, il s’agit de texte purement informatif.

L’onglet Test Cases permet de gérer la liste des cas de tests. On a la possibilité d’en créer de nouveaux, d’éditer les existants et même d’en créer un à partir d’une copie d’un autre. Tout est fait pour gagner du temps ! :)

image

Enfin, le dernier onglet : Shared Steps permet de gérer les… shared steps. Nous avons parlé de ces morceaux de tests factorisés et réutilisables dans plusieurs tests dans le billet sur les Test Cases :

image

Remarquez que nous avons une fonctionnalité supplémentaire par rapport aux Test Cases ici : l’enregistrement du fichier .uitest pour pouvoir automatiser un morceau de test (Shared Step).

Conclusion

De mon point de vue, l’intégration des testeurs dans l’équipe de développement est complètement revue dans Team System 2010. Tout le processus de test interagit et est connecté avec tous les aspects du cycle de vie d’un projet et la majorité des problématiques qu’on pouvait avoir auparavant, en termes de gestion des campagnes, de suivi et de reporting à été pris en compte dans cet outil ! :)

Difficile de parler de tout ce qu’il y a dans cette nouvelle version de Camano. Le but de ce billet est de vous permettre de démarrer facilement vos essais. Nous parlerons de la partie Lab Management dans un futur article !

.Dispose();

Publié lundi 18 mai 2009 20:23 par Etienne Margraff
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires

# re: Visual Studio 2010 – Quoi de neuf ? Microsoft Test and Lab Manager ! @ lundi 18 mai 2009 21:32

C'est juste énorme les articles que tu nous fais partager, GG Etienne :)

davidrei

# re: Visual Studio 2010 – Quoi de neuf ? Microsoft Test and Lab Manager ! @ mardi 1 décembre 2009 17:01

Coucou mister gourou !!

Et ça marche aussi avec Silverlight ??

Car j'ai l'erreur suivante, dès que je clic sur la page Web comportant un plug-in Silverlight :

"Microsoft Silverlight is not supported.. Test paused."

Configuration :

"Test Runner" de "Test and Lab Manager" (Visual Studio 2010 Beta 2)

Vincent THAVONEKHAM

thavo


Les 10 derniers blogs postés

- Créer un périphérique Windows To Go 10 ! par Blog de Jérémy Jeanson le 11-21-2014, 04:54

- RDV à Genève le 12 décembre pour l’évènement “SharePoint–Office 365 : des pratiques pour une meilleure productivité !” par Le blog de Patrick [MVP Office 365] le 11-19-2014, 10:40

- [IIS] Erreurs web personnalisées par Blog de Jérémy Jeanson le 11-19-2014, 00:00

- BDD/TDD + Javascript par Fathi Bellahcene le 11-16-2014, 16:57

- Sécuriser sans stocker de mots de passe par Blog de Jérémy Jeanson le 11-15-2014, 08:58

- Où télécharger la preview de Visual Studio 2015 ? par Blog de Jérémy Jeanson le 11-13-2014, 21:33

- Les cartes sont partout ! par Le blog de Patrick [MVP Office 365] le 11-13-2014, 17:26

- [ #Office365 ] Courrier basse priorité ! par Le blog de Patrick [MVP Office 365] le 11-12-2014, 08:56

- [Oracle] Fichier oranfsodm12.dll absent du package client par Blog de Jérémy Jeanson le 11-10-2014, 20:44

- [ #Office365 ] Le chapitre 1 des Groupes est écrit, et alors ? par Le blog de Patrick [MVP Office 365] le 11-10-2014, 20:23