Test Manager : Trucs et actuces

Après notre session des TechDays 2012 : MS TechDays 2012 - Mise en place d'une usine logicielle avec TFS et Test Manager 2010, et suite aux questions de fin de séance, nous avons eu l’idée de collecter les différentes « bonnes » pratiques ainsi que les trucs et astuces au sein de notre équipe de test.

Merci à Jean Dieu (QA Manager) et Marc Huhardeaux qui sont les auteurs des conseils ci-dessous

Recommandations générales
Stratégie des tests

Dans le Test Manager, séparez les tests de bases des tests fonctionnels.

Tests de base
Les tests de base regroupent :

• Tous les ‘clics’ possible sur un écran de l’application 
• Chasser toutes les erreurs de type « erreur 404, 403, … »

Ce qui revient à parcourir l’ensemble des écrans de l’application. Ainsi nous sommes sur que l’utilisateur final n’aura pas d’écran non désiré (écran d’erreurs, mauvais écran,…)

Tests fonctionnels
Les tests fonctionnels regroupent

• Tous les points fonctionnels décris par la maitrise d’ouvrage
• Valider le comportement  correct de chaque point

Conclusion
Ce qui revient à valider l’ensemble des comportements et le résultat obtenu.
Cette stratégie possède un avantage certain, les tests de base peuvent être intégrés dans le Build, car nous considérons que l’apparition d’un écran d’erreur ou d’un écran non désiré est inacceptable pour le client/utilisateur final.
Alors il restera ensuite que les tests fonctionnels à passer.

Pratiques 

1. Faire un découpage au maximum des actions. Ainsi les méthodes générées sont réutilisable par la suite.
2. Construire une base de données pour les jeux de test
3. Exiger de la part des développeurs des Identifiant Unique à chaque élément cliquable de l’application
1. Si l’application change de forme -> Pas de codage à refaire
2. On est sûr de tester le bon élément
3. Déclarer comme Bug, tout élément cliquable sans identifiant
4. RIEN NE DOIT LAISSER INDIFFÉRENT ! Une faute d’orthographe, un mauvais alignement ou un comportement erratique…
5. Avant de commencer les phases de tests il est préférable d’installer Visual Studio 2010 feature pack 2, ce qui permettra d’apporter plus d’options pour les phases de test.
1. Ce pack permettra de pouvoir modifier avec facilité les noms des méthodes déjà enregistré.
2. De pouvoir les supprimer
3. De pouvoir déplacer les méthodes vers le fichier Uimap.cs afin de pouvoir coder à l’intérieur de ses méthodes, car dans certains le codage et obligatoire lorsque l’on veut effectuer certains cas de test.

Us et coutumes
Le piège est donc de rester enfermé dans ses habitudes d’internautes et de se contenter du rendu d’un seul navigateur. Avec 2 moniteurs différents il est possible d’ouvrir sur chacun une session avec un navigateur différent, et de tester alternativement sur l’un puis sur l’autre ce qui permet en plus de rester bien mieux conscient de ce que l’on fait

Découverte d’un BUG
Le piège est de ne pas anticiper sur la correction d’un bug même mineur et de ne pas être assez explicite sur ce que j’attendais dans la correction.

Exemple : on repère un indicateur oublié et on le signale. Se contenter de signaler une erreur sans donner une ébauche de solution ou de comportement complet attendu n’est pas suffisant, car la correction du BUG peut très bien (fréquent) ne pas répondre à 100% à ce qu’on désire, ainsi cela induit une perte de temps

Spécifications
Le piège est de traiter à la légère les éventuelles spécifications de développement. S’il est écrit que tel ou tel chose doit être faite, même en dépit du bon sens, il faut s’assurer ensuite que cela a été fait.
Nous ne sommes pas les utilisateurs finaux du produit, et peut-être que cette fonctionnalité inutile pour nous ne l’est pas pour l’utilisateur. Et en cas de doute, il ne faut jamais hésiter à déranger ceux qui ont la réponse : c’est pour eux que l’on travaille.

