Ponts TI

Arriver sur un projet qu'on ne connaît pas, sans avoir vécu son historique fonctionnel, et devoir écrire des cas de test — ça arrive plus souvent qu'on le pense. Pas de dossier fonctionnel à jour, pas d'historique des décisions, parfois juste le code et quelques tickets épars. Voici, humblement, ma façon d'aborder ça.

S'appuyer sur l'équipe plutôt que deviner

Le réflexe le plus utile reste de poser les bonnes questions aux bonnes personnes — surtout les développeurs qui connaissent le code, mais aussi les analystes ou les personnes déjà présentes lors des décisions passées. Deviner un comportement attendu est risqué : ça peut donner des cas de test qui valident le mauvais comportement.

Chercher la documentation existante, même incomplète

Même partielle, même désuète, la documentation qui existe donne des indices précieux : tickets fermés, anciens courriels, notes de réunion, commentaires dans le code. Ce n'est jamais suffisant en soi, mais ça réduit la part de devinette.

Être honnête sur ce qu'on sait — et ce qu'on ne sait pas encore

C'est probablement le point le plus important. Accepter la tâche ne veut pas dire prétendre qu'on a toute l'information. Je préfère le dire clairement à l'équipe : voici ce que je comprends du comportement attendu, voici les zones grises, voici ce qui manque pour être vraiment confiant dans les cas de test que je vais écrire.

Le reverse engineering, une aide, pas une solution miracle

Quand on a des connaissances en code, relire la logique existante peut aider à déduire le comportement attendu. Mais ce n'est pas toujours possible, ni suffisant : le code montre ce que le système fait, pas nécessairement ce qu'il devrait faire. Une même ligne de code peut cacher un bug qui existe depuis des années.

S'appuyer sur les outils IA, avec discipline

Les outils d'intelligence artificielle peuvent aider à générer des cas de test à partir du code existant, d'une description ou d'un ticket. C'est un bon point de départ, surtout quand on manque de repères. Mais je ne les utilise jamais en une seule passe : je procède par itérations, je reformule, je précise le contexte, et je compare ce qui ressort d'une itération à l'autre.

Le plus important reste de comprendre ce que l'IA propose, pas seulement de le copier. Un cas de test généré peut sembler cohérent alors qu'il valide un comportement qui n'a jamais été confirmé par personne. Je garde donc le même réflexe qu'avec le reverse engineering : l'IA m'aide à explorer des hypothèses plus vite, mais la validation finale reste humaine — avec l'équipe, si possible.

Parler des délais dès le départ

Le point qu'on oublie parfois : ce manque de documentation a un coût en temps, et ce coût doit être nommé avant de s'engager sur une estimation. J'accepte la tâche, mais je prends soin d'expliquer à l'équipe qu'il manque un dossier fonctionnel clair, et que ça va nécessairement rallonger le travail — le temps de comprendre s'ajoute au temps d'écrire les cas de test. Une estimation qui ignore cette lacune n'est pas réaliste, et elle finit par créer de la pression inutile plus tard dans le projet.

En résumé : s'appuyer sur l'équipe, chercher ce qui existe déjà, être transparent sur les zones d'incertitude, utiliser le reverse engineering et les outils IA comme des aides à explorer plutôt que des réponses toutes faites, et surtout intégrer ces lacunes dans l'estimation des délais plutôt que les subir en cours de route.