Le logiciel de haute qualité : est-ce que ça vaut le coup ?
Voir tous les articles

Le logiciel de haute qualité : est-ce que ça vaut le coup ?

Augmenter la couverture de testsAutomatiser les testsRefactoriser en continuPrivilégier les changements incrémentauxConclusion

Quand on parle de logiciel de haute qualité, deux arguments reviennent souvent pour s’y opposer :

  1. Cela coûte plus cher à développer. Les processus, procédures et infrastructures nécessaires pour produire un logiciel de haute qualité prennent du temps. Et le temps, c’est de l’argent.
  2. Parce que cela prend plus de temps, on ne peut pas livrer de nouvelles fonctionnalités assez vite pour satisfaire les clients (internes ou externes) et rester compétitif.

Pris au pied de la lettre, ces arguments font douter de l’intérêt du développement logiciel de qualité. S’il faut dépenser plus ET perdre des clients et des parts de marché, pourquoi s’embêter ?

Mais si l’on creuse un peu et qu’on analyse vraiment les effets du développement « vite fait, mal fait » sur la durée, on se rend compte que ces arguments ne tiennent pas. Oui, on peut sortir quelques fonctionnalités très vite et gagner un peu de parts de marché. Mais les défauts et la dette technique accumulés finissent par coûter cher, réduire l’adoption et ralentir la livraison des nouveautés.

Voyons quelques pratiques clés de qualité à mettre en place et comment elles peuvent rendre le développement logiciel de qualité rentable pour votre entreprise.

Augmenter la couverture de testsAutomatiser les testsRefactoriser en continuPrivilégier les changements incrémentauxConclusion

Augmenter la couverture de tests

Plus un bug est détecté tôt, moins il coûte à corriger. Un développeur qui trouve son propre bug lors d’un test unitaire peut le corriger immédiatement. Mais un bug repéré par un client en production prend beaucoup plus de temps à résoudre : support client impliqué, développeur qui doit corriger un code qu’il n’a pas vu depuis des mois (si c’est encore le même développeur), réintégration, retest, redéploiement… Les coûts s’accumulent vite, sans parler de l’impact sur la satisfaction client.

Plus la couverture de tests est grande, plus vous détectez de défauts avant la mise en production. Atteindre 100% de couverture est difficile avec des tests fonctionnels seuls, mais les tests unitaires permettent de tester chaque fonction isolément. Même si 100% de couverture ne garantit pas un logiciel sans défaut, tendre vers cet objectif permet de détecter un maximum de bugs le plus tôt possible, ce qui réduit les coûts et améliore la qualité.

Automatiser les tests

Augmenter la couverture de tests prend du temps. Mais en automatisant les tests (ou au moins une grande partie), on accélère la détection des bugs tout en réduisant le temps global de test.

En développement piloté par les tests (TDD), par exemple, les tests unitaires automatisés sont écrits avant même le code. Dès que le code est prêt, le test s’exécute. S’il échoue, le développeur corrige et relance le test. Quand tout passe, le code est fusionné dans la branche principale et testé automatiquement avec le reste du code. En cas d’échec, le retour au développeur est immédiat.

L’automatisation rend les tests plus rapides et élimine les erreurs et biais humains, ce qui les rend plus efficaces.

Certes, il y a un coût initial à développer ces tests automatisés, mais bien conçus, ils sont réutilisables et évolutifs pour les futures versions. Il vaut mieux garder des tests petits et atomiques pour éviter de devoir maintenir de gros scripts. Cela permet aussi d’implémenter des tests par changement et/ou des tests parallèles, ce qui accélère encore les campagnes de tests.

Refactoriser en continu

Au fil du temps, à force d’ajouter des fonctionnalités et de corriger des bugs, le code devient complexe, difficile à lire et à maintenir, surtout avec plusieurs développeurs. Le refactoring consiste à améliorer le code existant pour le simplifier et le rendre plus efficace, tout en conservant sa fonction d’origine.

Pour accélérer la livraison de nouvelles fonctionnalités, il faut refactoriser régulièrement. C’est là que la qualité fait la différence.

Plus le code est complexe, plus il est difficile à faire évoluer. Ce qui semblait logique au développeur parti il y a 6 mois est un casse-tête pour le nouveau. Pour compenser, on ajoute encore de la complexité, et le problème s’aggrave.

La dette technique s’accumule et peut gravement ralentir l’évolution du logiciel.

Le refactoring continu nettoie ce code complexe, ce qui facilite la compréhension, la maintenance et l’évolution.

Privilégier les changements incrémentaux

Il est tentant de vouloir livrer de grosses fonctionnalités pour satisfaire un client ou l’équipe commerciale. Mais il vaut mieux privilégier de petits changements fréquents pour mieux contrôler la qualité et les coûts.

D’abord, cela permet d’intégrer plus de retours utilisateurs, pour une meilleure expérience. La qualité logicielle ne se résume pas au nombre de bugs : l’expérience utilisateur compte aussi beaucoup.

Ensuite, livrer de gros changements d’un coup augmente le risque de conflits et de bugs. Les petites mises à jour fréquentes facilitent les tests, la détection et la correction des problèmes.

Conclusion

Renoncer aux bonnes pratiques de développement logiciel peut sembler tentant : livrer plus de fonctionnalités rapidement, c’est séduisant. Mais les bugs, la baisse d’utilisabilité et les retards s’accumulent. À long terme, le vrai coût de la mauvaise qualité devient évident.

En appliquant les pratiques de qualité présentées ici, vous améliorerez la qualité de vos produits, réduirez les coûts de développement et de maintenance, offrirez une meilleure expérience utilisateur et livrerez plus vite… sur la durée.

Un projet en tête?