Release Management : bonnes pratiques

Introduction

Bonjour à toi qui lis ces lignes,

J’ai vécu plusieurs expériences de Release Manager (RM) dans des très grandes équipes (300 personnes) et dans des plus petites (2-3 personnes).
Cet article est là pour synthétiser toutes mes connaissances à ce sujet et c’est un sujet intéressant à plusieurs niveaux : sur le plan humain, organisationnel, des processus, de la communication, de la qualité et du DevOps.

Je vais vous partager ce retour d’expérience en répondant à ces questions :

1. Glossaire sur les tests
2. Qu’est-ce qu’un Release Manager ?
3. A-t-on systématiquement besoin d’un poste de Release Manager ?
4. Quelles sont les qualités d’un bon Release Manager ?
5. Comment s’interface-t-il avec les différentes composantes d’une équipe ?
6. Pourquoi un rôle dédié de Release Manager ?

Glossaire

Dans les DevOps, il y a des tests, donc autant poser le glossaire tout de suite.
Les différents tests dont je parlerai sont : Unitaires, Non-régression, Manuel, Sanity Checks, Test Post-Release.

Unitaires :

Tests qui peuvent et doivent tourner en automatique et qui sont rapides ( <10 ms). Ils peuvent tourner en local ou dans un processus d’intégration continue (Jenkins, Team City, VSTS…).

Non-Régressions :

Les tests BDD, Specflow, tests de la DAO : plus lents et qui peuvent, mais devraient le moins possible solliciter la base de données. Ils tournent aussi en automatique.

Manuels :

Un humain qui manipule l’IHM et qui constate de visu le résultat des manipulations.

Robotisés :

Un processus qui manipule l’IHM et les résultats sont soit analysés par le robot, soit autrement.

Sanity Checks :

Tests qui permettent de s’assurer que la fonctionnalité principale d’un logiciel est bien opérationnelle, soit par un Humain, soit par un Robot.

Test Post-Release :

Tests exécutés par un Support de Production ou la MOA sur l’environnement de production avec des comptes dédiés, le but étant entre autres de s’assurer du fonctionnement le plus end-to-end possible.

Qu’est-ce qu’un Release Manager ?

Un rôle ponctuel ou un vrai poste :

Un Release Manager peut être :

• Un poste plein temps, quelqu’un qui est assigné à ce poste toute l’année.
• Un rôle pris tour à tour par un membre de l’équipe de développement (ce que j’ai été plusieurs fois)

C’est un état d’esprit :

Ce que j’en pense : Un développeur qui initie le processus d’une Release pour lui-même (seul développeur) ou pour le compte d’une équipe a un état d’esprit différent.
Il passe d’un état d’esprit de création, d’amélioration, de correction à un esprit de vouloir assembler, challenger, questionner sur la qualité de ce que ces collègues ou lui-même ont/a produit.
Tout comme le développeur qui code en TDD, qui passe de l’écriture du test qui passe rouge, puis l’écriture du code qui le fait passer du rouge au vert, puis qui passe la phase d’amélioration des tests et du code.

Il est responsable :

Que le rôle soit tournant ou pas, un Release Manager est responsable de la qualité, du respect de la date de la livraison de la release et de la maîtrise des coûts de la release.
Il engage la responsabilité de son équipe devant son chef, voire au-dessus. Sa responsabilité est plus élevée qu’un développeur, mais son poste l’est aussi ; il n’a pas besoin de passer par la chaîne hiérarchique classique pour organiser la release comme il la juge nécessaire. Il a donc aussi la responsabilité de devoir peut-être annuler ou reporter la release s’il considère que le risque à livrer est trop élevé. Ou bien refuser une fonctionnalité qu’il estime trop risquée à intégrer au regard de l’apport fonctionnel ou technique.

Sa prise de fonction est communiquée à tous et il sera un communiquant avec tous :

Le Release Manager est identifié plusieurs jours avant la release et son rôle est communiqué comme tel aux différents services qu’il pourrait éventuellement solliciter.

Ainsi, il y aura une seule personne qui communiquera avec les DBAs (Database Administrators), l’infrastructure, le support, l’équipe de production… pour la MEP. Cela lui fait gagner du temps pour éviter des questions basiques et a aussi une confiance plus élevée avec les différents services.
Le RM concentre ainsi les informations venant des autres services et les redescend à l’équipe.
De la même manière, il prépare et envoie la communication pour les utilisateurs et/ou métiers du contenu de la release.

Ce que l’on attend de lui :

