Épuisement professionnel dans les tests logiciels : 6 causes & comment y remédier

J’ai étudié la question du burn-out dans les tests logiciels en me demandant :

• À quoi ressemble le burn-out dans ce secteur ?
• Quelle est l’ampleur du problème ?
• Qu’est-ce qui crée des systèmes dans lesquels les testeurs de logiciels s’épuisent ?
• Comment pouvons-nous déconstruire le problème du burn-out et le résoudre ?

Les réponses — ou du moins leur commencement — se trouvent dans cet article.

Le burn-out chez les professionnels des tests logiciels en informatique 

Le stress lié au travail est une réalité à laquelle beaucoup d’entre nous sont confrontés dans le secteur informatique. Je suis certain que vous connaissez également votre lot de stress. Dans mon contexte, malheureusement, le burn-out est devenu un sujet de plus en plus présent ces dernières années.

Le burn-out est-il un problème ?

Lorsque j’ai demandé à Jonathon Wright : « Quelle est, selon vous, l’ampleur du problème du burn-out chez les professionnels de l’assurance qualité ? », voici ce qu’il a répondu :

« C’est un problème immense. Comme le dit une célèbre expression : on ne peut pas sprinter tout le temps. »

Jonathon Wright, animateur du podcast The QA Lead

Il a poursuivi son explication :

« Les méthodologies comme Agile et DevOps encouragent l’idée de tout faire encore “plus vite”. Comment un professionnel de l’assurance qualité peut-il apporter une valeur mesurable dans un environnement où il faut échouer rapidement et apprendre vite ?

Lors d’un récent podcast sur QALead, l’expression « ralentir pour accélérer » a été évoquée. À moins que les entreprises ne célèbrent l’échec — ce que très peu d’entre elles font —, chaque fois que vous échouez, vous n’aidez pas la vélocité du reste de l’équipe. 

L’indice se trouve dans le titre du graphique de suivi de l’avancement, utilisé à outrance. La gamification du fait de s’engager sur un certain nombre de points d’histoire crée une compétition malsaine.

« Vous êtes contraint de faire plus avec moins, en travaillant selon l’attente irréaliste que le travail puisse être livré lors de sprints de deux semaines. »

Jonathon Wright, animateur du podcast The QA Lead

À quoi ressemble le burn-out dans l’assurance qualité ?

Le burn-out n’est pas un cas isolé dans le secteur des logiciels, mais à quoi ressemble-t-il ?

Voici les réponses de professionnels des tests logiciels, qui montrent les différentes façons dont le burn-out se manifeste dans l’assurance qualité.

« Nous devons prouver notre valeur. Les équipes me disent qu’elles sont agiles et qu’elles n’ont pas besoin de testeurs. »

« L’anxiété. Il est difficile pour les professionnels de l’assurance qualité de ne pas s’inquiéter avant une mise en production majeure ou de ne pas se sentir responsables des résultats. »

« La pression du temps. Les testeurs sont toujours les derniers. Et je n’obtiens jamais le temps dont j’ai besoin. En plus, ce temps est réduit de moitié parce que les développeurs prennent du retard. »

« Des attentes irréalistes. Je pourrais tester indéfiniment sans être capable de tout tester. Dites cela à un chef de projet. À quoi sert un testeur s’il ne trouve pas les bogues ?! »

« Déterminer, à partir des éléments du carnet de produit, ce qu’il faut tester est presque impossible. Et personne ne mentionne les cas limites. »

« Le gaspillage est frustrant. Les développeurs ne parviennent pas à reproduire un bogue, l’élément du carnet de produit est obsolète ou ils l’ont déjà corrigé. »

« Beaucoup ne veulent pas d’un rapport honnête, et surtout pas de mauvaises nouvelles. Lorsque vous insistez, cela peut devenir personnel. »

REJOIGNEZ LA COMMUNAUTÉ

Améliorez votre boîte de réception avec plus de conseils en leadership technologique pour livrer de meilleurs logiciels et systèmes.

Get Free Access

Have an account? Log In

Pourquoi le burn-out survient-il ?

La littérature recense de nombreux facteurs qui provoquent du stress et augmentent la probabilité de burn-out. Il existe des facteurs individuels, par exemple des moteurs personnels tels que vouloir être parfait, se dépêcher, en faire toujours plus, se montrer fort ou faire plaisir aux autres. Consultez l’analyse transactionnelle pour plus de détails. 

