Microsoft Test Manager 2013 (MTM) est un client lourd pour l’écriture et l’exécution des cas de tests fonctionnels encore appelés tests d’acceptance. MTM va permettre également de conduire des sessions de tests exploratoires. Le point fort de ce module est la capacité à enregistrer les actions effectuées par le testeur pour générer automatiquement un cas de test à partir de la session exploratoire, de façon à pouvoir les répéter.
MTM va permettre également une automatisation partielle ou complète de l’exécution des tests via une fonctionnalité d’enregistrement des actions effectuées par le testeur.
MTM va permettre également une automatisation partielle ou complète de l’exécution des tests via une fonctionnalité d’enregistrement des actions effectuées par le testeur.
L’intérêt
est que le testeur pourra alors sélectionner plusieurs actions et lancer
contextuellement la commande Play pour voir ces actions jouées automatiquement
lui permettant d’arriver plus rapidement à l’étape de validation du Test.
La grande nouveauté apportée
par Visual Studio 2013 est le support Web pour la gestion et l’exécution des
tests avec Web Access 2013 permettant à l’instar de test Manager les actions
suivantes :
·
La création
de plans de test.
·
La gestion
des suites de test.
·
La
création de cas de tests incluant le support des étapes partagées et
l’utilisation des paramètres
·
L’entrée
et l’édition en masse des cas de test à l’aide d’une Grid View
·
La copie
de cas de tests à partir d’Excel vers un Grid View et vice versa.
·
L’exécution
des tests.
·
L’édition
de tests lors de l’exécution.
·
Tester des
Application Windows Store sur un périphérique distant (tablette, téléphone)
Afin de démontrer la
productivité et la simplicité pour la mise en œuvre d’un plan de test avec
Visual Studio 2013, nous allons utiliser la version Web, dont l’un des attraits
est qu’il permet aux équipes de tests de démarrer rapidement sans avoir à
installer de logiciels sur leur poste de travail. Les différentes étapes à
suivre sont : La création d’un plan de test
Un plan de test est un conteneur de suites et cas de tests. Un plan de test est généralement utilisé pour déterminer les tests à exécuter et valider une itération donc typiquement des Sprints. On pourra également avoir des plans de tests de Release ou de non régression.
La création d’un plan de test est extrêmement simple comme montré ci-dessous :
Etant connecté au portail Web Access, activer l’onglet Test puis appeler la commande : Création de Plan de test comme montré ci-dessous
Renseigner le nom du plan de
test puis valider. On créera généralement un plan de test par Sprint ou
itération.
Nous allons ensuite organiser notre plan de test en suites de tests qui permettent de créer une arborescence hiérarchique à l’intérieur d’un plan de tests, par exemple dans un scénario Scrum of Scrums pour séparer les tests des différentes équipes.
Nous allons dans notre exemple créer deux suites : Développement et Déploiement en utilisant la commande Ajout de suite statique
L’étape suivante va consister
à ajouter des Exigences ou PBIs (Product Backlog Item équivalent d’une User
Story en Scrum) aux différentes suites :
Pour cela on utiliser la
commande d’ajout d’exigences : " Requirement Based Suite " 
Il suffit alors simplement d’exécuter la requête proposée que l’on peut modifier si nécessaire, puis sélectionner les PBIs à tester et valider en cliquant le bouton Ajouter
Note : Il est important de relier les cas de tests aux PBIs testés afin de pouvoir rapidement à l’aide des outils de Reporting, estimer la couverture fonctionnelle des tests. Pour cela, une fois le plan de test décomposé en suites, il suffit d’ajouter les PBIs du Sprint en cours aux différentes suites.
La dernière phase va consister à écrire l’ensemble des cas de tests nécessaires à la validation des critères d’acceptance des PBIs.
Simplement cliquer droit sur le PBI à tester puis lancer la commande « New Test Case »
Chaque cas de test sera décomposé en étapes se composant d’une action et d’un résultat attendu permettant de valider l’étape. On remarquera la possibilité d’utiliser le format Rich Text pour améliorer la lisibilité
Ci-dessous un exemple de cas de tests
Nous avons vu la simplicité
pour la mise en place d’un plan de test. Tout testeur expérimenté sait combien
il peut être fastidieux de mettre en place des campagnes de tests. Visual
Studio 2013 là encore va apporter un
certain nombre d’outils de productivité permettant de réduire considérablement
la charge à dédier à l’écriture des cas de tests avec notamment les
fonctionnalités suivantes :
1 - La fonction de clonage
des tests
Souvent les tests se
ressemblent et la fonction de clone va permettre d’accélérer considérablement
l’écriture des tests par un simple clic droit sur le cas de test et l’appel de
la commande « créer une copie et ajouter à la suite ». Il est
également possible de cloner des suites entières.
2 - La fonction de Copier-coller à partir d’Excel
Cette fonction permettra une saisie en masse particulièrement performante, ci-dessous 2 cas de tests saisis dans Excel qui sont placés dans le presse papiers
Il suffit
d’activer la vue GridView
Puis
simplement coller le contenu dans la grille et sauvegarder
Ci-dessous le résultat après
sauvegarde, les deux cas de tests sont créés. Le mode GridView peut également
être utilisé pour effectuer de la saisie au kilomètre de cas de tests.
3 - L’utilisation des Shared Steps
(Etapes partagées)
Cette fonctionnalité permet
de factoriser l’écriture des tests en réutilisant des groupes d’actions
récurrentes telle que la connexion à l’application testée par exemple.L’utilisation est extrêmement simple, il est possible de générer un Shared Steps directement à partir d’un cas de test existant, tout simplement en sélectionnant la séquence d’actions servant de base à la séquence récurrente puis en appelant contextuellement la commande « Create Shared Steps ».
Il sera alors possible de les
consommer à partir de n’importe quel cas de test en utilisant la commande
« Insert Shared Steps » à partir de la barre d’outils des actions.
4 - L’utilisation des
paramètres
L’entrée des données dans un
cas de test peut être variabilisée dans l’outil, ce qui permettra d’une part au
testeur de ne pas avoir à saisir les données dans l’interface durant
l’exécution des tests mais de les injecter dans les contrôles de l’application ,
et également d’utiliser le concept de jeux de données de tests, permettant de rejouer
le même cas de tests sur plusieurs jeux de données. Par exemple pour éviter au
testeur d’écrire les titres des taches à insérer dans notre application exemple,
nous pouvons les entrer sous la forme de paramètres dans le cas de test, pour
cela, sélectionner l’action ou l’on veut insérer le paramètre, et cliquer sur
le bouton « Insert Parameter »
Enfin nommer le paramètre (préfixé par le signe @) et
renseigner sa valeur au-dessous de la grille :
Une fois le plan de test
écrit, les tests sont prêts pour être exécutés via le module Test Runner, soit
avec la version Web ou la version Client riche, qui aura plus de fonctionnalité.
On remarquera bien
évidemment que le plan de test écrit dans l’interface Web est bien évidemment
consultable et modifiable à partir de Test Manager comme montré ci-dessous :
·
les étapes
du cas de test avec les résultats
·
l’enregistrement
vidéo de la session de test
·
les
données Intellitrace avec les données d’exception qui permettront aux
développeurs de résoudre beaucoup plus rapidement le bug avec également les
threads d’exécution, et la Stack Trace
·
les
informations systèmes et les entrées du journal d’évènement
Bien évidemment, le
collecteur est configurable via les propriétés du plan de test.
Ci-dessous un exemple de
données collectées via Test Runner avec les étapes et les enregistrements
vidéos associés, on notera le découpage de la vidéo par action du cas de test :
Visual Studio 2013 propose
également du reporting permettant de suivre l’activité de test. Ci-dessous le
rapport Backlog Overview qui permet d’analyser la progression par exigence ou
PBI, ainsi que le nombre de tests écrits et le résultat de l’exécution des
tests ainsi que le nombre de bugs ouverts:
Ci-dessous le module de
reporting intégré à MTM qui permet de
voir le statut d’exécution des tests par testeur ou par suite.
Les tests technique,
Nous partons d’une solution
contenant un projet de type Class Library Math et son projet de Test
UnitTestMath. On notera qu’au début, aucun type n’est présent dans le projet
Math, tout sera généré par les fonctions de refactoring de Visual Studio 2013
:
Le principe TDD consiste à
décrire les fonctions avant leur implémentation via les tests, ce qui a pour
effet dans un premier temps de ne plus compiler comme montré ci-dessous après
avoir écrit le test de la fonction Addition de la classe Operation qui n’existe
pas encore, nous allons ensuite générer le type Operation et la fonction Addition :
A l’aide des fonctions de
refactoring, nous allons dans un premier temps générer le type Operation dans
le projet Math comme montré dans la capture d’écran ci-dessus. Puis nous allons
générer dans ce nouveau Type Operation, la méthode Addition. Les opérations de
refactoring sont lancées à partir des SmartTag comme montré ci-dessous
On se
retrouve à l’étape ou la méthode est générée sous la forme d’un stub, et le
test qui ne passe pas :
Il suffit
d’écrire l’implémentation de la méthode Addition et relancer le test pour
terminer le cycle TDD, le test passe alors en vert
Enfin Visual Studio va
également permettre d’écrire des tests unitaires « fonctionnels » qui
seront joués en tant que tests d’acceptance via Test Manager. Généralement, ces
tests appellent des fonctions de haut niveau qui vont combiner l’appel de
plusieurs fonctions au travers des différentes couches de l’application, on les
appelle parfois des tests « sous cutanés » car ils réalisent des
appels juste au-dessous de l’interface utilisateur. Ces tests pouvant
s’apparenter à des tests fonctionnels, il est possible de les inclure dans des
cas de test. Pour cela, ouvrir le cas de test concerné dans Visual Studio,
activer l’onglet « Associated Automation » puis sélectionner le
test d’intégration et valider. Ce test pourra être joué de manière automatique
dans vos scénarios BDT et également lancés manuellement. L’avantage de cette
technique est qu’elle va permettre de limiter l’écriture de « UI Coded
Tests » ou tests d’interface automatisés, pouvant être plus complexes et
consommateurs de temps en termes de maintenance, le mix des deux est
généralement le meilleur scenario.
Enfin les
tests d’interfaces automatisés ou UI Coded Tests vont permettre de créer des tests interactifs avec
l’interface utilisateur. L’intérêt de ces tests réside dans la simplicité de mise en œuvre grâce à un
enregistreur d’actions, permettant à tout membre de l’équipe d’en créer y
compris des profils fonctionnels. Ils sont maintenables et modifiables car
cette technologie génère du code .Net. La maintenance en revanche va requérir
des compétences de développement
Note : Il est important
de sensibiliser les développeurs au respect des normes de développement pour
produire des interfaces testables notamment en respectant des conventions de nommage des
contrôles et la fixation systématique des UI Automation Properties dans les
balises XAML en WPF. Les gains apportés en retour par l’automatisation des
tests rembourseront largement cet investissement.
Aucun commentaire:
Enregistrer un commentaire