Skip to main content

Le monde est rempli de logiciels qui respectent parfaitement toutes leurs exigences documentées, mais qui échouent malgré tout à créer de la valeur pour leurs utilisateurs.

Lorsque j’ai étudié l’ingénierie logicielle – il y a bien longtemps – la qualité signifiait conformité, c’est-à-dire conformité aux exigences. J’ai également appris que l’assurance qualité désigne l’ensemble des mesures prises pour permettre, créer et vérifier la qualité, et que les tests sont une méthode clé de l’assurance qualité. 

Aujourd’hui, Wikipédia définit le test comme l’action d’examiner les artefacts et le comportement du logiciel testé par validation et vérification. Le test y est défini comme une activité, sans en préciser l’objectif. Les définitions que j’ai apprises à l’école d’ingénierie sont très compatibles avec la définition Wikipédia du test de conformité : un test qui détermine si un processus, un produit ou un service respecte les exigences d’une spécification, d’une norme technique, d’un contrat ou d’un règlement. Fait curieux, aucune de ces définitions n’utilise le mot qualité

Qu’est-ce que la qualité ?

Aujourd’hui, j’évite de définir la qualité sauf de façon indirecte, à travers quatre dimensions : bénéfices, fonctions, processus et expérience. Prenons l’exemple de quelque chose que tout le monde connaît, disons Paypal. On l’utilise pour transférer de l’argent en ligne : c’est sa fonction. Les bénéfices recherchés sont la simplicité, la sécurité et le faible coût. Utiliser PayPal consiste en différents processus utilisateur, guidés par le logiciel. Les émotions, telles que la satisfaction, la frustration ou l’accomplissement, ressenties par l’utilisateur durant l’utilisation de Paypal, forment l’expérience. Quelle que soit la définition de la qualité, il ne saurait y en avoir sans ces quatre dimensions.

Les tests se concentrent généralement sur la conformité fonctionnelle, c’est-à-dire vérifier que le logiciel fait bien ce que ses exigences stipulent et rien d’autre. Il peut aussi y avoir des exigences non fonctionnelles, comme les temps de réponse, le nombre de transactions parallèles supportées, ou la sécurité des données utilisateur. Les normes et réglementations, telles que SOC2 ou RGPD, ajoutent des exigences supplémentaires, tout comme les accords de Paypal avec les sociétés de cartes de crédit. Celles-ci ont parfois peu à voir avec les fonctions réelles et la valeur du logiciel, mais s’y conformer est une condition préalable pour pouvoir exercer l’activité. 

La qualité va au-delà de la simple conformité. Pour atteindre les deux, consultez notre liste soigneusement sélectionnée des meilleures plateformes de test logiciel

Le monde idéal

Les excellents testeurs adoptent à la fois une vision basée sur la conformité, axée sur la satisfaction des exigences, et une vision orientée résultats, axée sur la concrétisation des bénéfices. Dans un monde idéal, satisfaire les exigences documentées impliquerait la réalisation des bénéfices pour l’utilisateur, mais le monde est rarement idéal. Même si le logiciel était parfait, les utilisateurs ne le sont pas. La concrétisation des bénéfices dépend largement des actions de l’utilisateur, et ces actions dépendent de la façon dont le logiciel interagit et guide l’utilisateur. Cela influe sur la qualité de l’ensemble de l’expérience. Ces caractéristiques du logiciel ne peuvent guère être saisies par des exigences de conformité ou des cas de test formels. Encore une fois, dans un monde idéal, tous ces défis seraient résolus suffisamment tôt par une conception centrée utilisateur – mais le monde est loin d’être idéal, et le testeur doit jouer le rôle du véritable utilisateur.

Tests de conformité vs. tests orientés résultats

Les tests de conformité et les tests orientés résultats nécessitent des états d’esprit différents. Le test de conformité, c’est comme tendre des pièges : lire les exigences, imaginer ce qui pourrait mal se passer, et concevoir des conditions de test dans lesquelles le logiciel risque d’échouer. Le test orienté résultats s’apparente davantage à un acte de curiosité : comprendre ce que l’utilisateur doit accomplir, imaginer toutes les choses qu’il pourrait faire, déterminer comment le logiciel devrait réagir, puis essayer. 

La conformité est un prérequis à la qualité. Dans de nombreux secteurs, répondre aux exigences formelles de conformité est même un préalable à la participation à l’activité. On peut aussi atténuer les risques de responsabilité en produisant une preuve documentée que la conformité a été rigoureusement testée. J’ai tendance à penser que les tests de conformité contribuent à réduire le risque d’échec tandis que les tests orientés résultats aident à améliorer la probabilité de succès.