Il existe également des facteurs de stress liés à l’environnement de travail : charge de travail élevée, pression du temps, objectifs et attentes irréalisables, manque de contrôle, conflits qui s’enveniment, peur de perdre son emploi, insatisfaction professionnelle, intimidation et harcèlement moral, entre autres. Nous les connaissons.

Il y a quelque temps, j’ai commencé à examiner l’épuisement professionnel d’un point de vue systémique et j’ai créé un jeu de simulation dans lequel 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 manière à ce que certains membres d’une équipe finissent inévitablement par s’épuiser. Vous pouvez avoir un aperçu du jeu sur mon blog.

Cette approche systémique fonctionne également pour différents rôles au sein d’une équipe. Je l’ai mise en œuvre pour des professionnels de l’expérience utilisateur et j’ai été surpris de constater à quel point il est facile de pousser ces personnes au cœur d’un système d’épuisement professionnel. Lorsqu’ils prennent soin des utilisateurs, ils sont particulièrement disposés à mener un combat supplémentaire et à risquer de sombrer.

Ci-dessous, je vais me pencher sur l’histoire d’Alan, un professionnel de l’assurance qualité, afin de mieux comprendre et d’illustrer le problème de l’épuisement professionnel dans le secteur des logiciels. 

Ensuite, je parlerai de la manière dont les systèmes d’épuisement professionnel sont créés et de ce que nous pouvons faire pour améliorer ces systèmes.

Une histoire personnelle d’épuisement professionnel

Maintenant que je suis certain de pouvoir concevoir un système d’épuisement professionnel pour des professionnels de l’assurance qualité, laissez-moi vous présenter Alan et son histoire. 

Alan possède près de dix ans d’expérience dans les tests logiciels, et plus particulièrement 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 lui en reste quatre avant une première mise en production. 

Comment s’est passée la première journée d’Alan sur le projet ?

Alan : J’ai beaucoup de travail. Le logiciel est de mauvaise qualité. Je m’attends à trouver de nombreux bogues non détectés et je crains des problèmes si je ne parviens pas à les trouver avant la mise en production.

Markus : Identifier les bogues est donc ta priorité absolue pour améliorer la qualité ?

Alan : C’est une partie du problème. Nous nous attendons également à avoir de nombreux utilisateurs. Les performances du logiciel seront d’une importance capitale lorsque nous le déploierons auprès du grand public. L’équipe compte beaucoup sur mon expertise dans ce domaine.

Jusqu’à présent, Alan est plutôt optimiste quant au fait que les mesures convenues avec l’équipe amélioreront la qualité du logiciel. Hélas, un sprint plus tard, alors qu’il n’en reste plus que trois, Alan n’a plus l’air très 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 je suis loin d’y parvenir.

Markus : Qu’est-ce qui t’en empêche ?

Alan : J’ai besoin de l’aide des développeurs, mais ils sont débordés. J’ai également eu besoin de beaucoup plus de temps que prévu pour me familiariser avec le logiciel et signaler les bogues que j’ai trouvés.

Markus : As-tu pu tester les nouvelles fonctionnalités 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 encore loin d’avoir terminé.

Lors de la rétrospective du sprint douze, alors qu’il ne reste plus que deux sprints, les tests constituent le sujet numéro un : le responsable produit s’est plaint du nombre de bogues trouvés par Alan.

Développeur : La plupart des bogues trouvés par Alan sont soit insignifiants, soit ne sont pas des bogues du tout. Commençons par les examiner avant de tirer des conclusions.

Alan : Eh bien, j’ai eu du mal à comprendre ce que le logiciel devait faire à partir des éléments du carnet de produit. Une spécification m’aiderait vraiment.

Développeur : Il faudra me passer sur le corps ! Nous ne voulons pas du modèle en cascade. C’est surtout une question de bon sens. Venez simplement nous poser des questions. Où en sont les tests de performance ?

Alan : Je suis dans une impasse. Je n’arrive pas à faire fonctionner l’outil sur la couche de services à cause de toutes ces mesures de sécurité. J’ai besoin d’aide.

Développeur : Nous avons utilisé un autre outil lors du dernier projet. Il a parfaitement fonctionné. Je vais t’envoyer le lien.

