16 décembre 2020
Par Jean-François Riverin, cofondateur
Zentelia, firme de génie logicielle et expert en assurance qualité logicielle
Mon intention première était de vous présenter une définition technique des tests, avec l’objectif avoué de vous convaincre de leur nécessité dans les systèmes logiciels. Je voulais partir de leur définition littéraire tout en vous expliquant leur place dans l’assurance qualité. Mais quelque chose me retenait, je trouvais ça trop… théorique, trop cérébral.
Tester, c’est naturel
Je me suis donc demandé si cette notion de test ne pouvait pas se retrouver dans la vie de tous les jours. En observant le monde qui m’entoure, je me suis mis à trouver des tests partout, de façon naturelle. Chaque fois que l’on doute ou que l’on veut vérifier une hypothèse, on teste; parfois même sans y penser. Lorsque l’on écrit un texte comme celui-ci, on en fait une relecture et on le fait lire à quelqu’un d’autre. Pour savoir comment se vêtir, on vérifie la température. De même, avant une soirée importante on s’assure de notre habillement, on essaie diverses combinaisons. Avant d’embaucher, on passe des candidats en entrevue. Lorsque l’on conçoit quelque chose de nouveau, quelque chose que l’on n’a jamais fait, on le vérifie. Tester, c’est ce qu’on fait pour se rassurer de nos choix lorsque l’on doute et tout le monde le fait, même les animaux! Le test est tout simplement indissociable de toute évolution, de tout processus créatif!
Tester pour protéger la vie, c’est évident
D’accord, dans notre vie nous testons de façon intuitive, mais est-ce représentatif de ce que l’on trouve dans un monde industriel? Après tout, les grands fabricants de ce monde, du domaine des transports ou de la pharmaceutique par exemple, n’embauchent-ils pas les meilleurs ingénieurs? Dans ce cas, ces grandes entreprises ont-elles aussi besoin de faire des tests?
Pensons-y, un peu. Embarquerions-nous dans un avion n’ayant jamais été testé? Prendrions-nous tel médicament n’ayant jamais été éprouvé? Voudrions-nous des logiciels dans nos ordinateurs, nos voitures, nos cellulaires ou nos appareils domestiques sans qu’ils aient été testés? La réponse est bien sûr, non, presque jamais. Pourquoi? Parce que la plupart du temps, il y a trop de risques et que c’est trop dangereux!
Tester pour réduire les risques de façon générale
Et si les tests servaient justement à réduire le risque? Quels genres de risque voulons-nous éviter? Comme client, nous ne voulons pas perdre notre temps ni risquer des pertes financières importantes. Les risques sur notre santé et notre sécurité sont eux aussi habituellement inacceptables. Les fabricants ont également une limite de tolérance envers le risque. Ils veulent éviter de déplaire à leurs clients, de nuire à leur réputation et ils veulent éviter des pertes financières importantes.
Quand tester durant le processus de fabrication
Quelle est donc la meilleure façon d’utiliser les tests pour réduire les risques? Serait-ce d’ajouter des tests avant la mise en production afin de vérifier si le client est heureux du produit? Si ce ne sont que les seuls tests qui sont faits, personnellement, je ne voudrais pas être le premier dans l’avion! J’aimerais qu’il y ait quelqu’un d’autre qui passe avant moi; un pilote d’essai peut-être? Avant de risquer la vie de ce téméraire, l’idée de construire un simulateur pour tester le système de façon sécuritaire serait une bonne étape préalable. Cela permet alors de tester un grand nombre d’hypothèses, parfois très difficiles à reproduire dans l’environnement réel.
Cependant, le simulateur, bien qu’excellent, a un coût et ne permet pas de vérifier les défauts des composantes. On devra s’assurer de la fonctionnalité de chacune des composantes entrant dans la conception de notre produit en les vérifiant individuellement. Par exemple, le système de propulsion, le système de freinage, le système de direction sont des composantes critiques devant être vérifiées bien avant le premier vol! Mais on peut faire mieux. Chacun de ces systèmes (composantes) est constitué de pièces spécifiques assemblées selon un plan précis. Pour chaque pièce il a fallu en spécifier le matériel, la taille, la forme, la résistance, etc., afin qu’une fois assemblées, elles fonctionnent ensemble sans défaillances unitaires (individuelles).
Un boulon = un bout de code
Pour le monde du logiciel, n’est-ce pas, « virtuellement » les mêmes enjeux? L’univers du développement logiciel est certes beaucoup plus proche de la conception et du design que de la production industrielle proprement dite. Mais, justement, comme les tests sont indissociables de tout processus créatif et que chaque besoin génère une idée unique nous amenant à créer de nouvelles solutions informatiques, plus tôt nous validons (testons), mieux nous gérons nos risques.
C’est pourquoi chaque bout de code, tout comme chacune des pièces d’un avion, doit être testé unitairement afin d’assurer sa qualité. Ce bout de code fait partie d’une fonction; fonction pouvant être, par exemple, un système de calcul de taux. Cette fonction sera elle-même testée afin de s’assurer qu’elle exécute les résultats attendus, tel notre système de navigation. Cette fonction est ensuite intégrée dans un système plus vaste. Elle est liée à d’autres composantes comme une base de données ou encore une interface permettant la saisie des valeurs d’entrées. Une fois toutes les composantes intégrées dans une solution complète, celle-ci évoluera dans un environnement connecté à des systèmes externes fournissant des services permettant de l’alimenter, par exemple, à un service d’authentification. Enfin, une fois tous les systèmes intégrés, le produit doit encore passer un ultime test, celui de l’utilisateur. Ce n’est qu’après toutes ces étapes que nous avons enfin un nouveau produit prêt à être mis en service.
Le plus tôt sera le mieux
Ainsi, la prochaine fois qu’on vous demandera à quoi cela sert de tester tôt, puisque le système n’est pas terminé, vous pourrez répondre que cela sert justement à réduire le risque. Plus on attend, plus on prend de risques et plus l’enjeu est grand, plus on devrait tester tôt! C’est paradoxal, car très souvent, ce sont dans les projets importants que l’on teste le plus tard sous prétexte qu’il n’y a PAS DE TEMPS À PERDRE. Dorénavant, n’hésitez plus à répondre à ces arguments qu’il n’y a surtout pas de RISQUES À PRENDRE et j’ajouterais un « alors quand est-ce qu’on commence à tester qu’on le finisse ce projet! ».
Ce texte a d’abord été publié le 10 décembre dans un journal interne sur l’assurance qualité chez Desjardins Groupe d’assurances générales.
Pour plus d’information sur l’ensemble de nos services, entrez en communication avec l’un de nos experts.
Comments