• Être au service de son équipe pour prendre et intégrer les changements proposés
• Fournir un environnement de Test le plus proche possible de la production avec le moins de DownTime possible
• Garantir la qualité de la Release en s’assurant que les Tests ont tous été faits et sont bien verts
• Être attentif au fur et à mesure que la Release se prépare, d’accepter des Merges post-Freeze Code qui présentent un risque de plus en plus faible
• Préparer une communication adéquate pour les utilisateurs cibles des nouvelles fonctionnalités ainsi que pour l’équipe de développement
• Répéter le déploiement pour être sûr de le réussir le jour de la MEP sans erreur
• Préparer ou faire préparer les Tests Post-Release
• Livrer en production, communiquer les changements aux utilisateurs

A-t-on systématiquement besoin d’un poste de Release Manager ?

Pour une petite équipe ?

Si c’est une petite équipe, je pense qu’il n’est pas nécessaire d’avoir un poste dédié, mais d’un processus de livraison, une feuille de route pour livrer, oui.
Même dans une petite équipe (2-3 personnes), je pense que le le Release Management existe, même si le processus ne fait que 10 lignes. Et il me semble indispensable qu’il soit suivi à chaque Release et qu’il soit améliorable.
J’ai été sur un projet où nous étions deux et nous faisions tourner le Rôle pour que chacun sache faire la Release sans se tromper. Cela présentait 3 avantages :

• Le processus est déjà réfléchi, aucun risque d’oublier quelque chose.
• Il est ordonné.
• Les questions que l’on se pose à soi-même ou à l’autre ne varient pas. Cela permet aux autres développeurs de déjà préparer les réponses.

Cela permet de dérouler un processus dans lequel les choses seront faites dans un ordre convenu, où les mêmes questions seront posées à l’autre.
Le besoin d’avoir un Release Manager vraiment dédié (même en poste temporaire) se fait de plus en plus sentir parallèlement à l’augmentation de la criticité d’une livraison et/ou du coût d’une livraison. Il m’apparaît nécessaire qu’une personne, peu ou pas partie prenante dans l’opérationnel de la release, ait le recul suffisant pour une bonne organisation de l’équipe et puisse la challenger sur les changements que celle-ci propose.

Des besoins indirects qui peuvent créer le poste de RM

J’ai observé, au cours de mes expériences, que des équipes avaient des postes fixes de Release Manager.
Cela arrivait quand la Release était particulièrement difficile à déployer et quand le RM était aussi chargé de maintenir et protéger tous les types d’environnements de l’application. Il y a cependant un désavantage avec le poste fixe d’un RM : comme le rôle n’est pas tournant, les gens ne passent pas de "l’autre côté" et ne se rendent pas compte de la difficulté du travail du RM, et comprennent moins bien les demandes parfois contraignantes du RM. Le RM passe alors plus de temps à faire de la pédagogie auprès de ses équipes.

Même quand il y a déjà un processus de livraison en continu qui tourne comme une horloge ?

Oui ! Et là c’est mon côté Craftsman qui prend la parole : même si tous les tests passent, s’il y a une dette technique qui s’accumule à chaque livraison, c’est le coût du développement qui finira par s’envoler. Le Release Manager a alors son importance dans la revue de code et peut éventuellement proposer des hooks de vérification déclenchés à chaque Commit s’il voit des erreurs récurrentes dans les Commits.

Quelles sont les qualités d’un bon Release Manager ?

Il voit loin et est organisé :

Vu qu’il n’est pas occupé par les tâches opérationnelles de ses collègues, il se projette plus en avant que ses collègues pour anticiper des soucis à venir. Il prend tout le temps nécessaire pour préparer ou revoir sa checklist avant le début de la préparation de la release, répéter ou se faire expliquer des tâches qu’il devra faire à un moment précis de la release : les sanity checks, déployer…
Tout comme une checklist dans un cockpit d’avion, une fois l’avion en l’air, c’est trop tard !

Quand il s’agit de rendre verte la software factory, le RM doit anticiper et faire corriger les bugs avant la veille du jour J au vu du nombre de Tests en rouge.
Si un RM apprend qu’il y aura des reboots de machines dédiées aux tests, charge à lui de prévenir les développeurs bien en avance afin qu’ils ne perdent pas de temps à tester avec une bêta qui ne répondra plus.
À la Date de la Release, le RM doit savoir gérer son temps ainsi que celui de son équipe pour livrer à temps, dans de bonnes conditions de qualité, ou alors choisir de renoncer à livrer plutôt que de livrer une application mal testée.