En conséquence, le responsable produit organise une réunion express de deux heures lors du sprint suivant. L’objectif est d’examiner les bogues et de discuter de ce qu’il faut consigner dans les éléments du carnet de produit afin de faciliter les choses pour le nouveau venu Alan. Sentez-vous la frustration d’Alan monter ?

La position désespérée d’Alan, devenu le bouc émissaire, apparaît encore plus clairement après le sprint treize, alors qu’il n’en reste plus qu’un. Voici les décisions prises lors de cette rétrospective :

• De nombreux bogues ont été trouvés dans des fonctionnalités qu’Alan aurait dû tester lors du sprint précédent. Aucune fonctionnalité ne devra être clôturée sans avoir été testée par Alan.
• Toujours aucun test de performance. Nous allons faire intervenir un expert. Alan devra lui exposer la situation.
• Impossible de terminer deux fonctionnalités. Nous avons perdu deux jours à écarter des rapports de bogues inutiles. Alan indique la pertinence de chaque bogue. En cas de doute, demander au responsable produit.

Vous l’avez remarqué ? L’équipe n’a pas terminé deux récits et a réussi à rejeter la faute sur Alan ! 

Imaginez le sprint suivant, lorsque les récits ne sont pas clôturés parce qu’Alan n’a pas eu le temps de les tester ! Pas étonnant qu’Alan ait l’air épuisé.

Alan : Il ne reste que deux semaines avant la mise en production et la qualité est un cauchemar. Dites cela au propriétaire du produit ! Et ils ont effectivement supprimé les tests de performance. C’était la raison pour laquelle j’ai rejoint le projet à la base. Mon patron est mécontent. Il voulait que je montre l’exemple sur la façon d’intégrer les testeurs dans les équipes agiles. Je vais tout de même devoir me battre pour y arriver, ma réputation dans l’entreprise est en jeu.

Quatre semaines plus tard, deux semaines après la première mise en production auprès d’un public restreint, le système d’épuisement est pleinement opérationnel. 

Résumé des accomplissements d’Alan jusqu’à présent :

• Tests de performance : échec
• Être reconnu comme expert en tests de performance : échec
• Être capable de tester minutieusement les éléments nouvellement développés : échec
• Être capable de retester minutieusement les éléments déjà développés : échec
• Intégrer les testeurs dans les équipes agiles : échec
• Aucun bogue critique dans la mise en production : échec
• Être recommandé : échec
• Travailler dur et être accusé : réussi
• Peur de perdre son emploi : réussi
• Épuisement professionnel : en bonne voie à toute vitesse

Il s’agit d’un cas classique de système d’épuisement. Alors, qu’est-ce qui crée ce système et comment pouvons-nous l’atténuer ?

Qu’est-ce qui crée un système d’épuisement ?

Pour Alan, on pourrait dire que la cause est perdue dès le départ. Et ce serait exact. Alan se trouve dans un système d’épuisement qui agit au sein de l’équipe depuis un certain temps déjà. Le système d’épuisement désigne Alan comme une proie, tel un prédateur face à sa victime. Mais qu’est-ce que ce système d’épuisement et comment agit-il ?

Un système d’épuisement est une constellation de personnes, de facteurs moteurs et de conflits. Par un cycle de renforcement, il crée une situation si remplie de facteurs de stress que certaines personnes finissent par s’épuiser. Il est particulièrement puissant lorsqu’il peut déclencher la logique de survie des individus.

1. L’énergie suit les facteurs moteurs

Dans l’histoire d’Alan, nous pouvons repérer certains facteurs moteurs :

• L’ambition et la fascination pour le sujet de prédilection des tests de performance donnent à Alan envie de s’en charger.
• L’anxiété d’être responsable d’une mise en production ratée pousse Alan à rechercher les bogues.
• Quelque chose pousse les membres de l’équipe à développer les fonctionnalités avant toute autre chose.

Les facteurs moteurs modifient le cours de l’action. Les gens ont beaucoup de mal à réfléchir clairement à ce qu’il faut accomplir et à la manière d’y parvenir. L’énergie qu’ils investissent suit le facteur moteur, et non l’endroit où elle est le plus nécessaire. L’équipe d’Alan ne se demande jamais si développer toutes les fonctionnalités est la bonne chose à faire. Alan, lui non plus, ne se demande pas si rechercher les bogues est approprié.