Tips
Astuce pour le calendrier javascript FullCalendar

Pour automatiser un test sur le calendrier

1. Enregistrer l’ensemble des actions nécessaires sur le JQuery dans une seule capture.
2. Copier cet enregistrement dans le fichier de classe partiel UIMap.cs
3. Modifier la méthode pour qu’elle fasse ce que vous souhaitez.
4. Appeler cette nouvelle méthode pour effectuer les actions.

Gestion des décalages d’une semaine (en positif et négatif).  

1. Mis en arguments de « ma fonction » 
1. un élément date (sous forme de string)
2. un booléen disant si j’effectue un décalage ou un retour en arrière
3. un entier indiquant le nombre de jours (valeur par défaut fixée à 7).
2. Dans les modifications  de la fonction,
1. Vérifier s’il s’agit d’un changement
2. Ensuite Vérifie qu’il n’y a pas eu de changement de mois (Important).
3. De la nouvelle date, on récupère le numéro du jour qui nous servira pour déclencher l’action correspondante.

En affinant la partie gestion de la date, il est possible d’affiner encore plus le changement de date.

Astuce pour les éléments JQuery
L’enregistrement d’actions sur des éléments JQuery peut se faire de deux manières

1. d’un seul tenant
2. action par action indépendante

Préférez la solution 2 car en choisissant d’enregistrer chaque action de manière  indépendante dans un enregistrement voici les avantages :

1. La forte ré-utilisabilité
2. Le déroulement de l’ensemble des actions concernées est plus rapide que pour l’enregistrement d’un seul tenant.

Convention de nommage
Cet aspect représente un point central pour le bon déroulement lors de la phase de création de test. Pensez avant même de commencer à votre convention de nommage, car le découpage va vite générer beaucoup de méthode
Il est préférable d’avoir un nom à rallonge qu’un nom peu explicite, il est plus aisé de comprendre « une phrase ». Car au moment de passer dans le Test Manager, lors de la création du plan, on s’y retrouve facilement.

Exemple : on a 2 pages web : Accueil et Login.

Nous avons codé l’action « transition » entre la page « Accueil » et « Login ». Cette méthode (généré par Visual Studio) est nommée : TransitionPageAccueilVersPageLogin

Nous mettrons cette rubrique Tips à jour régulièrement

« On arrive bientôt ? » ou la maitrise du temps et agilité

Préambule : Ce post est la traduction d’un autre post d'Aaron Bjork Principal PM chez Microsoft.
Merci à Visual Studio Magazine et Aaron de m'avoir autorisé à traduire et publier cet article

Article original : Remaining Work is Key for Agile



Aaron Bjork nous explique pourquoi le travail restant à faire est la mesure la plus importante sur nos projets agiles.

L'été dernier, avec ma famille, sur la route des monts Cascade, dans l'État de Washington, nous avions six heures de route devant nous.
Pour ceux d'entre vous qui ont une famille, vous savez que six heures, c'est long en voiture, notamment avec des enfants âgés de 6, 7 et 9. Nous étions sur la route depuis environ 30 minutes quand ma fille de 6 ans, Lily, me pose la question, que tous les parents ne connaissent que trop bien : « on arrive bientôt ? »

Calmement, Je lui réponds  «Non, nous n’y sommes pas encore », Lily me rétorque  «Combien de temps encore ?"
Cette conversation, je suis sûr que tous les  parents l’ont eu.

Après ce voyage, j'ai réfléchi sur l'interaction avec ma fille et j’ai réalisé qu’il y avait un vrai parallèle avec le suivi des projets logiciels. Ma réponse à Lily était assez simple. Quand elle a demandée combien de route il restait, je lui ai donné ma meilleure estimation de la quantité en temps de route restant : cinq heures.