Il est un challenger :

Sur la gestion des risques :

Un exemple : face à une demande de merge ou un Change souhaité par un développeur après la session de tests manuels, il va challenger le besoin d’intégrer cette nouvelle feature ou correction. En effet, le processus habituel est de refuser tout changement non présenté avant le code Freeze, de refuser encore plus fermement si cela se produit après la session de tests manuels. Il va vérifier avec le responsable de l’équipe en question quel est le risque à livrer/ne pas livrer, le périmètre d’impact technique et fonctionnel du Change, comment il compte tester son changement, etc.

Sur la qualité des Changes proposés :

Le RM reçoit tous les Changes ou commits de ses équipes. Selon la taille des équipes et le niveau de qualité du développement requis en général dans la DSI, il y a pu avoir une review par le team leader du dev juste avant, et il y aura une review rapide de l’intégrateur général dans le cas où l’équipe est très importante. Mais dans tous les cas, je trouve qu’il est nécessaire que le RM ait au minimum un droit de regard sur les Changes qu’il va intégrer, et éventuellement un refus. Cela pour éviter des commits qui essayent de passer dans la version sans que l’on sache vraiment à quoi ils servent et les impacts non maîtrisés qu’ils pourraient avoir. Rappelons que c’est le RM qui sera seul quand il déploiera en PROD, ce droit de regard m’apparaît donc tout à fait légitime.

C’est un bon communiquant :

Un bon RM étant LE nœud central de communication, il doit communiquer avec tout le monde et écouter chacun.
Ayant des informations à communiquer en permanence à son équipe, il doit faire attention à la cible de communication lorsqu’il communique, surtout par mail, pour ne pas submerger d’informations son équipe. Il s’adresse par exemple à une seule équipe responsable d’une fonctionnalité, mais communique à tous la disponibilité d’une nouvelle version Pre-bêta : la version de test. Il Implique tout le monde dans les tests des applications, mais relance uniquement l’équipe qui sait faire un certain type de tests.

C’est un adepte de l’amélioration continue :

Tout le temps passé à préparer une release représente un coût de livraison. Donc plus une livraison est rapide, moins elle coûte. Mais si elle trop rapide dans le sens où les contrôles qualité ne suivent pas, ce sont des pertes opérationnelles potentielles qui s’ensuivront.

Comme il est en contact avec beaucoup de personnes, il peut recueillir des conseils, remarques, choses à retirer ou à améliorer. Il peut ensuite améliorer ou proposer des améliorations du processus pour des raisons d’efficacité, de confort de ses collègues développeurs et baisser ainsi le coût de la release. Pour cela, il peut capitaliser son expérience qu’il partagera au futur RM sur un support facilement transmissible (Wiki, Word, Excel…). Il repère tout ce qui a pu ralentir ou compliquer la release : des tests trop longs à s’exécuter, une difficulté à atteindre les gens pour leur parler, des corrections faites trop à la va-vite ou des tests qui restent longtemps en rouge.
Le RM est légitime pour proposer par exemple les améliorations suivantes :
Est-ce que tous les tests de l’usine sont vraiment nécessaires ? => supprimer ceux qui ne sont plus nécessaires ou qui ont une redondance entre eux.
Pourquoi tant de tests utilisent la base de données ? => Reparcourir et convertir des tests qui mockeront la base de données lorsque c’est possible.
La session de tests manuels se termine toujours plus en retard à chaque Release => Convertir des tests manuels en tests robotisés ou en TNR (Test de non régression) specflow.
La liste est non exhaustive bien sûr.

Il sait motiver les gens de manière positive :

"Soft Skills on"

Un bon RM, selon moi, sait impliquer chaque personne pour réaliser le livrable attendu. Il peut le faire d’une meilleure façon s’il connait bien les gens et leurs capacités. Le moment où le coût est particulièrement élevé se situe lors de la correction des Tests Unitaires et lors de la session de tests manuels. Il s’agit alors de trouver les bons mots pour faire bouger les gens : par oral, par des mails, en leur donnant des objectifs chiffrés atteignables sur des courtes périodes, etc. L’attitude et la posture mentale sont essentielles pour motiver les gens sans qu’ils aient l’impression d’être vos subordonnés. Un bon RM sait gérer la pression et ne devrait pas la transmettre à ses collègues, qui ont besoin de garder leur concentration pour résoudre des bugs, corriger des tests… Je recommande d’utiliser la communication non-violente pour aller parler aux gens plutôt que par mail ou par chat.