Pour la plupart d’entre nous, la difficulté consiste à prendre conscience qu’un facteur moteur a pris le contrôle. Heureusement pour nous, les psychologues les ont étudiés. Pour les facteurs moteurs personnels, commencez par l’analyse transactionnelle. Au niveau de l’équipe, la pensée de groupe constitue un bon point de départ. Vous y trouverez une multitude de conseils.

Concernant l’anxiété avant une mise en production, l’un des professionnels de l’assurance qualité expérimentés a conseillé : « Il suffit de lâcher prise et de rester calme ». Avec un tel état d’esprit dès le début, Alan poursuivrait probablement un objectif différent de celui qui consiste à traquer tous les bogues et mettrait en place des tests de performance. Les priorités absolues pourraient être que l’équipe élimine les bogues critiques et fournisse globalement une meilleure qualité. Une façon de réduire le stress associé aux tâches répétitives consiste à tirer parti d’outils de premier ordre conçus pour les tests de logiciels.

2. Les conflits attisent les tensions et deviennent personnels

Parallèlement aux facteurs moteurs, des conflits éclatent au sein de l’équipe. Par exemple, Alan a besoin de plus de temps de la part des développeurs qu’ils ne sont prêts à lui en accorder. Résultat : Alan fait beaucoup de bruit et les développeurs essaient de le tenir à distance. Avec peu d’aide, Alan ne peut pas répondre aux attentes. Il craint pour sa réputation, redouble d’efforts et génère encore plus de bruit.

Le plus grave, c’est que les conflits deviennent personnels. Ayant travaillé comme testeur pendant dix ans, Alan est probablement un véritable expert. Pourtant, l’équipe le considère comme un canard boiteux et agit en conséquence. Plus cette situation dure, plus elle s’envenime. Cela affecte même Alan : il commence à remettre en question ses compétences.

Combien de fois avez-vous rejeté la faute sur quelqu’un ? Combien de personnes autour de vous ne font-elles pas correctement leur travail ? Chacune de ces pensées révèle un conflit devenu personnel.

La plupart des équipes sont incapables de résoudre les conflits. Cela ne va pas de soi. La gestion des conflits est le mot-clé pour trouver des conseils. Le message essentiel est le suivant : les équipes ont besoin d’une culture dans laquelle les idées peuvent être échangées ouvertement, où les points de vue divergents sont accueillis comme des occasions de créer de nouvelles choses et où l’entraide est valorisée. Un objectif difficile à atteindre si l’on compare cela à la culture de la vitesse décrite par une personne interrogée : « À 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 influence la dynamique de l’équipe

L’équipe d’Alan a réservé les deux derniers jours du sprint aux tests, à la clôture du sprint et à la préparation du sprint suivant. L’équipe a simplement supposé qu’Alan suivait cette structure. Il testerait les fonctions nouvellement implémentées à la fin du sprint et effectuerait également quelques nouveaux tests lors du sprint suivant, tout en améliorant globalement les tests. Cela ne semble pas si mal, n’est-ce pas ?

La réalité raconte une tout autre histoire. Le logiciel n’est disponible que le dernier jour du sprint. Les éléments du backlog aident peu à comprendre exactement comment il devrait fonctionner. Pendant que l’équipe discute des détails de ce qu’elle fera lors du sprint suivant, Alan essaie de déterminer quoi tester parmi les éléments de ce sprint. Il pose ensuite des questions juste avant le départ des développeurs et effectue les tests pendant le week-end. C’est formidable que l’équipe discute de ce qu’il faut consigner. Alan peut alors tester sans déranger les développeurs. Bingo.

La structure de l’équipe isole de plus en plus Alan. L’équipe ne voit pas les difficultés qu’il rencontre. Elle ne remarque que des questions stupides et des résultats tardifs de faible valeur. Quel pauvre bougre.

La spécification par l’exemple montre très bien comment les tests et les testeurs peuvent faire partie intégrante d’une équipe agile. Les testeurs participent aux ateliers d’affinement, contribuent à créer une spécification testable, concentrent les efforts de test là où ils sont importants, améliorent les processus de l’équipe, les compétences individuelles et les outils, et effectuent même certains tests. Les tests sont réalisés en continu, et pas seulement à la fin du sprint.

4. Ignorez les règles fondamentales et allez au-devant des problèmes