Sans surprise, elle n'était pas particulièrement heureuses de cette réponse, cinq heures, c’est un temps long quand on a 6 ans.
Dans le même temps, la réponse était satisfaisante car elle définissait correctement ce qui nous attendait. Elle peut ne pas aimer le fait que nous avons encore cinq heures de route, mais au moins elle est informée et peut anticiper le reste de l'après-midi.

A partir de là, notre conversation aurait été complètement différente si j'avais répondu par : «Nous voyageons depuis 30 minutes".

Elle m’aurait probablement regardé  d’un air curieux. Elle n'était pas particulièrement intéressée par la distance parcourue. Cela ne répond pas à sa question. Elle veut juste savoir quand nous arriverons à notre destination. Elle voulait savoir combien de temps encore elle devrait rester dans la voiture.

La réponse « 30 minutes de conduite » est de nature à souligner notre effort, mais ne lui donne aucune réel appréhension de « quand arriverons-nous ? », « en avons-nous encore pour 1 heure ? », « pour 10 heures ? »

Les équipes de développement ont ce genre de conversations lors de la discussion autour des tâches restant à faire et du travail que cela représente.

Je sais que l’estimation des temps fait partie du quotidien de des équipes de développement.

C'est même une partie importante et essentielle du processus.

L'estimation fournit un point de départ qui peut être utilisée pour commencer à avoir des indicateurs de progression. Sans l'estimation, l'équipe avance à l'aveuglette.

Toutefois, Je vois beaucoup d'équipes accorder trop d'importance estimations, tout en oubliant le point le plus important : le travail restant.
La plupart des équipes sont conditionnés à suivre trois indicateurs:

• Les estimations originales
• La somme des travaux réalisés
• La somme des travaux restant

Je crois qu'il y a une place pour chacun de ces trois points dans un projet, mais je dirais qu’un seul compte vraiment : le travail restant.

Pourquoi ? Le travail restant est le seul indicateur qui aide l'équipe à mesurer la distance qui les sépare de la ligne d’arrivée.

Les estimations

Démarrons avec le suivi des estimations. L'argument commun pour le suivi des estimations initiales, c'est qu'il permet à l'équipe au fil du temps à améliorer leur capacité à estimer.

Il est assez commun de vouloir revenir sur l’estimation des tâches et de les comparer avec le temps passé à réaliser ces tâches. Le problème avec cette approche est qu'elle met l'accent sur la précision de l'estimation, au lieu de se concentrer sur l'accomplissement de la tâche.

« Agile » nous dit que les choses vont changer en cours de développement. C'est une partie normale du processus. A cause de cela, les estimations ne devraient pas être parfaites.

Rappelez-vous: l'objectif est de terminer le projet et offrir de la valeur aux clients.

Le but n'est pas de produire des estimations parfaites. 

Je ne prétends pas rejeter les estimations ou de mal faire le travail d’estimation. Je dis plutôt qu'une fois une estimation créée, l'équipe devrait focaliser son attention sur le travail restant. L'estimation est juste le point de départ pour savoir combien de travail il reste.

Travail Terminé

La plupart des équipes réagissent mal la première fois qu'on leur demande de laisser tomber l'indicateur "travail achevé".

Ils l'ont suivi de près pendant des années et sont formatés pour y faire attention. En réalité, suivre le temps de travail terminé n’apporte rien à la réussite du projet. Qu’importe si l’équipe a terminé en 100 heures de travail, sur 150 heures nécessaires au respect de son engagement. Ce qui est important, ce sont les 50 heures restantes.

Se focaliser sur le travail accompli peut conduire à un jeu dangereux, où l'équipe commence à plus se concentrer sur ses efforts, plutôt que sur son résultat.

Encore une fois, je ne dis pas que suivre ce qui se fait n'est pas important. Les équipes doivent absolument suivre ce qu'ils ont fait et se réjouir de l'achèvement de chaque élément du Backlog.