Il est curieux :

Il doit s’intéresser un minimum au métier de l’application et à ce qui est vital pour son fonctionnement. Cela lui permet de distinguer un bug bloquant d’un bug mineur, et donc réagir plus ou moins vite pour faire corriger un bug en fonction de la criticté. En s’intéressant au fonctionnement macro de l’application, cela lui permettra de dégager les Sanity Checks adaptés à la version de l’application. Il pourra utiliser ces Sanity Checks pour s’assurer du bon fonctionnement de la version Pre-bêta avant que son équipe commence ou continue les tests.
Etre un RM est aussi une bonne occasion de s’intéresser à ce que fait chacun et poser des questions pour approfondir ses connaissances.

C’est un chef d’orchestre :

Avec les tâches des autres

Un Release Manager étant le chef d’orchestre de la Release, il organise, distribue, suit les tâches de chacun. Bien sûr, les développeurs ont le droit d’avoir des initiatives, mais il faut qu’ils mettent le RM au courant. Le RM peut mettre aussi la main à la pâte, mais ce n’est pas son rôle prioritaire.
J’ai rarement eu l’occasion d’avoir le temps de faire autre chose que mon rôle, tout au plus, une demi-journée cumulée sur 15 jours. Comme le RM a une vue d’ensemble sur la Release, il saura que des tests ont des valeurs métier plus élevées par rapport à d’autres releases et qu’il vaudrait mieux que ces tests en particulier soient joués en premier. C’est dans ces moments-là qu’il est important que le RM soit au courant de qui a commité quoi pour la release. Car il pourra mettre en relation l’auteur d’une fonctionnalité qui ne fonctionne plus et celui qui aura testé celle-ci, et/ou celui qui l’a modifiée.

Avec les siennes

Un bon RM est minutieux et ne doit laisser aucun test de quelque nature lui échapper.

Une bonne session de tests doit, à mon avis, jouer chaque test deux fois au moins. Pourquoi ? parce que même s’il passe vert une première fois, il y aura des corrections qui viendront ensuite, et qui n’auront peut-être rien à voir ; mais il faudra alors le rejouer une deuxième fois pour être tranquille. Voilà pourquoi il faut assurer l’organisation des tests afin qu’ils soient tous joués une première fois, et rejoués après une vague de correction. Un RM ne peut se permettre de laisser un test non joué sur le côté, car d’une part il ne connaît pas son état, et si par malheur il passe rouge, il n’aura plus assez de temps pour rejouer les autres après la correction.
Les Sanity Checks et tests Post-Release ne sont pas là pour combler ces oublis. Je vous dis ça car j’ai déjà dû faire des rollbacks à cause de ces oublis dans des équipes où le concept de RM n’existait pas. Il y a eu une perte d’image à la clé pour nos utilisateurs.

Il sollicite au besoin plus de ressources humaines ou matérielles

Un bon RM doit vite se rendre compte si une correction prend anormalement du temps ou qu’une ressource qu’il avait demandée pour l’environnement de test tarde à venir. Il pourra, le cas échéant, mobiliser plus de ressources ou solliciter la hiérarchie si par exemple un serveur est trop souvent down.
Sa connaissance globale de la release lui permettra d’avoir les bons arguments pour appuyer la nécessité que telle ressource doit être disponible pendant la session de tests.

Comment s’interface-t-il avec les différentes composantes d’une équipe ?

Les MOAs

Les MOAs sont là pour renseigner le RM sur les features qui sont attendues dans la release. Il connaît ainsi les risques à livrer/ne pas livrer et la valeur apportée par chaque fonctionnalité. Ils sont utiles pour retrouver les bonnes personnes pour des corrections de TU ou TNR qui passent en rouge, ainsi que pour tester.

Les Chefs d’équipe :

Ils servent en général peu pendant la Release. Ils peuvent apporter un soutien au RM quand trop de temps est pris pour corriger un TNR.
Lors de certains processus de livraison, un chef doit donner un GO dans une DSI pour que le RM ait, de manière sûre, le feu vert pour la livraison. Il est alors indispensable d’avoir les numéros de fixe/portable de toute la chaîne hiérarchique bien avant la livraison, pour être sûr d’obtenir le GO. Anecdote : mon N+3 avait juste son téléphone personnel sur lui alors qu’il devait donner un GO sur un site web sécurisé. Il m’a alors envoyé un GO par SMS, avec l’autorisation de mettre en PROD en mon nom. Surprenant, mais le process l’autorise.