L’équipe d’Alan ignore les règles fondamentales du génie logiciel. 

En voici cinq :

1. Des événements inattendus se produisent. Ne pas prévoir suffisamment de marge pour y faire face conduit à travailler dans la précipitation, à prendre des raccourcis, à commettre des erreurs stupides, à provoquer des conflits tendus et donc à progresser plus lentement sur le long terme.
2. La pression entraîne des retards. La pression laisse moins de marge pour gérer les événements inattendus.
3. La qualité émerge progressivement. L’équipe doit avoir une culture de la qualité. Les tests ne sont qu’une pièce du puzzle. Et un seul membre de l’équipe qui s’oppose à tous les autres échoue généralement.
4. Modifier l’équipe ralentit les choses. Établir la confiance, adapter les processus, résoudre davantage de conflits : l’équipe a besoin de temps et d’énergie pour intégrer les nouveaux membres. Ajouter des personnes à un projet en retard le retarde davantage.
5. Les défauts sont là pour nous apprendre. Lorsqu’un processus produit trop de défauts, arrêtez-le, corrigez-le et tirez-en les leçons. Ne blâmez personne et, surtout, n’accélérez pas le processus.

Il existe d’autres règles de ce type et, chaque fois que les gens les ignorent, les choses empirent. Et c’est bien ce qui est arrivé à Alan.

5. La perception d’une situation tendue en est le déclencheur

Comment l’équipe peut-elle ignorer des éléments aussi fondamentaux ? C’est simple. C’est typique d’une situation tendue, où les données imposées (les livrables, le temps disponible et l’équipe) ne laissent pas suffisamment de flexibilité pour gérer les événements inattendus. Du déjà-vu, un cas évident. Les systèmes d’épuisement professionnel exploitent la seule variable d’une configuration tendue : l’intensité du travail de l’équipe, c’est-à-dire la quantité d’énergie que les membres de l’équipe puisent dans leurs réserves.

La question qui se pose est la suivante : l’équipe d’Alan est-elle réellement dans une situation tendue et livrer toutes les fonctionnalités est-il vraiment la meilleure solution ? Nous ne pouvons que le supposer. L’équipe a fait de même et s’est précipitée pour essayer de construire toutes les fonctionnalités.

C’est la perception des situations tendues qui compte. Le déclencheur d’une telle perception peut être une clause contractuelle, une incitation, une excellente occasion commerciale, une forte demande d’un supérieur, une promesse faite, le souhait d’un client ou une réglementation gouvernementale.

Alan s’attend à une avalanche de bogues et l’anxiété le pousse à les traquer. La question qui se pose pour lui est la suivante : trouver les bogues est-il vraiment une étape aussi importante dans ce cas ? Nous ne pouvons que spéculer, et Alan a fait de même. Il a supposé que oui.

La perception d’une situation tendue est un levier important pour briser un système d’épuisement professionnel. Elle repose sur une autre règle fondamentale du génie logiciel :

• Des attentes trop élevées. Les parties prenantes – y compris les développeurs eux-mêmes – espèrent, attendent ou exigent davantage que ce qu’une équipe logicielle peut raisonnablement livrer.

En regardant les 25 dernières années de mon expérience sur des projets, je ne me souviens pas d’un seul projet où cela n’était pas le cas. Le conflit entre ce qui est attendu et ce qui peut être livré est le point sensible. La réussite d’un projet dépend de la capacité des personnes impliquées à résoudre ce conflit. Je recommanderais de revoir les bonnes pratiques en matière de gestion des parties prenantes et des attentes, de gestion des conflits, d’ingénierie des exigences, d’agilité, et autres domaines similaires.

Dans tous les cas, il faut comprendre la nature exacte du conflit. Quelle est son intensité ? Qu’est-ce qui l’alimente ? Avec qui devez-vous travailler ? Ou, comme l’a formulé l’un des professionnels de l’assurance qualité interrogés : « Je crois que chaque entreprise doit prendre une décision consciente concernant la qualité, le coût et la rapidité ». Chaque entreprise doit travailler sur ses attentes.

Les professionnels de l’assurance qualité ne sont généralement pas en position de diriger cette discussion. Ils peuvent essayer d’y contribuer. Il peut être plus fructueux de gérer les attentes auxquelles ils sont personnellement confrontés. Une personne interrogée m’a confié sa méthode : « Il est impossible de tout tester. Il vaut mieux définir une durée limitée et les priorités avec le responsable produit. Les priorités reflètent le risque de ne pas tester. Si le résultat ne convient pas, renégociez la durée limitée et les priorités. »