Mais ne laissez pas ce suivi détourner l'équipe de son but.

Revenons à mon voyage en famille l'été dernier.

Finalement, il nous a fallu près de sept heures pour arriver à destination. Et quand nous sommes arrivés, nous étions tous ravis et prêts à profiter de nos vacances.
Personne ne se souciait plus que mon estimation de cinq heures était un peu sous-évaluée. Nous avions décidé, à mi trajet, de nous s'arrêter pour prendre un repas et aussi de voir quelques curiosités le long du chemin.

Après notre départ, Il y a eu des changements, et nous nous sommes adaptés à ces changements.

Nous étions arrivés, voilà ce qui était important.

Ma méthode : un exemple de "Task-Driven"

Historique

Depuis des années, j’utilise une méthode pragmatique pour la réalisation de logiciel, au sein et à destination de petites entreprises et avec des petites équipes.

Dans ces contextes, j’avais toujours plusieurs casquettes : chef de produit, chef de projet, responsable R&D, programmeur senior.

Dans la suite de ce document, je résumerai ces rôles au titre de « manager », un manager multi-casquettes, multitâches…

Sans un système léger et automoteur, il m’aurait été très difficile de m’en sortir.

Plus qu’une méthode « innovante et révolutionnaire », il s’agit plutôt d’un assemblage de bonnes pratiques et de pragmatisme. Elle a comme base principale la classique « Méthode agile » mais adapté à des « mini-équipes » très polyvalentes.

Ayant beaucoup de rôles différents, il m’a fallu faire des choix, établir des priorités.

Ce n’est pas la quantité de travail qui détermine la réussite d’un projet mais plutôt sa qualité, son organisation, l’engagement de son équipe et sa passion pour le produit.

Dans les différents rôles de management, j’ai fait l’impasse sur un certain nombre de fonctions pour n’en garder que l’essentiel.

·         Chef de produit : inspiré par l’agile, pas de cahier des charges à rallonge, juste des spécifications explicites courtes, les fameuses « user stories » (au final, leur addition donne un cahier des charges, mais à postériori).

·         Chef de projet : pas de planification, juste des découpages de « User stories » en tâche et des estimations de priorités dans celle-ci. Ces tâches permettent une autogestion de l’équipe de développement, dirigée par les tâches et leurs priorités, mais d’ordre imposé.

Tasks-Driven & Task-Centric

Les tâches

Ma méthode est basée sur les tâches et sur l’autonomie de l’équipe et de ses membres.

Le point principal est la possibilité, ou plutôt l’obligation des développeurs de choisir eux-mêmes les tâches qu’ils souhaitent réaliser, selon leurs inspirations, leurs compétences, leurs humeurs ou leurs ambitions.

Le libre choix des tâches donne une grande autonomie aux membres de l’équipe et leur permet de moduler leurs efforts et aspirations dans un but d’obtenir une plus grande productivité.

Lorsqu’un développeur choisi lui-même sa tâche, il va le faire selon certains critères principaux:

·         Son intérêt pour le sujet de la tâche :

« Tiens cette tâche à l’air intéressante, c’est vraiment dans mes cordes »

Exemple + : bonne expertise sur le sujet => bonne productivité et satisfaction

Exemple - : Challenge qui peut rater => mauvaise productivité et perte de confiance

·         Son état de fatigue et/ou de motivation :

« Je suis crevé cette semaine, je vais me faire toutes les corrections d’orthographe et d’alignement »

Exemple + : choix de tâches courtes et rapide => maintien de la productivité

Exemple - : Enfermement dans une tâche longue (défaut du concept ‘longue’) => baisse de la productivité

Dans l’optique d’atteindre le but de toute équipe de développement : Livrer un logiciel de qualité dans le délai fixé, le libre-arbitre dans l’organisation individuelle permet de conserver une bonne productivité et une bonne motivation quelque que soit l’état d’esprit et de fatigue du développeur.