Les Référents techniques d’équipe ou Team Leaders :

Ces postes n’existent pas toujours ; le plus ancien de l’équipe peut aussi faire l’affaire. Il s’agit de connaître via ces personnes (Team Leader, Référents Techniques) les compétences de chacun, ce qui est appréciable au moment de faire faire des corrections, ou même pour les informer de corrections qui auraient pu avoir un impact sur leurs développements. À la fin d’une session de tests manuels, je recommande de planifier une réunion avec eux pour m’assurer que chaque bug mineur est bien assigné, et qu’il sera corrigé à la prochaine version.

Les Responsables Infrastructures :

Voici un exemple de check-list que je recommande de parcourir à chacune des releases pour savoir s’il y a des ajouts/suppressions/modifications des élements suivants :

• Les Machines/VM nécessaires ?
• Les Web Services/Web App/Web Api
• Des ouvertures/fermetures de port ?
• Les Jobs/tâches planifiées
• Les logs

Suite à cela, le RM va pouvoir demander des ressources aux responsables infrastructures pour construire son environnement de test, checker les Web services extérieurs nécessaires s’ils existent, etc.
Il est également important de lister les ressources sur lesquelles on peut avoir la main (pour un redémarrage éventuel) et sur lesquelles on ne peut hélas rien.

Les DBAs :

Comme pour l’équipe Infrastructure, le RM va d’abord demander aux équipes les bases dont ils ont besoin, puis informer les DBAs pour voir ce qu’ils ont de disponible. En temps normal, ce sont souvent les mêmes bases qui reviennent, mais cela peut changer selon les releases. Le RM est là pour tenir informés les gens afin qu’ils puissent éventuellement jouer des scripts d’altération de données, afin de préparer l’environnement. Là encore, le RM qui a bien suivi les changements de ses collègues sait faire le lien entre les scripts et les features annoncées par les MOAs.

Pourquoi un rôle dédié de Release Manager ?

Le RM est un rôle non-développeur, et cela représente un coût certain dans équipe, qu’il soit dans un rôle temporaire ou permanent.

Il est détaché de son travail habituel :

Durant toute la préparation de la Release, il n’est focalisé que sur son objectif : la Release ; au contraire de ses collègues qui alterneront entre la préparation de la release et leur travail de développement habituel. Lorsque j’étais RM temporaire dans une grande banque française sur l’Asset Equity, je ne faisais plus du tout de développement. J’étais détaché des DSM, des réunions habituelles, des points équipes, aucun de mes chefs N+1 ou N+2 ne me demandait de comptes sur mes développements courants.

Il a une vue globale sur la Release :

Le RM s’extrait donc de ses tâches quotidiennes, de ses responsabilités de développeur, afin de prendre de la hauteur et d’avoir une vue globale sur une Release qui s’annonce. Chaque développeur va lui proposer ses commits en ayant souvent la vue réduite sur ce qu’il voudrait voir livré. Le Release Manager lui, voit la Release dans son ensemble et verra peut-être d’ailleurs des liens entre des commits qui constituent une seule et unique feature.
Le RM garde une cohérence si le développement est réparti sur plusieurs commits.
Par exemple, que faire d’une partie graphique si sur la DAL ou la couche business, le travail n’est pas fini ?

Il assurera la communication :

Interne

Un Release Manager est LE seul et unique point de passage de communication, tout passe par lui et tout part de lui pour la préparation de la Release.
Comme il planifie la Release, il communique le planning de celle-ci à son équipe avec des jalons à respecter, des niveaux de qualité à atteindre sur chacun des jalons, des pourcentages de tests réussis à tel jour, tel jour… Bref, il annonce les "Règles du jeu" bien en avance, afin que personne ne soit pris au dépourvu.
Si un développeur remarque qu’une procédure stockée n’a pas été déployée en environnement de Bêta, il la communique au RM qui transmettra à tous l’incident, et trouvera quelqu’un qui résoudra le problème, suivra la résolution et tiendra au courant les gens impactés.
Toutes les personnes autres que les développeurs savent également qui est le RM. Ils lui font immédiatement confiance pour mener des actions car ils savent qu’il est au courant de tout et qu’il agit dans le cadre d’un processus éprouvé.
Il y a ainsi un temps gagné à transmettre l’information, à prendre des décisions et lancer des actions.

Externe

