mardi 8 avril 2014

Démarrer avec Release Management for Visual Studio 2013 : InRelease - Partie 2 : Configuration et Déploiement

Release Management for Visual Studio 2013 est un solution de Déploiement Continu permettant de créer des cycles de release répétables, apportant de la visibilité sur l'activité de déploiement et de la productivité au travers de l'automatisation des déploiements sur l'ensemble des environnements en partant d'un serveur TFS jusqu'à la production.
En s'appuyant sur des chemins de release prédéfinis, des workflows d'approbation pour le déclenchement et la validation des déploiements, l'outil va permettre de rassembler tous les packages nécessaires et procéder au déploiement de ces packages sur les serveurs cibles, le déploiement étant réalisé sous la forme d'un transaction. Une fois le déploiement effectué avec succès, l'outil peut jouer des tests automatiques et ou générer des données de test. Les mêmes étapes sont répétés au travers des différents environnements
Release Management for Visual Studio 2013 est basé sur un Workflow d'approbation métier, et une configuration centrale et flexible.
Release Management for Visual Studio 2013 est une plate forme d'orchestration que va contribuer à améliorer la coordination et la communication entre le développement, les opérations et l'assurance qualité en vue de diminuer les problèmes inhérent aux mises en production manuelles.
 
Nous allons au travers de cet article démontrer comment utiliser release management étape par étape dans le cadre d'un scénario simple: le déploiement d'une application .net et la création d'un base de données SQL. Les binaires de l'application seront déployés en s'appuyant sur une build de release TFS automatiquement.
La première chose à faire après avoir installé l'outil va être de configurer le pipeline de release que l'on souhaite mettre en place.
Pour cela, activer l'onglet Administration / Manage Pick lists, cette liste va nous permettre de définir les différentes étapes de notre processus de release, par exemple, DEV, Integration, Preprod, Production. Cette étape est obligatoire, c'est sur ces différentes étapes que vont reposer les chemins de Release
 
 Les activités de déploiement vont s'appuyer sur un certain nombre d'actions et d'outils. Release Management vient en standard avec une bibliothèque d'actions et d'outils permettant de créer des orchestrations de déploiement
A titre d'exemple, ci dessous, l'édition de l'acion create SQL Database qui utiliser SQLCMD et des arguments: 
 Les outils vont également permettre d'utiliser  des fonctions très intéressantes tel qu'un Msi Deployer, ou un Database Deployer basé sur la technologie DACPAC
 Nous avons donc configuré les étapes (Stage), nous allons maintenant construire nos environnements et les releases Paths. Les environnements se composent de machines disponibles sur le réseau sur lesquelles a été installé et configuré le Deployment Agent. POur ajouter de nouveaux serveurs, simplement activer l'onglet Configure Paths / Servers. l'écran affiche les serveurs déjà enregistrés, on peut en créer de nouveaux en cliquant le bouton New, une fonction de Scan permet de les découvrir sur le réseau.
 Les serveurs cibles étant configurés, l'étape suivante va consister à configurer les environnements, simplement en ajoutant les serveurs ou stations de travail qui les constituent. Pour cela, activer l'onglet Configure Paths / Environments, La liste des environnements existant est affichée,
Cliquer sur New pour créer le nouvel environnement, nous allons ici créer une environnement de Dev puis utiliser la commande Link Existing pour ajouter les serveurs qui vont composer l'environnement (à noter que ces serveurs sont déjà listés dans l'onglet Servers). On créera également les environnements d'intégration , de pré production et de production
La dernière étape va consister à  créer le chemin de release pour notre application, pour cela, activer l'onglet : Configure paths / Release Paths puis cliquer sur New, il suffit de nommer le Release Path puis via l'onglet Stages ajouter simplement les différentes étapes que l'on souhaite faire partie de notre pipeline de release, dans l'étape ci dessous, DEV / Integration / PRE PPROD et PRODUCTION. Sauver et fermer
 Ci dessous le Release Path que nous venons de créer affiché dans la liste.
