Éditeur de logiciels : l’importance de rendre les tests automatiques

Aujourd’hui, une grande partie (voir tous) des éditeurs de logiciels axent leur développement en web to services et délaissent une version physique de leur logiciel. Mais ce « legacy » a été élaboré avec des fonctionnalités du logiciel orientées en fonction des besoins de plusieurs clients (en développant du « spécifique »), ce qui amène à gérer des versions quasiment personnalisées.

La base est commune mais certaines fonctionnalités sont propres à chaque client. Et orienter son produit par les besoins spécifiques d’un premier gros contrat est un jeu dangereux qui, à terme, peut conduire à avoir en production des versions « instables » et dont les maintenances deviennent ingérables.

Pour garantir la fiabilité du logiciel il faudrait passer par une automatisation des tests de non régression mais, dans un cas de figure comme présenté ci-dessus, c’est mission impossible ! Alors, quelle est la solution pour automatiser ses tests de non régression ?

On retrouve des situations ou des éditeurs n’ont plus une seule version implémentée, mais « autant » de versions que de clients.

Il devient presque impossible de procéder à l’automatisation des tests de non régression car il va falloir configurer les tests pour chacune des versions présentes et ce à chaque mise en production :

• Plusieurs cartographies,
• Différents environnements,
• Multiplicité des jeux de données …

Pour résumer : un cauchemar.

Mais on peut imaginer que, dans le cadre de la croissance de l’éditeur, il décide de mettre en œuvre une version unique en mode SaaS multi-tenant et « d’imposer/proposer » cette dernière à tous ses clients. Cela lui permet de s’affranchir définitivement des versions en production qui nécessitent des tests de non régression non automatisables, donc exécutés manuellement ou semi-manuellement.

Bien entendu, cette mise en œuvre passe par une planification, une validation du projet par les clients, avec la mise en avant des avantages : plus de réactivité, bénéficier d’un catalogue de fonctionnalité plus large, un coût moindre, plus de TMA, …

Cette refonte du logiciel doit intégrer l’automatisation des tests de non régression pour permettre :

1. D’aboutir à une version unique de qualité (on notera que si la version exécutable est unique, l’infrastructure utilisé par le client ne sera pas forcément la même).
2. Une version la plus fiable possible.
3. De se servir du patrimoine de tests pour incrémenter les tâches automatisées avant chacune des mises en production.

Le premier bénéfice de cette refonte et de l’automatisation des tests, c’est un coût de maintenance et de tests qui s’effondre, tout en gagnant en réactivité.

Pour conclure.

Pour les éditeurs de logiciel la migration vers une solution « SaaS » devient quasi obligatoire, dans la majeure partie des cas. Ne pas profiter de ce projet stratégique pour y coupler le projet d’automatisation des tests de non régression serait une erreur fondamentale. En effet, c’est le moment idéal et le moins risqué pour le faire. Si vous ne le faites pas dans ce contexte dites-vous que vous ne le ferez jamais !

Pour assurer la fiabilité de vos applicatifs et satisfaire vos clients, le taux de dysfonctionnement doit tendre vers 0. Et on ne l’expliquera jamais assez, mais il n’y a que l’automatisation pour arriver à de tels résultats.