Comment Nous Avons Construit La Testabilité ?

La testabilité permet aux équipes d'apporter des changements à leur code de base sans test de régression approfondi. Pour renforcer la testabilité, les équipes doivent collaborer et tirer parti des compétences de chacun. Malheureusement, une collaboration efficace ne se fait pas naturellement et nécessite donc un leadership qui va encourager les gens à s'exprimer et à partager leurs connaissances.

Pourquoi la testabilité ?

En tant que membre de l'équipe de développement, nous voulions réduire les incertitudes générées dès que nous apportions des changements à notre lecteur multimédia, telles que des corrections de bugs ou la refactorisation du code pour le rendre de plus en plus maintenable à mesure que le système évoluait. Toute modification, qu'il s'agisse de correction de bug ou d'une nouvelle fonctionnalité, nécessitait presque toujours un cycle de test de régression approfondi. Nous ne pouvions pas affirmer avec certitude qu'une modification du système n'avait pas affecté son comportement sans que nos testeurs n'explorent les principales fonctionnalités et confirment qu'il se comportait toujours comme nous l'avions prévu.

Pour nous, la testabilité signifiait qu'il fallait réduire les incertitudes générées lors de la modification de notre système. Cela signifiait alors que nous pouvions libérer le lecteur à nos équipes produit et qu'ils pouvaient l'intégrer dans leurs applications. Par conséquent, nous pouvions dire en toute confiance que nous n'avions pas besoin de passer par de longs cycles de tests de régression manuels.

Implémentation de la testabilité

Nous savions que si nous continuions à travailler comme nous l'avions fait nous aboutirions au même résultat, nous devions donc changer notre processus de développement. Au départ, les développeurs écrivaient le code et effectuaient les tests dont ils avaient besoin pour s'assurer que ce qu'ils avaient développé fonctionnait. Ensuite, les développeurs confiaient aux testeurs le soin d'effectuer les tests supplémentaires qu'ils jugeaient nécessaires. S'ils trouvaient un problème, il était signalé aux développeurs qui le corrigeait et le retournait aux testeurs. Ce cycle s'est poursuivi jusqu'à ce que les deux parties soient satisfaites et que l'équipe ait pu réaliser la sortie.

De manière générale, les développeurs et les testeurs travaillaient en mini silo. Cela ressemblait plutôt à une course de relais, chaque sprinteur travaillant dans son coin tout en essayant de faire avancer le travail jusqu'à la ligne d'arrivée dans l'espoir de rattraper le temps perdu pendant leur mini sprint. Tout le monde travaillait ensemble mais était concentré sur une partie seulement de la course. Il s'agissait plus de coopérer pour faire le travail que de collaborer.

Aussi, afin de changer notre façon de travailler, nous sommes retournés à nos planches à dessin. Et, pour éviter que les développeurs et les testeurs ne se retrouvent à travailler dans leur coin, nous avons encouragé la programmation en binôme puis en groupe de trois. Ce groupe était composé de deux développeurs et d'un testeur. Le travail consistait à écrire et à tester ensemble jusqu'à ce que la fonctionnalité soit construite et publiée. Dans ce trio, les développeurs testaient avec le support du testeur et le testeur écrivait du code soutenu par les développeurs. Chacun apprenait petit à petit à comprendre ce que faisait l'autre et commençait surtout à voir comment il pouvait faire les choses autrement.

Au début, les deux parties hésitaient un peu à travailler ainsi. Les testeurs ne savaient pas s'ils pouvaient suivre les développeurs et comprendre ce qu'ils développaient ni même écrire du code. Les développeurs craignaient de devoir aller trop lentement et de s'enliser dans des tests exploratoires. Aussi, au tout début, le responsable du développement a travaillé avec le trio et a modélisé la façon de travailler pour le groupe. Il effectuait un programme en prenant en compte toutes les personnes puis à tour de rôle pour coder et associait ce programme avec le testeur pour montrer comment cela pouvait fonctionner. Une fois le programme développé et testé de manière exploratoire, le responsable du développement laissait le testeur prendre le relais et diriger le groupe avec le reste de ce qui devait être testé.