Dans ce contexte, le manager peut (je dirais même : doit) lui-même réaliser des tâches, son  score est affecté à l’équipe.

Le manager joue un rôle de support auprès de son équipe.

Planification

Elle n’existe pas en tant que tel. Seuls quelques jalons peuvent être posés.

Comme j’utilise les grands principes de la méthode Agile, mes jalons sont les dates de fin de sprint et de fin de release.

Je ne connais pas de projet qui respecte son délai parce qu’il a été planifié, mais parce que son équipe s’est mobilisé sur un objectif clair et collectif : le délai.

La planification détaillée de toutes les tâches est souvent une façon pour tous les acteurs autour du projet de se rassurer.

Pour reprendre une citation de Rework : « Planifier, c’est deviner ».

Philippe Limantour, en lisant ce document m’a fait les remarques suivantes :

« Sur des projets de développement plus lourds je ne partage pas trop l’avis tranché sur le fait qu’un projet planifié ne tient pas ses délais.

La clef selon moi – expérimentée sur des projets de développement avec des équipes de plusieurs dizaines de développeurs, et des roadmaps de 6 mois avec un maximum de 5 jours de retard – réside dans le travail de préparation. Une très bonne analyse marketing détaillée dans un livrable de: ‘que veut le client’, ‘comment le fait-on technologiquement’, ‘quels choix in/out dans la prochaine roadmap’ est une clef du succès Ce travail est mené par une personne dédiée, en collaboration avec le chef de projet en charge de l’équipe de développement, et avec l’équipe commerciale. Une fois calé ce document, on n’en sort pas. Et un responsable qualité à temps plein a contribué à mettre en place, et à suivre, les processus qui permettent de suivre ce cadre qui a pour but de délivrer les fonctionnalités majeures attendues par les clients, en temps et en heure. »

Le rôle du manager est d’animer et motiver l’équipe pour tenir ces dates.

Mais, surtout, son rôle est de bien quantifier le nombre de tâches et leurs difficultés pour qu’elles « rentrent » dans le sprint ou release.

Le réalisme dans l’estimation du travail à fournir est l’un des point-clefs du métier de manager d’équipe de développement.

« Je pense savoir ce que je vais faire cette semaine, mais quels impondérables vont me tomber dessus et changer tout mon beau planning ? »

Je préfère largement parler d’objectif, et de dates d’objectif.

Le but : petits rappels

Le but de toute équipe de développement est de:

Livrer un logiciel de qualité dans le délai fixé

Seule l’obtention du but, de l’objectif compte, et pour cela, seule la motivation, la mobilisation autour du but compte.

Même si, le choix, l’autonomie et le libre-arbitre sont les bases de cette méthode, le manager doit pouvoir assigner et imposer ses choix et décisions aux membres de l’équipe dans l’intérêt du projet et, surtout, dans l’objectif d’atteindre le but.

Comment atteint-on le but : en terminant et en testant toutes les tâches. Tout tourne autour des tâches.

Malgré une forme d’autogestion des développeurs, le manager reste le manager, il est le garant du résultat final.

Nouvelle notion : le score

Pourquoi un score

Mon idée est que la motivation des membres de l’équipe peut être animée et aiguillonnée par le score qu’ils réalisent sur une période donnée (semaine, mois, release, sprint, etc… selon l’organisation choisie).

« Ma méthode » a ses limites, notamment dû au manque de mesure et d’évaluation des membres de l’équipe. Et sans indicateur, il n’y a pas d’axes d’amélioration, pas de détection proactive des dysfonctionnements.

Cerise sur le gâteau, l’idée de score induit un petit esprit de compétition que peut émuler une équipe, la faire progresser et être, par exemple, le support à de mini évènements.

Utilisation du score

Par l’équipe

Un score minimum moyen (SMM) par membre de l’équipe est fixé. Il faut également fixer un score minimum pour l’équipe afin de créer un esprit d’équipe.

