Comment assurer la non régression fonctionnelle lors d’une migration technique ?

Fini le weekend, les soirées arrosées, les grasses matinées, et les fantasmes futuristes que l’inventeur de SixthSence a fait naître dans ma tête. De retour à la réalité du lundi matin, et au projet qui m’attend : organiser le redéveloppement d’un de nos logiciels écrit en Java/JSP vers une architecture ou la partie serveur sera en J2EE (Hibernate, Spring, etc.) et la partie cliente en technologie Adobe Flex.

Pour rendre le projet plus intéressant, ajoutons que nous n’avons ni spécification fonctionnelle, ni documentation utilisateur, que les plans de tests sont pauvres, qu’il n’existe aucun script de test automatique, et qu’accessoirement, je suis loin d’être un expert du monde Java et je découvre le Flex ! La première pensée qui me vient à l’esprit est… vivement vendredi soir !

A vrai dire, les aspects techniques ne me font pas vraiment peur. L’équipe de développement tient la route, et elle produira les tests unitaires ! Ce qui me cause souci, c’est la qualification fonctionnelle et les risques de régressions. Comment les éviter ?

La matrice de compatibilité va me dicter une partie de la réponse. Notre logiciel doit pouvoir tourner sur 3 SGBD, 3 serveurs d’applications, Windows, Linux, et le plus grand nombre possible de navigateurs Internet. Bien entendu, j’échapperai à certaines combinaisons, genre SQL Server sous RedHat :-), mais tout de même, cela fait quelques dizaines de possibilités à explorer. Dans ces conditions, il n’y a qu’un seul moyen d’être exhaustif, c’est de passer par des outils d’automatisation des tests.

Concernant la qualification fonctionnelle, tout reste encore à construire. Comme je l’ai dit précédemment, l’application historique n’est pas accompagnée de spécifications fonctionnelles qui soient utilisables. Une option pourrait être d’entamer une phase de rétro-ingénierie visant à produire des spécifications, puis à implémenter selon ces spécifications et enfin à tester pour vérifier la conformité des développements. Mais avec ce système, toute erreur introduite durant la tâche rétro-ingénierie se transforme en régression dans l’application finale. Pire encore, les bugs de l’application historique seraient transposés dans l’application cible ! Ce n’est donc pas satisfaisant.

Pourtant, ce que je veux faire est simple : il faut que la même utilisation produise le même résultat dans les deux applications. Et si pour une fois la solution était aussi simple ? Produire des scénarii de tests, les dérouler sur les deux applications, et comparer les résultats : s’ils sont identiques, tout va bien ; s’ils sont différents, alors il faut regarder pour comprendre de quel côté est le bug, et corriger si besoin.

Il ne me reste plus qu’à me mettre en quête des outils adaptés, mais ça attendra demain!

Le futur a déjà commencé

Pranav Mistry est l'inventeur de SixthSense, un équipement qui permet des interactions entre le monde des données et le monde réel. Sa vidéo de présentation est tellement époustouflante que j'ai du la regarder 3 fois de suite.
Avec des tels génies, on peut se dire que le futur a déjà commencé, et c'est tant mieux !