Cette approche a, petit à petit, démontré au groupe de travail comment ils pouvaient travailler ensemble. En outre, la présence du responsable du développement, a rendu l'expérience plus sûre. De fait, les développeurs pouvaient désormais travailler moins vite qu'ils ne le font généralement et les testeurs pouvaient s'interroger et demander s'ils n'avaient pas compris. Enfin, elle permettait aux développeurs de renvoyer le test s'ils le considéraient non conforme au scope des modifications.

Il ne s'agissait pas ici de transformer les testeurs en développeurs ou les développeurs en testeurs mais plutôt de démontrer comment ils pouvaient mieux exploiter les compétences les uns les autres. Comment les développeurs écrivaient-ils des tests "code-level" qui garantissaient aux testeurs le fonctionnement du code  comme souhaité ? Mais aussi, comment les testeurs réalisaient-ils des tests exploratoires qui montraient aux développeurs les limites de leurs tests de code ?

Ce groupe de travail à 3 a fini par faire ressortir les compétences que l'autre pouvait apporter et à développer une compréhension beaucoup plus large car il a réalisé que la combinaison de leurs compétences pouvaient créer un produit de bien meilleure qualité. Ce niveau de collaboration a permis à l'équipe d'avancer plus vite qu'avant. Lorsque le groupe de travail développait une fonctionnalité, elle était entièrement testée de manière exploratoire et prise en charge par des tests automatisés écrits au niveau du code. Les tests automatisés ont permis aux développeurs d'apporter des modifications au code tout en sachant très bien qu'ils n'avaient pas affecté le comportement du système.

Le testeur ayant été directement impliqué dans les tests, il ne savait plus s'il était nécessaire de réaliser plus de test de régression avant la publication d'une version. De plus, ces tests pouvaient être mis à la disposition des équipes produit afin qu'ils puissent voir ce qui avait été testé et ce qui n'avait pas été testé, offrant petit à petit leur confiance en la capacité de l'équipe à fournir un lecteur multimédia stable et testé. 

Ce que nous avons appris 

Au début, le groupe de travail a mis du temps à comprendre comment travailler les uns avec les autres et ce qu'ils devaient faire comment le faire. De fait, le trio était bien plus lent que d'habitude. Les développeurs auraient pu simplement programmer par pairs pour obtenir la fonctionnalité construite, puis faire savoir au testeur ce qu'ils avaient fait. Mais travailler en trio signifiait que les développeurs devaient aller plus lentement qu'ils ne le faisaient habituellement. Ils devaient aussi aider le testeur à comprendre ce qu'ils faisaient et pourquoi ce qu'il faisait affectait le système.

Parfois, le testeur voulait réaliser des tests exploratoires auxquels le développeur devait s'impliquer afin qu'il puisse comprendre les différentes choses qu'il devait tester notamment quand les tests de code n'étaient pas en mesure de couvrir. En faisant le travail des deux disciplines, développeur et testeur ont commencé à comprendre les complexités que leurs rôles nécessitaient et que le simple fait de se le dire ne l'aurait pas permis.

Malheureusement, les gens ne fonctionnent pas spontanément comme ça. Ils ont besoin d'être encouragés et soutenus pour le faire. C'est pourquoi, le responsable doit leur permettre d'adopter une approche plus expérimentale de leur travail afin d'essayer des choses et comprendre ce qui fonctionne pour eux. Il doit également les encourager à mieux réfléchir aux résultats et à partager ce qu'ils comprennent et ce qu'ils ne comprennent pas.

Travailler de cette façon prend du temps, les dirigeants doivent donc donner à l'équipe l'espace et le soutien nécessaires pour déterminer ce qui fonctionne et ce qui ne fonctionne pas.

