Épuisement dans les tests logiciels : 6 causes et comment y remédier
Est-il possible d’imaginer une situation dans une équipe de développement logiciel dans laquelle un testeur est très susceptible de faire un burn-out ?
Si oui, que peuvent apprendre les testeurs de cette expérience de pensée ?
En réalité, le burn-out chez les professionnels des tests logiciels n’est pas qu’une expérience de pensée dans l’industrie des tests logiciels — il s’agit d’un problème réel et répandu qui touche de nombreux développeurs, ingénieurs et testeurs.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Je me suis penché sur la question du burn-out dans les tests logiciels, en posant les questions suivantes :
- À quoi ressemble le burn-out dans cette industrie ?
- Quelle est l’ampleur du problème ?
- Qu’est-ce qui crée des systèmes où les testeurs logiciels s’épuisent ?
- Comment pouvons-nous analyser le problème du burn-out — et y remédier ?
Les réponses — ou du moins un début de réponse — sont ici dans cet article.
Le burn-out chez les professionnels du test logiciel en informatique
Le stress lié au lieu de travail est une réalité à laquelle beaucoup d’entre nous dans l’industrie informatique sont confrontés. Je suis sûr que vous aussi connaissez votre dose de stress. En ce qui me concerne, malheureusement, le burn-out est devenu un sujet de plus en plus important ces dernières années.
Le burn-out est-il un problème ?
Quand j’ai demandé à Jonathon Wright, « À quel point pensez-vous que le burn-out est un problème chez les professionnels du QA ? », voici ce qu’il a répondu :
« C’est un problème immense. Des mots fameux : il est impossible de sprinter en continu. »
Jonathon Wright, animateur du podcast The QA Lead
Il a poursuivi en expliquant :
« Des méthodologies comme Agile et DevOps encouragent l’idée de tout faire toujours plus vite. Comment un professionnel du QA peut-il apporter une valeur mesurable dans une approche où l’on échoue vite et apprend rapidement ?
Dans un podcast récent sur QALead, l’expression ‘ralentir pour accélérer’ a été évoquée. À moins que les entreprises ne célèbrent l’échec (ce qui est très rare), chaque échec ne contribue pas à la vélocité de l’équipe.
L’indice est dans le titre du graphique surutilisé Burndown chart. La ludification de l’engagement sur un nombre de points de story crée une compétition malsaine.
"On vous demande sans cesse d’en faire plus avec moins, en devant travailler selon l’attente irréaliste que le travail puisse être livré en sprints de deux semaines."
Jonathon Wright, animateur du podcast The QA Lead
À quoi ressemble le burn-out dans le QA ?
Le burn-out n’est pas un cas isolé dans l’industrie du logiciel — mais à quoi ressemble-t-il ?
Voici quelques témoignages de professionnels du test logiciel illustrant les différentes formes que peut prendre le burn-out dans le QA.
« Nous devons prouver notre valeur. Les équipes me disent qu’elles sont agiles, qu’elles n’ont pas besoin de testeurs. »
« L’anxiété. Il est difficile pour les professionnels QA de ne pas angoisser avant une grosse mise en production ou de ne pas se sentir responsable des résultats. »
« La pression temporelle. Les testeurs sont toujours les derniers. Je n’ai jamais le temps dont j’ai besoin. Et il est divisé par deux, car les développeurs dépassent toujours les délais. »
« Des attentes irréalistes. Je pourrais tester indéfiniment et ne jamais tout couvrir. Essayez d’expliquer ça à un chef de projet. À quoi sert un testeur qui ne trouve pas les bugs ?! »
« Trouver quoi tester à partir des items du backlog est presque impossible. Et personne ne parle jamais des cas limites. »
« Le gaspillage est frustrant. Les développeurs n’arrivent pas à reproduire un bug, ou la tâche du backlog est obsolète, ou alors elle est déjà corrigée. »
« Beaucoup ne veulent pas d’un rapport honnête, et surtout pas de mauvaises nouvelles. Quand vous insistez, cela peut devenir personnel. »
Pourquoi le burn-out survient-il ?
La littérature énumère de nombreux facteurs qui provoquent du stress et augmentent la probabilité de burn-out. Certains facteurs sont individuels, par exemple, des moteurs personnels comme « sois parfait », « dépêche-toi », « donne-toi à fond », « sois fort » ou « fais plaisir aux autres ». Consultez l’analyse transactionnelle pour en savoir plus.
Et il y a des facteurs de stress propres à l’environnement de travail. Charge de travail élevée, pression temporelle, objectifs et attentes inatteignables, manque de contrôle, conflits exacerbés, peur de perdre son emploi, insatisfaction professionnelle, harcèlement, mobbing, etc. Nous les connaissons bien.
Il y a quelque temps, j'ai commencé à examiner le burnout d’un point de vue systémique et j'ai créé un jeu de simulation où les joueurs peuvent influencer le destin d'une équipe de développement logiciel. Ils peuvent épuiser les membres de l'équipe ou créer le projet le plus gratifiant qui soit.
Le cœur de la simulation est un système d’épuisement professionnel, c’est-à-dire un système conçu de telle sorte que certains membres de l’équipe finiront inévitablement par s’épuiser. Vous pouvez découvrir un aperçu du jeu sur mon blog.
Cet angle systémique fonctionne également pour différents rôles au sein d’une équipe. J'ai appliqué cette méthode pour les professionnels de l'expérience utilisateur et j’ai été surpris de voir à quel point il est facile de pousser ces personnes au cœur d’un système de burnout. Surtout lorsqu'ils se soucient des utilisateurs, ils sont prêts à mener un combat supplémentaire et à risquer de sombrer.
Ci-dessous, je vais plonger dans l’histoire d’Alan, un professionnel du QA, pour mieux comprendre et illustrer le problème de l’épuisement professionnel dans l’industrie du logiciel.
Puis, je parlerai de la manière dont les systèmes de burnout se créent, et de ce que l’on peut faire pour améliorer ces systèmes.
Une histoire personnelle sur le burnout
Puisque je suis convaincu de pouvoir créer un système de burnout pour les professionnels du QA, laissez-moi vous présenter Alan et son histoire.
Alan a près d'une décennie d'expérience dans le test logiciel, notamment dans les tests de performance. Il est sur le point de rejoindre une équipe de développement. L’équipe travaille depuis dix sprints et il en reste quatre avant la première livraison.
Comment s’est passée la première journée d’Alan sur le projet ?
Alan : Il y a beaucoup à faire pour moi. Le logiciel est de mauvaise qualité. Je m’attends à beaucoup de bugs non détectés et je crains des problèmes si je ne les trouve pas avant la livraison.
Markus : Identifier les bugs est donc ta priorité principale pour améliorer la qualité ?
Alan : C’est une partie du travail. Nous attendons aussi de nombreux utilisateurs. Les performances du logiciel seront primordiales une fois que nous le déploierons au grand public. L’équipe compte sur mon expertise à ce sujet.
Pour l’instant, Alan est assez optimiste quant aux mesures convenues avec l’équipe pour améliorer la qualité du logiciel. Hélas, un sprint plus tard, à trois sprints de la fin, Alan n’a plus l’air aussi enthousiaste.
Quel est le problème ?
Alan : Ces deux semaines ont été intenses. Je ne suis pas satisfait de mes progrès. Je voulais réaliser un premier test de performance simple, mais j’en suis bien loin.
Markus : Qu’est-ce qui te bloque ?
Alan : J’ai besoin du soutien des développeurs, mais ils sont surchargés. J’ai aussi mis beaucoup plus de temps que prévu à prendre en main le logiciel et à signaler les bugs que j’ai trouvés.
Markus : As-tu pu tester les nouvelles stories livrées par l’équipe ?
Alan : Pas vraiment, l’équipe était occupée à les peaufiner. Sur les deux jours réservés aux tests à la fin du sprint, il ne restait qu’une demi-journée. Je suis resté plus longtemps et j’ai travaillé samedi, mais je suis loin d’avoir terminé.
Lors de la rétrospective du sprint douze, alors qu’il ne reste que deux sprints, les tests deviennent le sujet principal : Le product owner se plaint du nombre de bugs trouvés par Alan.
Développeur : La plupart des bugs trouvés par Alan sont insignifiants ou n’en sont pas vraiment. Passons-les en revue avant de tirer des conclusions.
Alan : Eh bien, il m’a été difficile de comprendre ce que le logiciel était censé faire à partir des éléments du backlog. Une spécification m’aiderait vraiment.
Développeur : Plutôt mourir ! Nous ne voulons pas de Waterfall. C’est surtout du bon sens. Tu n’as qu’à venir demander. Où en es-tu avec les tests de performance ?
Alan : Je suis bloqué. Je n’arrive pas à faire tourner l’outil sur la couche de service avec toute cette sécurité. J’ai besoin d’aide.
Développeur : Nous avons utilisé un autre outil lors du dernier projet. Il a parfaitement fonctionné. Je t’envoie le lien.
En conséquence, le PO organise une réunion express de deux heures lors du sprint suivant. L’objectif est de passer en revue les bugs et de discuter de ce qu’il faut documenter dans les éléments du backlog pour faciliter l’arrivée d’Alan. Ressentez-vous la frustration d’Alan qui monte ?
La place fatidique d’Alan en tant que bouc émissaire devient plus évidente après le sprint treize, à un sprint de la fin. Voici les décisions issues de cette rétrospective :
- De nombreux bugs trouvés dans des stories qu’Alan aurait dû tester au sprint précédent. Plus aucune story ne sera clôturée sans qu’Alan ne l’ait testée.
- Toujours pas de test de performance. Nous faisons intervenir un expert. Alan doit le briefer.
- Impossible de terminer deux stories. Nous avons perdu deux jours à éliminer des rapports de bugs inutiles. Alan doit indiquer la pertinence de chaque bug. En cas de doute, demander au product owner.
L’avez-vous remarqué ? L’équipe n’a pas terminé deux user stories et a réussi à mettre la faute sur Alan !
Imaginez le sprint suivant, lorsque les user stories ne sont pas clôturées parce qu’Alan n’a pas eu le temps de les tester ! Pas étonnant qu’Alan ait l’air épuisé.
Alan : Plus que deux semaines avant la livraison et la qualité est un cauchemar. Dites-le au Product Owner ! Et en plus ils ont retiré les tests de performance. C’était la raison principale pour laquelle j’ai rejoint le projet. Mon chef est mécontent. Il voulait que je montre l’exemple sur l’intégration des testeurs dans les équipes agiles. Je vais quand même devoir me battre pour cela, ma réputation dans l’entreprise est en jeu.
Quatre semaines plus tard, deux semaines après la première livraison à un public restreint, le système d’épuisement professionnel est pleinement opérationnel.
Le bilan d’Alan à ce jour :
- Tests de performance : échec
- Être reconnu comme expert en tests de performance : échec
- Tester minutieusement les nouvelles fonctionnalités : échec
- Re-tester avec soin les fonctionnalités déjà créées : échec
- Inclure les testeurs dans les équipes agiles : échec
- Livrer sans bugs critiques : échec
- Être recommandé : échec
- Travailler dur et être tenu pour responsable : réussi
- Peur de perdre son emploi : réussi
- Burn-out : s’en approche à toute vitesse
Voici un exemple classique d’un système de burn-out. Alors, qu’est-ce qui crée ce système, et comment peut-on s’en protéger ?
Qu’est-ce qui crée un système de burn-out ?
Pour Alan, on peut dire que c’était perdu d’avance. Et ce n’est pas faux. Alan se trouve dans un système de burn-out en place dans l’équipe depuis un moment. Ce système le repère comme un prédateur repère sa proie. Mais au fond, en quoi consiste un système de burn-out et comment opère-t-il ?
Un système de burn-out est une combinaison de personnes, de moteurs et de conflits. Par un cycle auto-renforçateur, il crée une situation saturée de facteurs de stress, allant jusqu’à ce que certaines personnes s’épuisent. Il est d’autant plus puissant lorsqu’il est capable d’activer la logique de survie des individus.
1. L’énergie suit les moteurs
Dans l’histoire d’Alan, on peut repérer certains moteurs :
- L’ambition et la fascination pour le sujet des tests de performance poussent Alan à vouloir s’en charger.
- L’anxiété liée à la peur d’être tenu responsable d’une livraison ratée conduit Alan à traquer les bugs.
- Quelque chose pousse les membres de l’équipe à développer de nouvelles fonctionnalités avant tout le reste.
Les moteurs modifient le cours de l’action. Il devient très difficile pour les gens de réfléchir clairement sur ce qu’il faut accomplir et comment y parvenir. L’énergie investie par les personnes suit le moteur dominant, pas là où on en aurait le plus besoin. L’équipe d’Alan ne se demande jamais s’il est pertinent de développer toutes les fonctionnalités. Alan, lui, ne s’interroge pas non plus sur la pertinence de partir à la chasse aux bugs.
La difficulté principale, pour la plupart d’entre nous, c’est de prendre conscience qu’un moteur a pris le contrôle de notre comportement. Heureusement, les psychologues les ont étudiés. Pour les moteurs personnels, commencez par l’analyse transactionnelle. Pour le niveau équipe, l’effet de groupe (« groupthink ») est une bonne piste. Vous y trouverez de nombreux conseils.
Concernant l’anxiété avant une livraison, un professionnel QA expérimenté recommandait : « Il faut juste lâcher prise et rester cool ». Avec cet état d’esprit dès le début, Alan aurait sans doute poursuivi un objectif différent de la chasse aux bugs et de la mise en place des tests de performance. Les priorités auraient pu être que l’équipe corrige les bugs critiques et livre une qualité globale supérieure. Une façon de réduire le stress lié aux tâches répétitives est d’utiliser des outils de test logiciel de premier ordre.
2. Les conflits s’enflamment et deviennent personnels
En plus des moteurs, les conflits s’intensifient au sein de l’équipe. Par exemple, Alan a besoin de plus de temps chez les développeurs que ceux-ci ne sont prêts à lui accorder. Résultat : Alan fait beaucoup de bruit et les développeurs essaient de le tenir à l’écart. Sans aide, Alan n’arrive pas à satisfaire aux attentes. Il craint pour sa réputation, redouble d’efforts, et produit encore plus de bruit.
Le pire, c’est que les conflits deviennent personnels. Après dix années comme testeur, Alan est probablement un vrai expert. Pourtant, l’équipe le considère comme un poids mort et se comporte en conséquence. Plus cela dure, plus c’est ancré. Cela finit même par impacter Alan : il commence à douter de ses propres compétences.
Combien de fois avez-vous accusé quelqu’un ? Combien de personnes autour de vous semblent mal faire leur travail ? À chaque fois que vous avez une telle pensée, c’est un signe que le conflit est devenu personnel.
La plupart des équipes sont incapables de résoudre les conflits. Cela ne va pas de soi. Le mot-clé à chercher est gestion de conflit. Le message de base : les équipes doivent instaurer une culture où les idées peuvent être échangées librement, où les points de vue divergents sont accueillis comme des occasions de créer du nouveau et où s’entraider est valorisé. Ce n’est pas facile, surtout si l’on compare avec la culture de la vitesse qu’un interviewé décrivait : « À moins que les entreprises ne célèbrent l’échec, à chaque fois que vous échouez, vous n’aidez pas la vélocité de l’équipe ».
3. La structure de l’équipe influe sur la dynamique
L’équipe d’Alan consacrait les deux derniers jours du sprint aux tests, à la clôture du sprint et à la préparation du sprint suivant. L’équipe partait simplement du principe qu’Alan suivait cette structure. Il testait les nouvelles fonctionnalités mises en œuvre à la fin du sprint, refaisait certains tests au sprint suivant et cherchait à améliorer globalement les tests. Rien de problématique à première vue, n’est-ce pas ?
La réalité est tout autre. Le logiciel n’est disponible que le dernier jour du sprint. Les éléments du backlog aident peu à comprendre précisément comment il est censé fonctionner. Tandis que l’équipe discute des détails de ce qu’elle fera au prochain sprint, Alan tente de déterminer ce qu’il doit tester sur ce sprint-ci. Il pose alors des questions juste avant que les développeurs ne partent et effectue ses tests le week-end. Heureusement, l’équipe discute de ce qu’il faut documenter. Alan peut alors tester sans déranger les développeurs. Pari gagné.
Plus la structure d’équipe évolue, plus Alan est isolé. L’équipe ne voit pas ses difficultés. Ils ne remarquent que ses questions jugées bêtes et ses résultats tardifs, de faible valeur. Il fait office de boulet.
La spécification par l’exemple montre très bien comment le test et les testeurs peuvent être partie intégrante d’une équipe agile. Les testeurs participent aux ateliers de raffinement, contribuent à créer une spécification testable, concentrent les efforts sur ce qui compte, améliorent les processus de l’équipe, les compétences individuelles et les outils, et réalisent également une partie des tests. Les activités de test sont continues et non reléguées à la fin du sprint uniquement.
4. Ignorer les règles fondamentales et foncer droit vers les ennuis
L’équipe d’Alan néglige les règles fondamentales de l’ingénierie logicielle.
En voici cinq :
- Des imprévus surviennent toujours. Manquer de marge pour les gérer conduit à la précipitation, aux raccourcis, aux erreurs stupides, à des conflits tendus, et donc à un ralentissement du progrès à long terme.
- La pression retarde. La pression réduit l’espace disponible pour les imprévus.
- La qualité est émergente. L’équipe doit adopter une culture de la qualité. Le test n’est qu’une pièce du puzzle. Et un membre qui défend seul la qualité face à tous les autres échoue généralement.
- Changer l’équipe la ralentit. Instaurer la confiance, adapter les processus, résoudre davantage de conflits : l’équipe a besoin de temps et d’énergie pour intégrer de nouveaux membres. Ajouter des personnes à un projet en retard le retarde encore plus.
- Les défauts servent à apprendre. Quand un processus génère trop de défauts, il faut l’arrêter, le corriger et en tirer des leçons. Ne pas accuser, et surtout, ne pas accélérer le rythme.
Il existe d’autres règles du même genre et toute négligence à leur égard aggrave la situation. C’est ce qui s’est produit pour Alan.
5. La perception d’une situation sous contrainte comme déclencheur
Pourquoi l’équipe ignore-t-elle d’aussi fondamentaux principes ? Facile à deviner. C’est typique d’une situation sous contrainte, où les conditions (livrables, temps disponible et ressources de l’équipe) ne laissent pas assez de marge pour gérer l’imprévu. Déjà vu, déjà vécu, un cas classique. Les mécanismes d’épuisement exploitent la seule variable possible : l’énergie que l’équipe est capable de fournir, c’est-à-dire l’énergie consommée par chacun de ses membres.
La question cruciale : l’équipe d’Alan est-elle vraiment dans une telle situation et livrer toutes les fonctionnalités est-il vraiment la meilleure option ? On ne peut qu’en faire l’hypothèse. L’équipe en a fait autant et s’est précipitée à développer l’ensemble des fonctionnalités.
C’est la perception de la situation contrainte qui influence. Le déclencheur de cette perception peut être une clause contractuelle, une prime, une grande opportunité commerciale, une forte demande d’un supérieur, une promesse tenue, un souhait client, une réglementation étatique.
Alan anticipe une avalanche de bugs et l’anxiété le pousse à les traquer. Sa question centrale : est-ce vraiment si important dans ce cas de trouver tous ces bugs ? On ne peut que supposer, et Alan aussi. Il a supposé que oui.
La perception d’une situation tendue est un levier important pour sortir du mécanisme d’épuisement. Derrière cela se trouve une autre règle fondamentale de l’ingénierie logicielle :
- Des attentes trop élevées. Les parties prenantes – y compris les développeurs eux-mêmes – espèrent, attendent ou exigent davantage que ce que l’équipe logicielle peut raisonnablement livrer.
En regardant mes 25 dernières années d’expérience projet, je ne me souviens pas d’une seule où cela n’ait pas été le cas. C’est le cœur de la tension entre ce qui est attendu et ce qui peut réellement être livré. La réussite d’un projet repose sur la capacité des personnes impliquées à résoudre ce conflit. Je recommande de se pencher sur les bonnes pratiques de gestion des parties prenantes et des attentes, gestion des conflits, ingénierie des exigences, agilité, etc.
Dans tous les cas, il s’agit de bien comprendre la nature du conflit. Quelle est son importance ? Qu’est-ce qui le motive ? Avec qui faut-il travailler ? Ou, comme l’un des professionnels QA interviewés l’a formulé : « Je pense que chaque entreprise doit prendre une décision consciente au sujet de la qualité, du coût et du délai ». Chaque entreprise doit œuvrer sur ses attentes.
Les professionnels QA ne sont généralement pas en position de mener cette discussion. Ils peuvent essayer d’y contribuer. Il peut être plus judicieux de gérer les attentes rencontrées sur le plan personnel. Une interviewée m’a confié sa méthode : « Il est impossible de tout tester. Mieux vaut définir une boîte à temps et les priorités avec le product owner. Les priorités reflètent le risque à ne pas tester. Si besoin, il faut renégocier la boîte à temps et les priorités. »
6. Le piège de l’agilité
Une équipe solide qui s'adapte en continu aux besoins changeants, une façon non bureaucratique de gérer le changement, des moyens simples de planification et de contrôle de l'avancement : le mouvement agile a amené une multitude d’innovations dont les équipes de développement auraient tout intérêt à profiter. Pourtant, l’agilité semble accentuer la pression.
Tout commence avec le vocabulaire : « Sprint » évoque la rapidité, « vélocité » aussi, il faut échouer vite. Les principes agiles placent le code en priorité, prendre de l’avance sur la réflexion est facilement écarté comme du gaspillage. Même le terme « scrum » vient du rugby, sport où les joueurs se percutent à pleine vitesse. Ainsi, l’agilité, parfois malgré elle, promeut la vitesse au détriment de la qualité. « Les méthodologies comme Agile et DevOps encouragent l’idée de tout faire encore plus vite », se plaignait un professionnel du QA.
Les mécanismes de scrum, par exemple, sont même pires que le vocabulaire. Il ne s’agit pas de dire que les créateurs de Scrum souhaitaient provoquer le burnout. Mais scrum mène les équipes sur une fausse piste.
D’abord, scrum focalise l’attention de l’équipe sur le backlog. Le rôle du product owner : ajouter des éléments au backlog. Celui du membre de l’équipe : les prendre et les traiter un par un. Celui du scrum master : s’assurer que cela va plus vite. Ensuite, le contrôle de l’avancement agile exige des éléments de backlog petits, réalisables en quelques jours. Les gourous recommandent également des critères d’acceptation précisément définis avant le sprint. Les membres de l'équipe reçoivent des tâches bien définies et de petite taille à livrer. Ils rapportent chaque jour le temps nécessaire pour les clôturer. La vélocité indique à tous la performance. Les micro-managers jubilent et contrôlent chaque minute : aucun espace pour la créativité, pression pour toujours aller plus vite : une course effrénée.
Dans ce contexte, dans une situation apparemment tendue, peu importe que le produit soit excellent pour les utilisateurs ? Pas du tout, c’est le travail de l’équipe UX. Faut-il que cela ait du sens ? Rôle du product owner. Que les critères d’acceptation soient complets ? Encore le product owner. L’absence de bug est-elle importante ? Travail du testeur, une fois les critères acceptés. Qu’est-ce qui compte vraiment ? Que j’aie fini mon élément du backlog dans les temps. Comprenez-vous la position d’Alan ? Scrum pousse les équipes à livrer toutes les fonctionnalités. La qualité, c’est le job d’Alan. La règle fondamentale est violée, les choses empirent.
L’équipe d’Alan se plie aussi au principe de l’engagement. Ils remplissent le sprint avec autant d’éléments du backlog que le suggère la vélocité. Puis ils font le serment de tout livrer. Vient alors une autre loi fondamentale : l’imprévu arrive toujours. Plutôt que de rompre leur serment, ils prennent des raccourcis et grignotent sur les tests. Livré dans les temps, bravo ! Un des interviewés l’a dit très clairement : « La gamification de l’engagement par nombre de points d’histoire crée une compétition malsaine. »
L’équipe d’Alan est tombée dans le piège de l’agilité. Elle applique Scrum sans être agile. Comparez les deux images suivantes, la première illustre l’esprit Scrum, la seconde ce qu’est l’agilité véritable.
Scrum se concentre sur le processus qui transforme les éléments du backlog en produit.
L’agilité vise à créer un impact avec un produit et à favoriser les interactions entre les personnes concernées : ceux qui commandent un produit, ceux qui l’utilisent et ceux qui le créent.
Si Scrum est un excellent outil pour les équipes réellement motivées, il devient catastrophique dans une hiérarchie descendante et autoritaire !
À retenir
Dans le secteur logiciel, il est important de développer des mécanismes de défense contre le stress et le burnout chez les professionnels du test logiciel. Dans certaines entreprises plus que dans d’autres. Certaines situations sont réellement tendues, d’autres sont rendues tendues intentionnellement. Mais la plupart semblent bien plus tendues qu’elles ne le sont. Ce qui nous pousse à suivre nos drivers, à cesser de travailler sur les conflits et à ignorer les règles fondamentales.
Le tableau suivant résume les rouages d’un système conduisant au burnout.
Éléments clés d’un système de burnout
- Tension ressentie : écart entre ce que l’on considère comme sa tâche et ce que l’on est capable de livrer. Réfléchir à ce qui est vraiment la meilleure chose à accomplir peut désamorcer le système de burnout.
- Drivers : déterminent où va l’énergie et nous empêchent d’agir avec sagesse en période de tension. Découvrir nos drivers peut aider à dépenser moins d’énergie et à mieux la dépenser.
- Conflits : les exacerbent, rendent l’équipe moins efficace et épuisent l’énergie. Créons une culture d’équipe qui accueille les conflits et encourage l’entraide.
- Règles fondamentales : elles sont facilement négligées. Les voir ignorées est le signe que tout va empirer. Il faut réagir !
- Structure de l’équipe : fige les bonnes et mauvaises pratiques. Modifier la structure d’équipe peut changer fondamentalement qui fait quoi et la façon dont les personnes interagissent. Cela peut complètement bouleverser les règles du jeu.
- Cercles vicieux : résultent de l’interaction entre les acteurs dans et autour de l’équipe et aggravent sans cesse la situation. Savons-nous repérer les cercles vicieux qui nous piègent ? Il faut les interrompre et les corriger !
- Piège de l’agilité : c’est adopter des cadres agiles sans être réellement agile. Résultat : une course sans fin. Concentrons-nous sur les utilisateurs, la création d’un excellent produit et la qualité de nos interactions, plutôt que de simplement brûler les éléments du backlog.
En tant que professionnel du QA, vous n’êtes peut-être pas en mesure d’améliorer globalement la situation. Mais il est possible de réduire un peu le stress.
J’ai demandé à Jonathon Wright : « As-tu déjà vu des entreprises ou des équipes agir concrètement pour promouvoir la santé mentale chez les professionnels du QA ? Qu’est-ce qui fonctionne ? »
Il a répondu,
« Après avoir passé l'année dernière à aider le gouvernement britannique à se préparer au Brexit, j'ai été extrêmement impressionné par l'éthique de travail. J'ai assisté à mon premier cours de pleine conscience obligatoire, qui s'est révélé extrêmement utile, il y avait des spécialistes de la santé mentale sur place et même des groupes de soutien qui se réunissaient chaque semaine. »
Il a également souligné que les QAs peuvent faire beaucoup pour gérer leur stress et leur anxiété à titre personnel :
« La vie est trop courte pour s'inquiéter des petites choses. Il est difficile pour les professionnels QA de ne pas s'inquiéter avant une sortie majeure d'un nouveau produit ou de ne pas se sentir responsables des résultats. Mais, comme dans l'épisode II avec Parveen, parfois il suffit de ‘laisser aller, laisser aller’ et de ne pas ‘vouloir toujours être parfait’. »
Jonathon Wright, animateur du podcast The QA Lead
« En tant que personne ayant dû gérer l'anxiété tout au long de ma carrière professionnelle, cela a eu ses écueils et ses défis, mais j'en suis toujours ressorti plus fort et dans une meilleure position pour mieux gérer mon anxiété — apprenant chaque fois un peu plus sur moi-même. Le secteur attire effectivement des personnes se trouvant à divers degrés du spectre (dans lequel je m'inclus). Cependant, les personnes les plus talentueuses avec qui j'ai eu l'opportunité de travailler ont souffert de troubles mentaux ; c'est pourquoi je considère ma maladie mentale comme un superpouvoir ! »
Comme Jonathon l'a souligné, avec un peu de chance et la bonne attitude, vous pouvez transformer un métier stressant en une activité gratifiante. Je vous encourage à adopter le point de vue proposé par le concept de système contre l'épuisement professionnel. Laissez tomber l'anxiété, gardez votre calme. Puis regardez au-delà des commandements, des processus et des outils. Concentrez-vous sur l'essentiel : la façon dont vous et vos coéquipiers vous entraidez pour créer de formidables produits.
