Comment l'indépendance des tests aurait pu sauver l’Etoile Noire

J'ai eu l'occasion de réfléchir et d’appréhender l'importance de l'indépendance des tests logiciels… en sortant d'une salle de cinéma où je venais de voir Rogue One, le petit dernier de l’univers Star Wars.

L'indépendance des tests est une des premières notions qu’on m’a enseignée lors de ma formation aux tests logiciels. Cela consiste à dire que le test est plus efficace s'il est effectué indépendamment du développement. Je l'ai apprise par cœur, sans vraiment la remettre en cause ou en comprendre tous les enjeux. Cela semblait simplement évident. C'est toutefois dans un contexte complètement différent que j'ai eu l'occasion de réfléchir et d’appréhender l'importance de l'indépendance des tests… en sortant d'une salle de cinéma où je venais de voir Rogue One, le petit dernier de l’univers Star Wars. 

Rappelez-vous. Le tout premier épisode de la célèbre saga cinématographique s'ouvrait sur la princesse Leia confiant à un droïde les plans de l’Etoile Noire, tout juste dérobés à l'Empire. Grâce à ces derniers, Luke Skywalker serait en mesure de détruire la terrible arme de destruction massive en exploitant une faille critique. 

Jusqu'ici, je supposais que des ingénieurs sous pression et une organisation pas très efficace pouvait être à l'origine de cet échec du camp impérial. Après tout, une armée qui embauche des soldats d’élite qui tirent toujours à 50 cm de leur cible, c’est forcément qu’il y a des problèmes d’organisation et de ressources humaines. Le film Rogue One nous a présenté une toute autre version de l'histoire. Sans s’étendre sur les détails, on découvre que la faille a été sciemment conçue afin d'offrir à la rébellion la possibilité de faire exploser l'arme. C'est un sabotage réalisé par l’architecte en charge de ce projet. Donc, la principale erreur de l'Empire a été de faire entièrement confiance à leur équipe et de ne pas avoir vérifié les plans dans les moindres détails… Je pense que vous commencez à voir où je veux en venir. Si une équipe de testeurs entièrement indépendante avait été mandatée pour vérifier les plans de la station spatiale, il est fort probable que cette faille aurait été découverte bien plus tôt ! 

On se remet dans le contexte. Le projet dure depuis des années et les scientifiques qui travaillent dessus vivent reclus sur une planète isolée, dans un laboratoire secret. Pour conserver la confidentialité du projet, ce sont les mêmes ingénieurs qui conçoivent l’arme et qui la teste. Ils subissent une grande pression et ils n’ont probablement pas l’occasion d’aller prendre l’air sur d’autres planètes. Au fil du temps, il serait étonnant que les liens qui se sont noués entre les collègues n'aient pas d'influence sur leur travail. Il deviendrait alors de plus en plus difficile de remettre en question les choix de leur supérieur. Ce supérieur qu’on présente comme un génie, qui sait se rendre indispensable et semble faire un travail impeccable. 

Je ne trouve pas tout à fait absurde d'imaginer la discussion suivante, un jour, entre deux ingénieurs de l’Empire : 

“- Tiens, tu as vu que le boss a installé un conduit entre le cœur du réacteur et la surface de la station ? On n’aura pas intérêt à y faire tomber son gobelet de coca ! Ahah !
- Le connaissant, il a tout prévu en cas de surchauffe du réacteur. Ou quelque chose du genre.
- Ouais, tu as raison, il laisse rien au hasard… tiens mais ce serait pas l'heure d'aller manger ?
- Ah oui, en plus il y a des frites à la cantine ce midi. “

Sur un projet aussi critique pour l’Empire, le choix le plus judicieux aurait été de nommer une équipe indépendante, régulièrement renouvelée, et de lui confier la tâche de vérifier au fur et à mesure de l'avancement qu’aucune anomalie ne pourrait mettre en péril la stabilité de l’Etoile noire. Je ne vois pas comment de bons testeurs auraient pu ne pas remarquer la faille. Même si l’anomalie n'avait pas été considérée comme un risque et qu'elle n’avait pas été corrigée, rien que le fait d'avoir identifié son existence, de l'avoir remise en question et de l'avoir documentée aurait permis de se protéger de l'attaque des rebelles. Un processus de test rigoureux, documenté, aurait pu empêcher le sabotage et sauver l’Etoile noire.

Entendons-nous bien : je ne dis pas que les tests n'auraient pas été bien réalisés. Il est clair que l’Empire a embauché des professionnels qualifiés (de gré ou de force, d'ailleurs, ce qui est un autre problème). Simplement que la complaisance, l'habitude et le fait de travailler en cercle fermé n’ont pas rendu le travail des testeurs très efficace. 

Bien sûr, dans le contexte de cette saga de science-fiction, le spectateur est ravi que cette erreur se soit produite : c'est grâce à elle que la Rébellion remporte une victoire décisive ! C’est bien fait pour les méchants ! Mais dans la vraie vie, n'importe quelle application critique nécessite un certain recul de la part de l'équipe de test, pour éviter de telles négligences. Imaginez ce même scénario plaqué sur un contexte bien plus terre à terre d'une application financière ou de santé ! Ce serait la catastrophe. 

Travaillant moi-même dans une petite équipe en mode Agile, je peux facilement imaginer comment ce genre d'anomalie passerait inaperçu. Il est très difficile de prendre des distances avec une équipe de développement au sein de laquelle les relations sont presque fusionnelles. Il est si facile de se laisser convaincre que non, ce n'est pas un bug, il faut faire confiance au développeur, il sait ce qu'il fait, ça n'arrivera jamais en production. 

Je crois que justement, notre travail, en tant que testeur, c'est de ne jamais faire confiance aux développeurs. La persévérance, la remise en question doivent être permanentes. Et même si ce n'est pas à nous d'avoir le dernier mot, même si le point soulevé est considéré comme négligeable ou peu critique, le plus important c'est de toujours documenter ses doutes. Parce qu'on ne sait jamais si un jour, on n'aurait pas besoin de retrouver en urgence une toute petite faille insignifiante qui pourrait être exploitée par des personnes mal intentionnées. Bref, le test doit être indépendant du développement. 

Si je ne m'étais jamais véritablement penchée sur le sujet auparavant, je sais désormais que chaque fois que je serai tentée de penser “oh, ce n’est peut-être pas un bug” au moment de rapporter une anomalie mineure, je n'aurais qu'à penser au sort tragique de l’Etoile noire. Et la prochaine fois que lors d’une réunion sur un projet sensible, un participant dira “on peut tester ça nous-mêmes”, il serait de bon ton que quelqu’un se serve de cet exemple explosif pour lui remettre les idées en place.