Pour que ça marche, le meilleur moyen d'y parvenir c'est de s'impliquer dans le processus en tant que dirigeant. Cela peut vouloir dire de prendre le volant et d'ouvrir la voie ou autoriser les autres à prendre le relais tout en les accompagnant. Cette façon de manager permet aux équipes de se rendre compte de ce qui est acceptable et ce qui ne l'est pas mais aussi de remettre en question les hypothèses et autres possibilités qui ne sont pas toujours vraies. Par exemple, plutôt que de penser que vous ne pouvez pas faire d'erreurs, dire que vous ne comprenez pas ou demander d'aller plus lentement.

Créer un environnement d'apprentissage 

Le simple fait de rassembler les gens et d'attendre qu'ils travaillent ensemble conduira probablement à un échec mais c'est le but. Vous voulez qu'ils échouent pas qu'ils s'arrêtent et reviennent à ce qu'ils étaient mais qu'ils comprennent pourquoi ils ont échoué. Vous voulez qu'ils parlent de ce qui fonctionne et de ce qui ne fonctionne pas et de ce qu'ils peuvent faire autrement.

Le problème dont le leadership a besoin pour soutenir ces personnes c'est l'hypothèse que les personnes et les équipes performantes n'échouent pas. Nous ferons donc de notre mieux pour éviter l'échec dès ses premiers signes. Le leadership doit montrer que l'échec est un sous-produit naturel de l'expérimentation et que les plus performants produisent et partagent leurs échecs ; il ne faut donc pas les éviter, les nier, les ignorer ou les déformer mais en tirer des leçons.

Pour que les gens acceptent un échec comme celui-ci, ils ont besoin d'un haut niveau de sécurité psychologique. Cela veut dire que les membres de l'équipe peuvent prendre des risques interpersonnels et être vulnérables en partageant ce qu'ils ne savent pas, ce qu'ils ne comprennent pas ou les erreurs qu'ils ont commises sans craindre d'être jugé ou que cela n'affecte leurs perspectives.

Le leadership doit aider les gens à voir que ces frontières invisibles nous retiennent et que nous n'essayons pas de le leur enlever ou de les remplacer, mais de mieux les comprendre. De plus, il faut encourager les gens à dépasser les limites de leur discipline et à être plus disposés à comprendre ce que font leurs pairs et comment et pourquoi ils le font comme ils le font. Et l'une des meilleures façons d'apprendre est de le faire.

Ensemble, nous pouvons être bien plus que la simple somme de nos disciplines. En permettant les membres de l'équipe de faire preuve de faillibilité, d'apprendre de leurs échecs et de travailler au-delà des frontières des disciplines, nous pouvons les voir évoluer depuis la coordination de leurs actions vers une véritable collaboration : une collaboration haute en sécurité psychologique et ancrée dans la confiance et le respect mutuel qui inclut naturellement l'échec dans le processus.

Favoriser la sécurité psychologique

Lorsque l'équipe de développement est passée à un groupe de travail de deux développeurs et un testeur pour implémenter la testabilité, ils ont trouvé la sécurité psychologique par hasard. Une fois que le responsable du développement a modélisé la manière dont le groupe pouvait travailler ensemble, le trio a été quasiment laissé seul. Désormais, ce groupe de travail semblait plus ouvert sur ce qu'il savait et ce qu'il ne savait pas, il demandait de l'aide ou d'être seul lorsqu'il avait besoin d'espace pour réfléchir et résoudre des problèmes seul, sachant toujours que les autres membres de l'équipe étaient à côté en cas de besoin. 

La sécurité du trio s'est renforcée quand le testeur du trio a convoqué une réunion avec les deux développeurs et le responsable du développement. Il a estimé que le trio allait trop lentement et qu'il était la raison du ralentissement. Il pensait qu'il ne pouvait pas acquérir les compétences assez rapidement et qu'il devait soit revenir à l'ancienne méthode de travail, soit trouver un autre testeur plus compétent. Le responsable du développement s'est mis à rire car il a cru qu'il voulait partir. Il l'a rassuré sur le fait que le trio allait au bon rythme et qu'ils devaient continuer comme ils étaient. Cela a démontré à tous les membres du groupe qu'il était normal d'aller lentement et qu'il était important de prendre son temps pour acquérir les nouvelles compétences et que le leadership était là pour les soutenir. 

