Test et Bruit
[TDD]
Clara teste le produit : son objectif est d’y rechercher des problèmes. Là où TDD et la relecture sont appliquées routinièrement, son activité à elle requiert au contraire une attention sporadique, ou thématique, puisqu’elle ne peut pas “couvrir” l’ensemble, immense, des comportements possibles. Parfois, un simple “bruit” guide son intuition.
— Tu es là depuis seulement 4 jours, et tu as déjà trouvé LE killer bug, celui allait gâcher la fête.
— Faut croire !
— Le CTO à fait reporter la M.E.P., et il a tenu à te féliciter ! C’est la première fois que je l’entends parler en bien d’une personne lui annonçant une mauvaise nouvelle.
— Arrête.
— Comment tu as fait pour trouver ce bug ?
— Au début, je ne l’ai pas reproduit. Je n’avais pas tout noté. Fermer l’appli, tu penses, c’est trivial. J’en ai parlé à Jérémie.
— Et ?
— Il est passé, et il m’a fait la démo : Je valide l’encryptage, je signe, je ferme, je rouvre. Tu vois, ça marche.
— Arhgh ! Vexant !
— J’ai cherché un peu. Quels sont les choix et les chemins possibles lors de l’encryptage avant fermeture ? Je me suis demandé pourquoi ces étapes existaient pour commencer. Pourquoi pas une simple “fermeture avec encryptage” et c’est tout ? J’en ai parlé à Maria.
— Et alors ?
— C’est toute une histoire. L’enchaînement n’était pas du tout le même initialement. Ça a été revu 3 fois en conception. Donc j’étais sur la bonne piste. J’ai fini par trouver LA combinaison d’actions qui reproduisait le plantage.
— Et tu l’as montré à Jérémie ?
— Exact. Il a dit : c’est bizarre !
— Ha ! Je le vois d’ici.
— Il a dit : c’est comme si la formule à crypter n’était plus lisible. Et du coup le programme décide de s’arrêter, en mode “je travaille pas sur des données frelatées”.
— Je lui ai dit : si ça se trouve, la formule est frelatée. Il m’a répondu : bien sûr que non ! Elle est fournie par le composant CygnaTrack. Ça ne peut pas être ça.
— Ça se serait le comble en effet.
— C’était ça. Je lui ai demandé s’il y avait un moyen d’examiner la zone en mémoire.
— C’est ce qu’il a fait ?
— Il a d’abord râlé, puis il a modifié son code pour enregistrer l’objet dans un fichier binaire. Ça lui a pris 15 minutes, à tout casser.
— Et alors ?
— On a regardé. DEADBEEF !
— Quoi, dead beef ?
— Dans le “dump” en hexadecimal: toute la zone remplie d’octets D, E, A, D, B, E, E, F, D, E, A…
— Qu’est-ce que ça veut dire ?!
— C’est une histoire que m’a raconté mon père. En programmation système dans le temps, on remplissait les zones de mémoire devenues inutiles avec ce motif avant de les libérer. Au debug, si tu vois DEADBEEF, c’est que ton code utilise une zone qu’il ne devrait pas.
— Mais pourquoi le code de Jérémie ferait ça ?
— Tu ne comprends pas : ce n’est pas le code de Jérémie, c’est CygnaTrack qui fait ça.
— Quoi ?
— Le système CygnaTrack est buggué. Ils réutilisent des objets qui ont été désalloués. Une chance qu’ils le tracent. On gagne du temps.
— À quoi ça tient !
Stay Tuned!