L’idéal est de fixer une récompense pour SMM atteint, individuels et collectifs, récompensant en cela l’effort individuel et les efforts collectifs. Cette différence « individuel/collectif » est importante, un membre qui fournit de gros efforts et obtient un bon score n’a pas à être pénalisé par le piètre résultat de l’équipe.

A l’inverse, si globalement, l’équipe a été bonne, tout le monde doit être récompensé afin que personne ne se sente exclu, même s’il n’a pas vraiment  participé à l’effort collectif.

A chaque fin de période, une analyse du plus mauvais score doit être faite, dans un esprit positif, afin d’aider le membre de l’équipe qui l’a obtenu. Pourquoi ne pas utiliser la technique des 5 pourquoi pour faire cette analyse ?

Il est nécessaire d’écarter des « mauvais scores », les scores bas obtenus à cause d’éléments extérieurs ou personnels  (ex : absence pour maladie = mauvais score, mais l’équipe n’y peut pas grand-chose).

Pour le manager

Il aide à l’estimation simple des tâches.

Le score est très comparable à la vélocité (basée sur les points des user-stories), et permet donc son utilisation pour la planification des sprints et des releases.

Définition d’un score

Le score d’une tâche est le résultat d’un calcul basé sur des critères prédéfinis. Il sert à indiquer aux développeurs le nombre de points qu’il va gagner en réalisant cette tâche.

Pour rester simple, il n’y a que trois critères avec trois valeurs qui déterminent le score de la tâche.

L’expertise :

Facile= 1, Normal=3, Expert=5

La longueur de la tâche :

Courte=1, Normal=3, Longue=5

La priorité :

Non-urgent=1, Normal=3, Urgent=5

Subjectivité de l’évaluation.

Elle est réelle, mais elle est limitée par le faible nombre de choix et la transparence des choix. Les choix doivent être discutables par n’importe quel membre de l’équipe en cas de désaccord, et à n’importe quel moment du process, même quand il est fini. L’important est que ce désaccord soit motivé.

Dans de rares cas, à l’instar du « planning poker », le « scoring » peut-être collectif, en reprenant la même méthode que le « planning poker », mais cette méthode doit rester l’exception.

Le futur en conclusion

Les outils utilisables

Ils n’existent pas encore d’outil utilisable tel quel pour la gestion basée sur les scores. Pour le task-driven, beaucoup d’outils sont utilisables, je ne vais citer que ceux que j’ai utilisés ou évalués.

Team Foundation Server, Mantis, Jira et le très prometteur Asana

Le choix de TFS

Je trouve que l’intégration TFS/Visual Studio qui fait de l’ensemble une plateforme redoutable de productivité et d’efficacité.

Ce que j’aime également dans TFS, c’est l’idée de pouvoir lié le code aux « Workitems » et notamment les archivages (check-out), c’est ce qui me manque dans Mantis, une ou des références sur des bouts de code pour mieux expliquer des spécificités/tâches techniques.

TFS est un très bon contrôleur de source mais la gestion des « Workitems » n’est trop adaptée à une gestion Task-driven et ne gère pas les scores, c’est pourquoi je travaille sur une interface web et un « process template » qui va bien coller avec ma méthode de travail.

D’où le projet ScrumPilot.

ScrumPilot

L’idée initiale de ScrumPilot était un simple tableau de bord plus vivant et plus visuel que celui qui est offert.

De fil en aiguille, j’en suis venu à lui ajouter des fonctions de lecture de « workitems », projets, utilisateurs.

Et de me dire, qu’avec tout cela, ma meilleure connaissance de la facétieuse API de TFS et un peu d’huile de coude, je devrais pouvoir faire un mix entre Mantis/Asana, TFS, ma méthode et mes scores, pour donner un vernis « petite équipes agiles centrées sur les tâches »

Il fera l’objet d’un autre article plus détaillé quand je l’aurais peaufiné.