Bien que ce groupe ait trouvé la sécurité psychologique par accident, il y a certaines choses que le leadership peut faire afin de garantir une haute sécurité psychologique. Par exemple, il pourrait s'assurer que le dirigeant connaisse la notion de sécurité psychologique. En effet, beaucoup l'associe à une confiance en soi élevée et imaginent des espaces de travail sûr. Néanmoins, la sécurité psychologique consiste aussi à prendre des risques interpersonnels comme se sentir mal à l'aise. Un espace sûr, est à mon sens, un peu différent car vous restez dans votre zone de confort sans craindre d'être challengé sur des questions ou idées. 

La confiance est une autre idée fausse de la sécurité psychologique. En fait, si nous nous faisions tous confiance, les gens seraient plus disposés à s'exprimer et à prendre des risques interpersonnels. Bien que je reconnaisse que la confiance joue un rôle important, si nous assimilons la sécurité psychologique à une autre forme de confiance, nous risquons de passer à côté de la situation dans son ensemble. La sécurité psychologique est un phénomène de groupe sur la volonté des personnes à prendre des risques interpersonnels à un moment donné. En revanche, la confiance repose sur des individus ou des groupes, c'est-à-dire la fiabilité, la vérité ou la capacité de l'autre personne ou du groupe à mener à bien une action future. La sécurité psychologique concerne l'état actuel tandis que la confiance concerne l'avenir.

À partir de cette base, le leadership sera dans une bien meilleure position pour modéliser les comportements afin de montrer comment prendre des risques interpersonnels et démontrer que les dirigeants ne puniront pas les gens pour cela. Se comporter c'est montrer sa faillibilité, c'est partager ses erreurs et encourager les autres à partager les leurs, mais aussi démontrer que le leadership n'a pas toutes les réponses et qu'il est impératif que les gens partagent ce qu'ils font et ne savent pas. 

Le leadership doit adopter trois mentalités fondamentales pour encourager la prise de risques interpersonnels. La curiosité car il y a toujours quelque chose à apprendre, de l'humilité car nous n'avons pas toutes les réponses et de l'empathie dans la mesure où la prise de risque est compliquée et doit être entretenue.

Célébrer le succès et l'échec de l'expérimentation 

Jeff Bezoes a dit un jour, “Ce n'est pas une expérience si vous savez que ça va marcher” et selon moi il atteignait un point fascinant. 

Nous pensons tous savoir comment mener des expériences et comment les gens doivent travailler. Pourtant ce n'est pas toujours le cas. Les gens croient naturellement que l'échec est mauvais et doit être évité à tout prix, mais l'échec fait partie de l'apprentissage et de la prise de risques. Une organisation doit encourager activement ses équipes à expérimenter en leur fournissant des structures qu'elles pourront adopter et adapter à leurs cas d'utilisation.

De plus, l'expérimentation doit être célébrée, comme les succès et les échecs. Les gens devraient être activement récompensés pour avoir expérimenté, échoué et partagé ce qu'ils ont appris si nous voulons que les gens évoluent vers l'inconnu, prennent des risques et créent de nouvelles façons de travailler.

L'intégration de la testabilité ressemble souvent à un problème technique. Les équipes doivent simplement trouver comment isoler leur système en modules et intégrer des tests autour de ces modules. Bien que cela soit en partie vraie, ces tests sont presque inutiles si les membres de l'équipe ne leur font pas confiance. De plus, si le leadership est absent, les membres de l'équipe s'éloigneront par défaut de la collaboration et se tourneront vers l'autoprotection. Cela peut donner l'impression que chaque personne travaille de manière isolée sur sa partie du cycle de vie du développement et que tout le monde espère ardemment qu'ils parviendront à se retrouver à la fin. 

Une façon d'établir cette confiance serait que les développeurs et les testeurs collaborent ensemble pour développer ces tests ensemble. Mais pour collaborer comme cela, le leadership doit modéliser des comportements qui montrent que les membres de l'équipe peuvent prendre des risques interpersonnels et expérimenter leurs façons de travailler.