Hier encore, un logiciel était constitué de quelques milliers de lignes de code. Aujourd’hui, ces applications en nécessitent la plupart du temps plusieurs millions, ce qui entraîne une quantité plus importante d’erreurs de programmation.
Une étude menée en 2013 par l’université de Cambridge évaluait le coût des bugs informatiques à 312 milliards de dollars par an. Une somme colossale qui pourrait être réduite considérablement si l’industrie informatique améliorait ses techniques de test.
Tout prestataire amené à créer des logiciels pour ses clients doit veiller en permanence à leur qualité et, pour y parvenir, mettre en place un processus de test rigoureux. Dans le domaine du cloud, ces préoccupations sont d’autant plus centrales que le client a toujours besoin d’un logiciel pour accéder à ses données – stockées sur un serveur. Il est donc primordial de s’assurer de la fiabilité et de la qualité de celui-ci.
La phase de tests est toujours une étape délicate. Elle implique deux contrôles distincts :
- D’une part, il faut tester le logiciel lui-même afin d’écarter tout risque de dysfonctionnement ;
- D’autre part, il faut vérifier que le logiciel créé est conforme aux spécifications demandées dans le cahier des charges initial. Pour ce faire, on contrôle à la fois les aspects techniques (« recette technique ») et les aspects fonctionnels (« recette fonctionnelle »).
Il s’agit, in fine, de s’assurer que le contrat a bien été respecté et que le produit fini répond parfaitement aux demandes exprimées. La planification de la phase de tests commence tôt dans le cycle de vie du développement logiciel.
Des tests ? D’accord ! Mais… ils coûtent combien ?
Force est d’admettre que les tests sont coûteux tant en termes d’argent qu’en termes de temps, des coûts qui varient beaucoup d’un projet à l’autre. Selon la complexité des tests à mener, cette étape peut représenter à elle seule de 30 à 40% des coûts de développement d’un logiciel et occuper un tiers du temps total dévolu au projet. Cependant, l’investissement n’a rien de superflu : plus une anomalie est découverte tardivement, plus elle est coûteuse à corriger, d’où l’intérêt de commencer la phase de tests de manière précoce. Toutes les méthodes de gestion de projet ne le permettent pas.
Dans certaines d’entre elles, comme le modèle Cycle en V, la vérification du logiciel et la validation de sa conformité s’effectuent seulement une fois le logiciel créé. Le temps dont on dispose pour effectuer des tests et corriger les éventuelles anomalies détectées est donc limité car il dépend de la durée restant avant la date de livraison du produit fini au client.
A l’inverse, d’autres méthodes d’organisation du travail comme la méthode Agile en vigueur chez Oodrive permettent de démarrer les tests fonctionnels beaucoup plus tôt dans le déroulement du projet. On peut commencer à concevoir les tests dès que l’on connaît les fonctionnalités demandées et lancer la phase de tests proprement dite dès qu’une version exécutable de l’application est disponible. La validation, quant à elle, n’intervient qu’à la toute fin du cycle dans la mesure où elle a valeur de contrat.
Un bug identifié au moment de la livraison du logiciel au client coûterait jusqu’à 45 fois plus cher à corriger qu’un dysfonctionnement détecté au tout début de la phase de développement, ce qui confirme la grande valeur ajoutée de ces méthodes de travail.
Malgré cet argument économique de poids, le test a encore trop souvent mauvaise réputation. Un désamour qui s’explique par plusieurs raisons :
- Les testeurs étant les derniers à intervenir dans la chaîne de développement du logiciel, ils sont tributaires des retards accumulés durant les étapes précédentes du projet. Lorsqu’ils découvrent des anomalies, ils sont souvent jugés responsables de ces retards.
- Le rôle du testeur étant de mettre en évidence les bugs d’un logiciel, il implique forcément de porter un regard critique sur le travail effectué par les développeurs, un exercice de diplomatie délicat !
En dépit de ces écueils, on peut dire que les tests sont essentiels au processus de développement informatique. Les utilisateurs finaux seront intransigeants face aux bugs et il ne fait aucun doute qu’un système qui ne fonctionne pas sera balayé du revers de la main !
