Contrairement à des idées reçues largement répandues, la mise en place de tests automatisés, en complément des tests manuels existants, est l’un des meilleurs moyens d’accroître l’efficacité et la couverture des tests tout en réduisant les délais et le coût global du projet !
L’idée de cet article est de revenir sur un composant essentiel dans la réussite d’un projet logiciel : l’automatisation des tests.
Le constat : Les tests… « si on a le temps »
Errare humanum est, perseverare diabolicum
L’erreur est humaine, l’entêtement [dans son erreur] est diabolique
Les développeurs sont des personnes intelligentes, douées d’une compétence technique incroyable et pouvant apporter une solution miracle à tout problème. Mais ce sont également des êtres malheureusement imparfaits et qui peuvent donc commettre des erreurs !
Et prendre des raccourcis dommageables à terme comme (exemples pris tout à fait au hasard) :
- concevoir un système figé (non évolutif) : « Il répond à la demande initiale… C’est le client qui a voulu des nouveautés, après. »
- limiter le nombre des tests manuels (cas droits, cas extrêmes, …) : « Oui, oui, j’ai testé et ça marche ! Je vous le promets ! »
- limiter la durée des phases de tests : « On est dans les temps et on est confiant ! Allez on livre ! »
- limiter la documentation : « De toute façon, je suis le seul compétent sur ce projet. Et puis c’est une perte de temps »
- ne pas revenir sur le code déjà produit : « Ça sert à quoi ? »
- modifier le code au dernier moment : « Un petit bug de dernière minute. Mais tout va bien, je l’ai corrigé et mis en ligne hein ! »
- etc, etc, etc.
Et comme le diable se cache dans les détails, même avec la meilleure volonté du monde, les erreurs ont tendance à apparaître sur des tâches répétitives, les régressions apparaissent dans le temps, etc. Bref, au fur et à mesure où le projet avance, la dette technique ne fait que grandir.
Afin de remédier à cela, des outillages de contrôle automatique sont mis en place, formant ce qu’on appelle une usine logicielle, et automatisant la vérification continue du projet : exécution automatique des compilations, exécution automatique des tests (unitaires, fonctionnels et autres), analyse qualité, etc.
Malgré cela, la base nécessaire à une utilisation efficiente d’une usine logicielle n’est pas toujours acquise. En effet, beaucoup d’entreprises ayant investi dans la mise en place d’une usine logicielle complète ne s’en servent que partiellement pour automatiser certaines tâches telles que du déploiement ou du packaging de livrable.
C’est un bon début mais il manque un petit quelque chose pour que l’on puisse vraiment parler d’ »intégration continue », à savoir la vérification automatisée en « temps-réel » du bon état de fonctionnement du logiciel en cours de réalisation. Et cette vérification ne peut se faire qu’avec une batterie de tests suffisante: tests unitaires, tests fonctionnels, tests IHM, tests de performance, etc.
Lorsqu’on évoque la mise en place de tests automatisés avec les développeurs concernés, une des premières réactions est :
« Nous avions prévu d’en réaliser sur ce projet mais, nous avons dû abandonner en cours de route (hum, dès le début du projet) pour aller plus vite et livrer le projet dans les temps ».
A chaque fois que cette réponse nous est donnée, nous ressentons la même stupeur ! Il traduit un manque de recul sur les enjeux d’un projet de développement logiciel, le manque d’une vision d’ensemble…
En creusant la question, on se rend compte qu’il y a une méconnaissance complète de ce qu’est un test automatisé et de ce qu’il peut apporter aux développeurs, au projet, et au logiciel final. Il est perçu comme une charge et donc un coût, un délai et une complexité supplémentaire !
Et non, contrairement à une idée reçue souvent évoquée, la mise en place de tests automatisés ne double pas la charge du projet !
La réalité : Les tests automatisés sont une bénédiction
Un outil de tests automatisés est capable de lire les actions pré-enregistrées et prédéfinies, comparer les résultats au comportement attendu et signaler le succès ou l’échec de ces tests. Une fois les tests automatisés créés, ils peuvent facilement être répétés (à l’infini) et ils peuvent être étendus pour effectuer des tâches impossibles avec des tests manuels (durée des tests, tests de charges, cas aux limites, multiplicité des environnements, etc).
Avec une usine logicielle et les méthodologies ad-hoc de travail associées, il est possible, tout en mettant en place des tests automatisés, non seulement de livrer le projet dans les temps (voire plus rapidement) mais également d’améliorer la fiabilité, la qualité et la maintenabilité du produit final.
Sans surcharge pour le projet : le temps « perdu » à coder des tests est « re-gagné » en réduisant la phase de recette et devient largement bénéficiaire durant la phase de maintenance !
Les bénéfices attendus de la mise en place d’un outil de tests automatisés sont de divers ordres:
D’une part pour le projet :
- La détection des régressions le plus tôt possible. Et donc diminution des coûts de retour sur le code;
- La diminution des risques fonctionnels de par l’exécution continue des tests;
- L’amélioration de la « confiance » sur le projet; La mesure de la couverture et des résultats des tests donnent de la visibilité;
- La pérennisation des « connaissances ». Facilitant notamment le transfert d’un projet logiciel à des équipes de maintenance;
D’autre part, pour les développeurs :
- Gain de maturité du développeur dans ses méthodes de travail. Permet au développeur d’être plus productif en soumettant du code testable et testé !
- Meilleure appropriation/compréhension des spécifications exprimées => Le test fonctionnel doit vérifier que le code produit répond à l’exigence;
- sans forcément aller jusqu’à développer ses tests avant le code; même si….
- Aide à la conception; Le développement des tests supposent que le développeur se pose les bonnes questions !
- Isolation/mocking des données, api, etc. La mise en place des test demandent la possibilité de lancer des tests dans un environnement fermé;
Il faut bien comprendre que les tests automatisés ne permettent pas de réaliser l’économie du passage des tests manuels. Ils viennent plutôt compléter et simplifier fortement ces efforts de tests en permettant :
- de réduire la durée des phases de validation (moins d’anomalies remontées, gravité des anomalies amoindrie, moins d’effort de correction de ces anomalies), et donc de réduire le fameux TTM “Time-To-Market”;
- d’améliorer la qualité fonctionnelle (réponse aux exigences documentées) et la fiabilité du produit final;
- de concentrer l’activité des développeurs sur du nouveau code plutôt que de revenir sans arrêt sur le code « acquitté »;
Il faut aussi souligner qu’une stratégie claire doit accompagner la mise en place des tests automatisés. Essayer de couvrir le code source à 100% peut se révéler inefficace et très coûteux. Pour atteindre un ROI maximal, il faudra mieux placer ses tests automatisés aux endroits stratégiques du code source (fonctionnalités critiques, couches logicielles intégrant l’intelligence métier, …) en fonction du contexte du projet.
Seule l’expérience et/ou un bon accompagnement permettent d’éviter les écueils de cette mise en place et d’arriver au plus vite à une organisation efficace, productive et de qualité.
En conclusion : L’automatisation des tests n’est pas une option
La réalisation de tests logiciels peut vite devenir laborieuse et fastidieuse avec des tests manuels. L’automatisation des tests permet d’effectuer ces tests de manière efficace et surtout reproductible, sans intervention humaine, et sans augmenter exponentiellement les coûts des projets.
Leur mise en place nécessite des compétences et un investissement initial, mais le retour sur investissement est très rapide. Surtout lorsqu’ils sont systématisés et uniformisés sur l’ensemble des projets de développement logiciel de l’entreprise, au travers d’une usine logicielle et de bonnes pratiques.
Les tests automatisés logiciels sont aujourd’hui une composante essentielle des projets de développement réussis !
Illustrations empruntées à :
http://dilbert.com/
http://testdroid.com/testdroid/why-to-do-automated-testing que je vous recommande de lire également.
— Fabrice
