Comment faire évoluer un logiciel sans casser ce qui fonctionnait hier ?

Une nouvelle fonctionnalité arrive. Cool !

Mais est-ce que le planning fonctionne toujours ? Les calculs de facturation sont-ils toujours justes ? Peut-on encore créer un client et lui associer son animal ?

Dans notre dernier #PointTech, nous avons expliqué le parcours d’une version avant son déploiement. À l’entrée de cette chaîne : les tests automatisés. Mais que vérifient-ils vraiment ?

D’abord, vérifier les détails qui comptent.

Prenons une ligne de facturation : une quantité, un prix, une remise, une TVA.

Nous vérifions les résultats attendus, mais aussi les cas moins évidents : une quantité fractionnée, un arrondi, une remise de 100 %, ou des montants incohérents qui doivent être refusés.

Ce sont les tests unitaires : ils isolent une règle précise et vérifient qu’elle produit le résultat attendu. Pas approximativement.

Ensuite, vérifier que les composants travaillent ensemble.

Une règle peut fonctionner seule et poser problème lorsqu’elle échange avec le reste du logiciel.

C'est le rôle de nos tests d’intégration : nous recréons dans des conteneurs isolés un véritable environnement VetCoreSolution®, avec les mêmes composants serveurs, de véritables bases de données et des données de test.

Nous vérifions alors le fonctionnement de cet ensemble. Nous mesurons aussi certaines opérations sur des volumes représentant des années d'usage du logiciel, notamment le chargement des rendez-vous, des clients, des animaux ou des historiques de consultations.

Parce qu’un logiciel utilisé dans une clinique vide ne raconte pas la même histoire qu'avec 15 ans d’activité.

Puis, utiliser le logiciel comme dans une clinique.

• Un navigateur automatisé ouvre l’interface.
• Il crée des clients.
• Il leur associe des animaux.
• Il prend des rendez-vous.
• Et il vérifie que ces rendez-vous apparaissent bien dans le planning, pour les bons clients.

Ce sont les tests de bout en bout : on ne vérifie plus seulement une fonction ou un échange entre serveurs, mais un parcours complet dans le logiciel.

Et quand tout ne se passe pas comme prévu ?

Nous simulons aussi volontairement des échecs, par exemple une erreur du serveur lors de la création d’un animal.

Un logiciel doit fonctionner quand tout va bien. Mais sa réaction lorsqu’une opération échoue mérite, elle aussi, d’être testée.

L’enjeu : ne pas repartir de zéro à chaque modification.

Nous conservons également des scénarios qui reproduisent des bugs déjà rencontrés. Ils permettent de vérifier qu’une évolution ne réintroduit pas un problème corrigé auparavant : on parle alors de tests de non-régression.

Ces contrôles s’inscrivent dans la chaîne présentée au précédent épisode : les modifications déclenchent automatiquement des tests, et un contrôle en échec bloque leur intégration au code principal.

Est-ce que cela garantit un logiciel sans aucun bug ? Non.

Un test vérifie un scénario prévu. Il ne peut pas anticiper toutes les situations, ni remplacer la validation métier et les retours du terrain.

Mais l’objectif n’est pas seulement de vérifier que la nouvelle fonctionnalité marche.

#PointTech #VetCoreSolution #QualitéLogicielle #TestsAutomatisés #ArchitectureLogicielle #VetTech #LogicielVétérinaire