More Articles

• Comment se préparer à, et survivre à, des décisions de livraison/non-livraison
• Comment les compétences en test m’ont fait devenir un meilleur développeur en automatisation
• 6 astuces d’Ingénierie Qualité pour les équipes de développeurs à distance
• Apportez Vos Propres Outils… Mais Réfléchissez-y à Deux Fois
• 14 articles incontournables sur les tests logiciels pour s’inspirer

6. Le piège de l’agilité

Une équipe solide qui s’adapte continuellement à l’évolution des besoins, une manière non bureaucratique de gérer le changement, des moyens simples de planifier et de contrôler les progrès : le mouvement agile a fait émerger une multitude d’innovations dont les équipes de développement ont tout intérêt à tirer parti. Pourtant, l’agilité semble attiser le feu.

Cela commence par la terminologie : sprint signifie rapide, vélocité signifie rapidité, on échoue vite. Les principes agiles placent le code au premier plan, et réfléchir à l’avance est facilement considéré comme du gaspillage. Même le terme scrum vient du rugby, un sport où les athlètes se percutent à pleine vitesse. Ainsi, l’agilité, même à l’encontre de ses convictions, favorise 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 », s’est plaint un professionnel de l’assurance qualité.

La mécanique du scrum, par exemple, est encore pire que sa terminologie. Ce n’est pas que les créateurs de Scrum voulaient favoriser l’épuisement professionnel. Mais le scrum entraîne les équipes sur une mauvaise voie.

Tout d’abord, il concentre l’attention de l’équipe sur le backlog. Le travail du propriétaire du produit consiste à placer des éléments dans le backlog. Le travail d’un membre de l’équipe consiste à les prendre et à les réaliser un par un. Le travail du scrum master consiste à veiller à ce que cela se fasse plus rapidement. Ensuite, le contrôle des progrès agile nécessite de petits éléments du backlog réalisables en quelques jours. Les gourous recommandent également de définir précisément les critères d’acceptation avant le sprint. Les membres de l’équipe reçoivent de petites unités précisément définies à livrer. Ils indiquent chaque jour le temps dont ils ont encore besoin pour les terminer. La vélocité indique à tout le monde la qualité de leur performance. Les micromanagers jubilent et contrôlent chaque minute : manque de contrôle, absence d’espace créatif, pression pour aller plus vite : une course effrénée.

Dans ces conditions, dans une situation qui semble tendue, est-il important que le produit soit formidable pour les utilisateurs ? Certainement pas, c’est le travail de l’équipe UX. Est-il important qu’il ait du sens ? C’est le travail du propriétaire du produit. Est-il important que les critères d’acceptation soient complets ? Encore une fois, c’est le travail du propriétaire du produit. Est-il important qu’il soit exempt de bogues ? C’est le travail du testeur, une fois les critères d’acceptation validés. Qu’est-ce qui compte ? Que je termine mon élément du backlog à temps. Voyez-vous la position d’Alan ? Le scrum pousse les équipes à réaliser toutes les fonctionnalités. La qualité est le travail d’Alan. La règle fondamentale est enfreinte, la situation empire.

L’équipe d’Alan respecte également son engagement. Elle remplit le sprint avec autant d’éléments du backlog que l’indique la vélocité. Puis elle jure de les livrer. La loi fondamentale suivante la frappe de plein fouet : des événements imprévus se produisent. Plutôt que de rompre leur serment, les membres de l’équipe prennent des raccourcis et rognent un peu sur les tests. Terminé à temps, bravo ! L’une des personnes interrogées l’a dit très clairement : « La gamification de l’engagement sur un 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 montre ce qu’est Scrum, la seconde ce que représente l’agilité.

Scrum concerne le processus qui transforme les éléments du backlog en un produit.

L’agilité consiste à créer un impact avec un produit et à favoriser les interactions entre les personnes impliquées : celles qui commandent un produit, celles qui l’utilisent et celles qui le créent.

Si Scrum est un excellent outil pour les équipes agiles intrinsèquement motivées, il est fatal dans une hiérarchie de commandement descendante !