Nous avons terminé la partie Paths, nous allons maintenant mettre en place le déploiement de l'application, pour cela nous allons utiliser l'onglet Configure Apps
Notre projet exemple est un calculateur géométrique, pour le déployer, nous allons créer un composant personnalisé basé sur les outils existants, simplement activer l'onglet component, puis cliquer sur New pour le créer. Dans notre exemple, il a déjà été créé et nous allons simplement l'ouvrir en double cliquant dessus.
Le composant a donc un nom et une description, pour la source, il est spécifié qu'il va utiliser l'output de la build TFS  définie dans le release Template (étape de configuration que l'on va voir juste après) à partir de  la source de la Drop location (\)
 activer l'onglet Deployment, dans notre exemple, on utilise l'outil XCopy Deployer pour copier les binaires vers un répertoire cible dans le serveur de l'environnement cible.
puis on se place dans l'onglet Release Template, qui va nous permettre de configurer le déploiement proprement dit, c'est l'étape qui peut s'avérer la plus complexe. Dans cet onglet sont affichés les Release Templates existants.
Cliquer simplement sur New pour créer le nouveau Release Template, Entrer un nom et une description pour le Template, choisir un Release Path et configurer la build definition en choisissant le Team project contenant le projet de développement ainsi que la build qui génére les binaires à déployer
Une fois terminé, cliquer sur la bouton Create pour valider
Un Designer graphique s'affiche (basé sur la technologie Workflow Foundation 4.0) permettant de créer la séquence du  Déploiement. Nous allons dans le cadre de cet exemple :
Glisser notre serveur cible sur la surface de design et dans la boite graphique du serveur glisser les actions suivantes :
  1. La création d'un dossier avec Create Folder
  2. La création de la base de données avec Create Database
  3. Le déploiement de l'application avec le composant GeometryCalculator Deployer
Un simple double clic sur chaque composant va permettre de configurer les paramètres, par exemple ci dessous, on définit le dossier cible qui sera créé sur le serveur
Ces actions seront alors exécutées sur le serveur cible dans l'ordre de la séquence. Dans le cas ou l'on veut déployer des binaires sur plusieurs serveurs, on va pouvoir paralléliser ces taches.
L'ensemble de la configuration est désormais terminée, la phase de création du Release Template est bien la plus complexe de l'ensemble de ce processus de mise en œuvre d'un pipeline de release.
La dernière étape va consister simplement à consommer l'ensemble des artefacts mis en place afin de créer des Releases puis de déployer ces releases.
Pour ce faire, activer l'onglet Releases puis cliquer sur New, un formulaire de saisie de release s'ouvre, Entre un nom pour la release, dans notre exemple Sample Release V1.0, sélectionner le release Template à exécuter, définir étape cible, par exemple DEV, ainsi que la build (dans notre exemple on utilise Latest afin de déployer la dernière version) Puis cliquer sur Start pour lancer le déploiement de suite ou sur Create Draft pour la lancer plus tard.
Simplement pour vérifier, ci dessous une vue des bases SQL qui ne contient pas de base de données SampleApplicationDB, ainsi que le dossier cible sur le serveur qui est vide.
La première étape lorsque que l'on démarre un release est de l'approuver, pour cela cliquer sur Approve, entrer un commentaire et valider comme montré ci dessous.
Le déploiement est ensuite démarré, on notera le statut Pending ci dessous.
Une fois la transaction de déploiement terminé, le statut est Done et la release est en attente d'approbation du déploiement, qui se fait de la même manière que pour l'acceptation du déploiement
Avant de valider, on vérifie que le déploiement s'est bien passé, ci dessous, on voit que la base de données a été créée avec succès et que les binaires ont été déployés correctement dans le dossier cible.
On peut donc procéder à la validation du déploiement comme montré ci dessous
Et on a le statut final avec un triple Done
En fermant l'écran précédent on revient à l'écran des releases, et on a le statut Released affiché
 
La suite sera de répéter ce déploiement vers les différents environnements en utilisant les étapes suivantes (stages). Pour passer une release à l'étape suivante, il suffit simplement de l'éditer et de modifier la valeur Target Stage ce qui aura pour effet de réinitialiser un nouveau Workflow de déploiement vers un nouvel environnement. Il faudra en prérequis prendre soin de configurer le release Template pour les différentes étapes.
 
Ci dessous l'onglet Integration de notre Release Template qui n'est pas configuré de même que Pre prod et Production, il suffit simplement de répéter l'opération précédente, en utilisant un environnement et des serveurs cibles différents;
 
 


lundi 31 mars 2014

Démarrer avec Release Management for Visual Studio 2013 : InRelease - Partie 1 : Installation

Une des nouveautés les plus attendues venant avec Visual Studio 2013 est bien évidemment le module permettant une gestion professionnelle des déploiements sur nos environnements projets. Pour ce faire, Microsoft a intégré l'outil InRelease à TFS, ce composant a été développé à l'origine par la société InCycle Software, et intégré sous le nom Release Management for Visual Studio 2013.
La première chose à faire pour évaluer l'outil est bien évidemment de l'installer, ce qui va être l'objet de cet article. La partie 2 de cet article sera focalisée sur la mise en place d'un pipeline de Release avec cet outil afin de démontrer la valeur et la pertinence des fonctionnalités offertes.
Prérequis à l'installation
Le premier requis consiste à avoir installé au préalable un serveur TFS 2013
Le deuxième prérequis va consister à procéder au téléchargement des éléments suivants à partir du site www.VisualStudio.com ou encore en utilisant votre abonnement MSDN :
  • Release Management Client for Visual Studio
  • Release Management Server for TFS
  • Microsoft Deployment Agent
Etape 1 :
Installer le composant Release Management Server for TFS sur le serveur d'application TFS. POur ce faire lancer l'installtion du binaire : en_release_management_server_for_team_foundation_server_2013_x64_3165245.exe
et suivre les étapes suivantes:
 Cliquer Install et attendre que l'installation soit finalisée
 Puis cliquer sur Launch afin de lancer la configuration
Entrer le compte permettant la connexion avec TFS (normalement TFSService) puis cliquer sur les boutons Test afin de valider le compte de service et le serveur de base de données
 Puis Cliquer sur Apply et c'est terminé
 
Etape 2 : Procéder à l'installation de l'agent de déploiement sur toutes les machines qui vont composer vos environnements : serveurs et stations de travail. dans notre exemple nous allons installer cet agent sur le serveur TFS juste pour démontrer les étapes et la configuration :
Installer le composant deployment Agent, pour ce faire lancer l'installation du binaire : en_microsoft_deployment_agent_2013_x86_x64_3165245.exe
L'écran suivant apparaît, cliquer sur Install:
 attendre la fin de l'installation
 Puis Cliquez sur Launch
 L'écran de configuration s'ouvre, renseigner le compte permettant de gérer les releases via Release Management for Visual Studio 2013 ( à noter que des droits particuliers devront être attribués à ce compte pour que cela fonctionne, voir plus bas dans le présent article).
 Enfin cliquer sur Apply Settings
Très important : Le compte utilisé devra être membre du groupe Project Collection Administrators et de plus, il faudra lui donner la permissions "Make Requests on behalf of others" comme montré ci dessous : Pour cela se connecter au portail Web Access de l'instance TFS, Afficher le panneau de configuration TFS et activer l'onglet sécurité

Etape 3 :
Procéder à l'installation de Release Management for Visual Studio 2013, cet outil peut être installé sur n'importe quel ordinateur capable de se connecter à l'instance TFS.
Pour cela, lancer l'installation à partir du binaire :
en_release_management_client_for_visual_studio_2013_x86_x64_3165245.exe
Cette installation est classique et va permettre de gérer nos Workflow de déploiements.
La configuration va juste demander d'entrer le nom du serveur de Release, http://ReleaseServer
si le client est installé sur le même serveur, localhost peut être utilisé.
Enfin, nous allons configurer la connection à TFS pour le client, pour cela, démarrer Release Management for Visual Studio 2013 :
Activer l'onglet Administration, puis activer le bouton "Manage TFS", Cliquer sur New, et renseigner le nom du serveur TFS, la collection cible, le path, port et protocol ainsi que le compte utilisé pour Release Manager (ayant la permission : Make Requests on behalf of others) puis cliquer sur Verify pour s'assurer que la connexion fonctionne correctement
Sauvegarder et fermer, l'écran affiche la connexion TFS créée, à noter qu'il est possible de créer plusieurs connexions à des serveurs TFS différents.
Nous sommes maintenant opérationnel pour utiliser cette nouvelle fonctionnalité. dans la partie 2 de cet article nous allons aborder la mise en place end to end d'un scénario de déploiement en ciblant plusieurs environnements.

Tests, Qualité et Agilité avec Visual Studio 2013 pour une approche Dev-Tests Partie 3 : Qualité et Agilité

La qualité a de multiple facettes, et pourra être  définie de manière différente en fonction des  objectifs et du contexte d’un projet, de plus, la qualité est difficile à mesurer.
L’agilité depuis près de 20 ans a largement démontré au travers de nombreux rapports statistiques tels que ceux du Standish Group (Chaos Report) l’efficacité de la qualité vis-à-vis de la réussite des projets.
Le cycle de vie dans le cadre d’un développement en mode Agile et plus spécifiquement SCRUM se présente comme suit :
L’équipe va garantir en s’appuyant sur une approche incrémentale, itérative et des cycles courts, une convergence avec le besoin métier et également un haut niveau de qualité, étant donné une activité soutenue de tests et la livraison d’un incrément potentiellement livrable en production à chaque fin d’itération. Ce processus, pouvant aller de 1 à 4 semaines maximum, implique une inspection des fonctionnalités produites afin de vérifier la conformité aux critères d’acceptance, ainsi que de la qualité desdits livrables aux travers des tests et du contrôle de qualité de code. Si un des points n’est pas satisfait, le livrable est rejeté et replacé dans le Product Backlog pour finalisation au Sprint suivant. Ceci est décidé au cours de la session de Sprint Review, lors de laquelle, l’équipe va présenter au Product Owner et aux parties prenantes du projet, les fonctionnalités développées lors du Sprint. Le critère de passage pour rappel est la conformité avec la « Definition of Done » ainsi que la validation du Product Owner.
L’activité de tests est donc bien évidemment au centre d’une stratégie qualité, qui en fait englobe un plus large panel d’activités dont la plupart viennent du monde agile. Nous allons donc  dans un premier temps définir quels sont les concepts clés à prendre en compte dans une stratégie qualité et nous mapperons le concept avec le ou les outils proposé par Visual Studio 2013
La DOD : Definition of Done
L’état Terminé se définit comme l’état ou la fonctionnalité d’un incrément logiciel devient potentiellement candidat à une mise en production. La Définition of Done (DOD) est une simple check-list auditable définie par l’équipe de développement et qui peut être influencée par les standards de l’organisation du projet (standard d’architecture, normes qualités etc.). La DOD est un des éléments qui va permettre de valider comme terminé le développement d’un PBI. Ci-dessous un exemple de DOD :
·        Code complété, compile et archivé dans le contrôle de code source
·        Tous les tests passent (Tests unitaires, acceptance, non régression)
·        Les critères d’acceptance du Product Owner sont validés
·        Nombre de Bugs critiques ouverts : 0
·        La couverture de code est >= 70%
·        Le nombre de warnings FXCop<=20
Coté Visual Studio 2013, la DOD fera appel au Contrôle de Code Source TFS, les tests unitaires, le calcul de couverture de code, les builds automatisés, le module de gestion de projet Agile avec Web Access, le système de suivi des bugs, et Microsoft  Test Manager
La gestion de la dette technique
La dette technique est une métaphore inventée par Ward Cunningham dans les années 90. Il compare le concept existant de dette dans le domaine financier et l'applique au domaine du développement logiciel.
Par définition, la dette technique est un ensemble d’accumulation d’imperfections techniques liées à un projet dans sa globalité, le plus souvent non visible par l’utilisateur. A l’instar d’une dette financière, Ward Cunningham parle du point de non-retour, à partir duquel nous ne serons plus capables de rembourser la dette technique. Les causes principales sont généralement une mauvaise qualité du code, un manque de tests et / ou d’automatisation des tests, l’absence de validation à fréquence régulière en se basant sur une liste DOD par exemple. Un processus de contrôle qualité et des cycles courts Agiles avec le respect d’une Definition of Done seront très efficaces pour gérer cette dette et ou l’endiguer. D’autres pratiques d’ingénierie Agile tel que le refactoring, le Pair Programming, la mise en œuvre d’analyse de code statique et dynamique ainsi que des tests de performance participeront également au contrôle de cette dette et éviter le point de non retour.
Visual Studio 2013 fournit l’ensemble des métriques permettant de piloter une dette technique et permet au travers de la plate forme de reporting de produire les rapports adhoc
 
Les points de contrôle et de Reporting
La mise  en place de tableaux de bord ou rapport de statut permettant de fournir les  métriques qui seront  vérifiées à chaque fin d’itération. Cette pratique est parfaitement en conformité avec Scrum dont les trois piliers sont la transparence, l’inspection et l’adaptation avec notamment l’opportunité à chaque fin de Sprint d’inspecter le niveau de qualité de l’incrément et potentiellement l’adapter pour être conformes aux niveau exigé par le projet avec par exemple, le niveau de Warning FXCop, le nombre de tests unitaires ainsi que la couverture de code associée, l’état de la Build tout au long du Sprint, et un rapport sur la couverture et les résultats des tests fonctionnels.
Visual Studio 2013 fournit une plate forme de reporting et également un cube OLAP qui permettra de suivre les métriques du plan qualité et de les présenter dans un rapport de statut
 
Le Refactoring : cette  pratique d’amélioration du code et de son design consiste à changer la structure interne du code sans en affecter le comportement externe, en d’autres mots, améliorer le code sans casser les tests unitaires, le refactoring ne doit être fait que pour minimiser la dette technique, ajouter de la valeur métier ou atteindre la « Definition of Done » de l’équipe
L’IDE Visual Studio fournit un outil de refactoring intégré et permet également d’intégrer sous forme de plugin des outils tiers tel que Resharper par exemple
Le Pair Programming : Lors de cette pratique, deux développeurs vont travailler sur une tache de développement et alterner à fréquence constante. Pour cela, les développeurs pourront utiliser la méthode Pomodoro par exemple. Souvent controversée, cette méthode apporte pourtant de nombreux avantages tels qu’une meilleure qualité due à une inspection er revue du code continue, on notera également une augmentation des compétences et le partage des connaissances avec également une meilleure cohésion dans l’équipe. Généralement le code produit est plus rapidement conforme à la Definition of Done.
 Test Driven Development (TDD) : Cette pratique combine la technique de refactoring avec le fait d’écrire les tests unitaires avant le code d’implémentation.  Le développeur écrit donc les spécifications détaillées de l’application et obtiendra de manière générale un meilleur design de son code. C’est une technique puissante pour éviter les défauts dans une application et garantir un haut niveau de couverture de code.
Le couplage des tests unitaires et du refactoring font que Visual Studio 2013 est un outil parfaitement adapté à une approche TDD
Analyse de code statique : cette fonction va relever la présence de défauts dans le code et lever des warnings  ou des erreurs lors de la compilation. Le principe est de confronter le code écrit aux 200 règles et bonnes pratiques édictées par Microsoft couvrant les domaines suivants : Design, globalisation, interopérabilité, maintenabilité, conventions de nommage, performance, stabilité, sécurité, et usage de code. L’analyse statique de code doit être utilisée dans le cadre du processus d’intégration continue, mais également dans le cas de développement externalisés ou encore dans le cadre d’audits.
Avec le module d’analyse de code statique, il est possible dans Visual Studio ainsi que dans le processus de Build d’intégrer une politique qualité personnalisable basée sur des templates :
 
 
Sprint Reviews : Le Sprint Review est un évènement qui clôture un Sprint et qui a pour vocation l’inspection des fonctionnalités délivrées afin de valider si l’incrément sera accepté ou replacé dans le Product Backlog. Cet évènement fait partie de la stratégie qualité, car c’est à ce moment que le Product Owner inspecte en présence des parties prenantes les fonctionnalités livrées pour validation ou non.
 
Intégration continue (CI) : Cette pratique implique que les développements intégrés dans le contrôle de code source doivent faire l’objet à fréquence fixe ou lors d’évènements tel que le check in d’un développeur d’une compilation globale avec un jeu complet des tests unitaires ainsi que d’un processus d’analyse de code statique.
Dans Visual Studio 2013, le support de l’intégration continue repose sur le service de Build, permettant de créer des builds des solutions composant un projet avec le jeu des tests unitaires et le contrôle de l’analyse statique du code. Une fonctionnalité particulièrement intéressante avec Visual Studio est le Gated Check in. Sur le principe, dès qu’un développeur va soumettre son code pour archivage, l’archivage ne sera accepté qu’à la condition ou le code fusionne et compile avec succès avec le code coté serveur. Techniquement, TFS crée un Shelve coté serveur, fusionne le code proposé par le développeur puis le compile. En cas d’échec,  l’archivage est rejeté, dans le cas contraire, le code est intégré au contrôle de code source. Ci-dessous la configuration d’un build avec l’analyse de code et le jeu des tests unitaires :
Déploiement Continu (CD) : Ce concept va permettre à  l’issue d’un build de déployer automatiquement l’ application afin que les testeurs aient en permanence la dernière version à tester. Le déploiement continu constitue une automatisation à très haute valeur ajoutée qui de plus va engendrer des économies importantes de temps à l’équipe car il s’agit  très souvent d’une tache fastidieuse et répétitive.
Visual Studio 2013 va proposer cette fonctionnalité de déploiement continu en se basant sur la brique Lab Management via les workflows BDT (Build Deploy Test). Dans ce cas la solution est compilée, testée unitairement puis déployée sur un environnement cible puis des tests automatisés ou manuels pourront être joués sur ces environnement. Ci-dessous un lab avec un serveur d’application et un client provisionné dans Lab Center :

 
 
Une autre possibilité consistera à modifier les templates de builds pour invoquer des déploiements tels que Click Once et Web Deploy à  la fin d’un build, si les tests ont été réalisés avec succès.
Ci-dessous un template de Build en mode édition montrant le designer XAML permettant la modification du workflow de build avec l’ajout de séquences de déploiement (la technologie sous-jacente est Workflow Foundation 4.0)
 
Automatisation des Tests : Cette pratique va consister simplement à intégrer le jeu des tests de non régression au processus d’intégration continue. L’automatisation pourra également inclure des tests automatisés d’interfaces utilisateurs.
Visual Studio avec la plateforme de build et la mise en œuvre de scenario BDT avec Lab Management vient outiller ce scenario de bout en bout.
Gestion des Bugs : Quand bien même, en  Agile, la devise pour les bugs est : "Just Fix them, don't manage them!" (Fixez les, ne les gérez pas !), un système de gestion d’anomalies est au centre d’une stratégie qualité, ceci particulièrement lorsque l’application est utilisée par des équipes autres que l’équipe de développement, ou encore lorsque certains bugs ne pourront pas être gérés dans le Sprint en cours, à ce moment-là , ils pourront être tracés dans le système de suivi d’anomalies. Un des pointé intéressant du suivi des bugs est aussi le suivi de la volumétrie des bugs et également celui des bugs critiques qui potentiellement peuvent être bloquant pour la validation d’un Sprint, avec par exemple l’inclusion dans la Definition of Done de la clause 0 bugs critiques.
Avec Visual Studio 2013, deux outils permettront la création et la gestion des bugs : pour les testeurs, il s’agit de Test Runner, qui va permettre la création de bugs riches grâce au collecteur intégré, pour toutes les autres parties prenantes, la plateforme Web Access va permettre la création et le suivi des bugs au travers du tableau de bord du portail Web Access et aussi des requêtes de work items.
 
Coté développeur,  Visual Studio 2013 apportent de nombreuses fonctionnalités qui vont permettre  un meilleur contrôle de la qualité du code avec :

Code Lens : Cet outil confère un affichage de type tableau de bord dans l’IDE au niveau fonction mais aussi au niveau du type permettant au développeur de disposer d’informations contextuelles, de manière configurable via le menu options, avec :

·        Statut des Tests unitaires
·        Testé par
·        Références
·        Auteur
·        Changements
·        Work items / bugs
·        Code Reviews
Le développeur peut non seulement consulter les informations mais aussi accéder à ces informations en cliquant sur les hyperliens tel que montré ci-dessous :

Code maps : cette fonctionnalité permet de retranscrire des portions de code en format Visuel et analyser efficacement les dépendances du code .Il permet d’appréhender la complexité par le visuel et  de mieux gérer la structure du code pour mener à bien une tache de refactoring par exemple.  
 En conclusion, la richesse fonctionnelle de la plate forme Visual Studio 2013 va permettre d’intégrer ses équipes dans une réelle approche Dev-Tests au travers d’outils performant centré sur la qualité, l’agilité, l’automatisation et la productivité. L’outillage des méthodes et pratiques explicitées dans cet article avec Visual Studio 2013 permettra  d’optimiser la probabilité de réussite de tout projet informatique.

Tests, Qualité et Agilité avec Visual Studio 2013 pour une approche Dev-Tests Partie 2 : Visual Studio 2013: L’outillage pour les Tests

L’offre Visual studio 2013 ne propose pas moins de 4 modules répondant à l’ensemble des besoins en termes d’écriture et d’exécution des Tests. Nous allons les passer en revue puis démontrer comment en quelques minutes il est possible de mettre en œuvre un plan de test via le nouveau module Web de Test Manager 2013
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.
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
Une fois renseignées, les listes apparaissent au-dessous du nœud parent du plan de test comme montré ci-dessous :
Astuce : Lors de la création des suites, on souhaite avoir un affichage suivant un ordre spécifique, pour cela, il suffit préfixer les suites par des chiffres permet d’obtenir l’ordre souhaité.
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
Les PBIs sont ainsi ajoutés à la suite sélectionnée.
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 :
 
Test Runner : Cet outil permet l’exécution des cas tests tout en  assurant en tache de fond la collecte d’artefacts techniques et non techniques qui permettront de joindre facilement des commentaires et des captures d'écran durant la session de test, ces informations seront automatiquement téléchargées dans lors de la création  de bugs, fournissant des informations riches aux développeurs permettant de reproduire et comprendre le bug. De plus, les bugs et les cas de test sont liés automatiquement ce qui permettra de ré exécuter facilement le test pour valider le fix. Les données collectées automatiquement sont :  
·        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 :

 
Ci-dessous  un autre exemple du collecteur avec la trace Intellitrace, la liste des thread et les données d’exception, cette information est ouverte à partir de l’onglet All links.
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,

 Visual Studio 2013 permet l’écriture des tests unitaires avec la possibilité d’utiliser plusieurs Framework de tests qui sont pluggables dans l’IDE et fournit notamment l’ensemble des fonctionnalités de refactoring nécessaires à la mise en œuvre d’une approche TDD  (Test Driven Development), pratique par laquelle le développeur va procéder à l’écriture des tests avant l’écriture du code d’implémentation. Nous allons démontrer à l’aide d’un exemple extrêmement simple basé sur une classe de calcul mathématique cette approche TDD avec Visual Studio 2013
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.