Le RM s’occupe également de la communication à l’extérieur de la DSI, pour les utilisateurs.
Étant donné qu’il a lui-même intégré les changements, il peut facilement parler des nouveautés de la version. Il constituera ainsi la release note et l’enverra aux utilisateurs, et la MOA l’aidera pour cibler les utilisateurs si besoin. Dans certains processus, c’est aux MOAs de faire les tests post-release sur la PROD. Le RM pourra s’assurer de leur disponibilité à la date et heure de la MEP afin de garantir les tests post-release, et pourra leur demander de vérifier particulièrement certaines fonctionnalités.

Il créé, maintient, met à jour l’environnement de test :

Il sait quels sont les besoins de son équipe, a priori sait également déployer en Pre-Bêta. Il peut préparer l’environnement de test pour son équipe, la configurer correctement, la tester sommairement grâce aux Sanity-Checks.
Ses petits camarades vont pouvoir se concentrer sur autre chose pendant ce temps. Si les développeurs ont des demandes sur l’environnement, comme redémarrer des services, nettoyer des tables ou basculer ponctuellement sur une autre ressource, le RM apprécie alors le périmètre d’impact et l’urgence de la demande :

• fait suite à la demande si le périmètre est assez restreint.
• demande au reste de l’équipe si le périmètre est trop large.
• accepte de le faire de manière programmée en avertissant les testeurs impactés.

Le RM intègre les corrections de tests sur la version de Pre-bêta et décide de la mettre à jour pour voir les tests être corrigés. Pendant tout le temps du déploiement, son équipe ne pourra pas tester. À lui de choisir judicieusement le nombre de releases par jour afin de limiter le Down-Time.

C’est un serviteur impartial et droit dans ses bottes :

Le Release Manager peut être vu sous un autre angle : il se met au service, de manière impartiale, de son équipe pour assurer la Release. Les développeurs vont lui demander d’intégrer des fonctionnalités et ce sera lui qui s’occupera de leur bonne intégration dans le livrable. De même, il sera exigeant envers l’équipe dans les tests qu’elle fera sur les fonctionnalités demandées. L’aspect désintéressé a son importance : si la personne qui se porte volontaire comme RM a une fonctionnalité très engageante dans sa propre Release, il aura plus de travail pour faire tester ou tester lui-même la fonctionnalité.
La conséquence est qu’il passera moins de temps sur son rôle et des doutes subsisteront sur son impartialité vis-à-vis de sa fonctionnalité.

Si un Développeur ne suit pas le process, le réflexe à avoir est : "you shall not pass" de Gandalf. Les règles ayant été énoncées clairement et à l’avance, personne n’a été pris en traître.
Il faut une certaine force de conviction pour tenir ce poste, j’en conviens. Il y a des développeurs qui ont la pression pour livrer leur fonctionnalité, mais quand ils présentent un Commit qui n’est pas vérifié ou qui ne builde pas (bon, là ce serait jenkins qui bloquerait) ou bien qui est visiblement codé à l’emporte-pièce, selon les règles édictées (et selon moi aussi), ce n’est pas admissible.

Il garantira la bonne organisation, exécution et correction des tests :

Cette responsabilité a du sens à être confiée à un rôle tournant, s’il y a un référentiel de test transmissible et fiable d’une release à l’autre. Ce sont aux développeurs d’imaginer, créer, sauvegarder les tests pour que chaque RM puisse suivre leurs états lors de la préparation de la Release.
Si l’usine de tests se met subitement à passer tous les tests en rouge, c’est à lui de regarder et de comprendre pourquoi. S’il juge que l’usine de tests est trop rouge, il pourra décider d’avancer la correction des tests de l’usine. Ou pareillement, s’il voit que davantage tests manuels sont prévus, il faudra qu’il en tienne compte lors de sa planification.
Le bon sens voudrait que l’on teste de la plus petite unité de fonctionnement, vers la plus grande, donc les Tests Unitaires, puis les TNR et enfin, les Tests Manuels.

Conclusion :

Je conseille à tout le monde d’essayer au moins une fois le rôle de RM si celui-ci est tournant.
Etre un RM vous pousse dans vos retranchements sur l’organisation personnelle, l’organisation des tâches, l’anticipation, la méticulosité, et sur votre connaissance de l’usine de tests logicielle en place.
Cela vous permettera également de proposer des améliorations sur le process pour les prochaines releases.
Si vous avez des questions ou remarques, n’hésitez pas à poster un commentaire, je suis à votre disposition.

© SOAT
Toute reproduction interdite sans autorisation de l’auteur.