À retenir

Dans le secteur des logiciels, il est important de développer des mécanismes de défense contre le stress et l’épuisement professionnel chez les professionnels des tests logiciels. Dans certaines entreprises plus que dans d’autres. Certaines situations sont réellement tendues, d’autres sont rendues tendues intentionnellement. Mais la plupart des situations semblent bien plus tendues qu’elles ne le sont. Et cela nous pousse à suivre nos injonctions, à cesser de travailler sur les conflits et à ignorer les règles fondamentales. 

Le tableau suivant résume les rouages d’un système d’épuisement professionnel.

Éléments clés d’un système d’épuisement professionnel

• La tension perçue est l’écart entre ce que nous considérons comme notre tâche et ce que nous pouvons livrer. Découvrir ce qui constitue réellement la meilleure chose à accomplir peut démanteler le système d’épuisement professionnel.
• Les injonctions définissent la direction dans laquelle circule l’énergie et nous empêchent d’agir avec discernement dans une situation tendue. Découvrir nos injonctions peut nous aider à dépenser moins d’énergie et à la dépenser plus judicieusement.
• Les conflits attisent la situation, rendent une équipe moins efficace et épuisent son énergie. Créons une culture d’équipe où nous accueillons les conflits et nous aidons les uns les autres.
• Les règles fondamentales sont facilement ignorées. Les voir ignorées est un signe certain que la situation va empirer. Nous devons agir !
• La structure de l’équipe fige les bonnes et les mauvaises pratiques. Modifier la structure des équipes peut changer fondamentalement qui fait quoi et la manière dont les personnes interagissent. Cela peut complètement changer les règles du jeu.
• Les cercles vicieux émergent de l’interaction entre les acteurs de l’équipe et ceux qui l’entourent et rendent la situation de plus en plus difficile. Pouvons-nous repérer les cercles vicieux qui nous ont piégés ? Nous devons les arrêter et les corriger !
• Le piège de l’agilité consiste à adopter des cadres agiles sans être agile. Le résultat est une course effrénée. Concentrons-nous sur les utilisateurs, la création d’un excellent produit et la manière dont nous interagissons, plutôt que sur la réduction du nombre d’éléments du backlog.

En tant que professionnel de l’assurance qualité, vous n’êtes peut-être pas en mesure de changer la situation globale pour l’améliorer. Mais vous pouvez probablement réduire une partie du stress. 

J’ai demandé à Jonathon Wright : « Où avez-vous vu des entreprises ou des équipes prendre des mesures pour promouvoir la santé mentale des professionnels de l’assurance qualité ? 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 professionnelle. J’ai suivi mon premier cours obligatoire de pleine conscience, qui s’est révélé extrêmement utile ; des spécialistes de la santé mentale étaient présents sur place, ainsi que des groupes de soutien qui se réunissaient chaque semaine. »

Il a également souligné que les professionnels de l’assurance qualité peuvent faire beaucoup pour gérer leur stress et leur anxiété sur le plan personnel :

« La vie est trop courte pour s’inquiéter des petites choses. Il est difficile pour les professionnels de l’assurance qualité de ne pas s’inquiéter avant la sortie majeure d’un nouveau produit ou de ne pas se sentir responsables des résultats. Mais comme dans l’épisode II avec Parveen, il faut parfois simplement “laisser tomber, laisser tomber” et ne pas “garder son calme”. »

Jonathon Wright, animateur du podcast Le responsable de l’assurance qualité

« En tant que personne qui a géré son anxiété pendant toute sa carrière professionnelle, j’ai rencontré des écueils et des difficultés, mais j’en suis toujours ressorti plus fort et mieux armé pour mieux gérer mon anxiété — en apprenant davantage sur moi-même à chaque fois. Le secteur attire effectivement des personnes qui se situent à différents degrés du spectre (et je m’inclus dans cette catégorie). Cependant, les personnes les plus talentueuses avec lesquelles j’ai eu l’occasion 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 travail stressant en une activité gratifiante. Je vous encourage à adopter le point de vue proposé par le concept d’un système d’épuisement professionnel. Laissez votre anxiété s’en aller, restez calme. Puis regardez au-delà des commandements, des processus et des outils. Concentrez-vous sur ce qui compte vraiment : la manière dont vous et vos coéquipiers vous entraidez pour créer d’excellents produits.