Leadership dans le test : Combien de tests sont suffisants ?
Note de l’éditeur : Bienvenue dans la série Leadership en Test, présentée par l’expert et consultant en tests logiciels Paul Gerrard. Cette série est conçue pour aider les testeurs disposant de quelques années d’expérience—en particulier ceux qui travaillent en équipe agile—à exceller dans leurs rôles de responsables et de gestionnaires de tests.
Dans l’article précédent, nous avons dressé un manifeste du risque afin d’aider les managers. Dans cet article, nous allons aborder la question classique et intemporelle : « Combien de tests sont suffisants ? ». Spoiler : la réponse appartient aux parties prenantes.
Inscrivez-vous à la newsletter The QA Lead pour être informé lorsque de nouveaux articles de la série sont publiés. Ces articles sont extraits du cours Leadership en Test de Paul, que nous vous recommandons fortement pour approfondir ce sujet et bien d’autres. Si vous vous inscrivez, utilisez notre code promo exclusif QALEADOFFER pour bénéficier de 60 $ de réduction sur le prix total du cours !
Combien de tests sont suffisants ? C’est la question philosophique classique, sans réponse définitive, que tous les testeurs se posent parce que leurs parties prenantes la leur posent également.
Les parties prenantes veulent le savoir car elles veulent s’assurer que les systèmes ont été correctement testés mais, puisqu’elles financent les tests et ont des échéances à respecter, elles souhaitent aussi connaître le coût potentiel des tests et leur durée.
Ainsi, c’est aux parties prenantes de juger combien de tests sont suffisants. Votre rôle, en tant que responsable des tests, est de leur apporter un maximum de valeur en les aidant dans leur prise de décision. Dans cet article, nous aborderons :
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
- La valeur des tests pour les parties prenantes
- La théorie quantique et la théorie de la relativité (pas la physique)
- Utiliser le bon langage
- Estimations, budgets et négociation
Commençons.
La valeur des tests pour les parties prenantes
Chaque test que nous réalisons doit avoir de la valeur pour les parties prenantes, car il fournit des preuves qui soutiennent leur prise de décision de quatre manières :
- Des preuves que le système atteindra les objectifs métiers du projet.
- Des preuves que le système ne plantera pas, ou si cela se produit, que l’impact d’une défaillance est tolérable.
- Des preuves permettant de reproduire, diagnostiquer, corriger et re-tester le système en cas d’échec.
- Des preuves pour appuyer les prises de décision dans le contexte d’un projet (accepter, livrer, rejeter, etc.)
Notre objectif, lors des tests, est de créer des tests qui augmentent progressivement la couverture du système par rapport à un modèle de test reconnaissable. Nos tests doivent démontrer que le système répondra aux objectifs métiers et que les risques de défaillance sont connus et, espérons-le, acceptables.
Parmi les quatre types de preuves ci-dessus, les trois premières soutiennent la quatrième. Au final, les parties prenantes doivent prendre une décision fondée sur les preuves. C’est à elles, et non aux testeurs, de juger si elles disposent d’assez d’informations pour être confiantes. De toute façon, la valeur des tests se juge du point de vue des parties prenantes.
À présent, chaque testeur fait des choix sur ce qu’il va tester en se basant sur un modèle formel ou même à l’instinct. Ces choix sont fondés sur une certaine valeur perçue.
Sauf si le testeur est aussi une partie prenante, il juge généralement la valeur en fonction d’un certain degré d’exhaustivité ou de couverture. Ou, s’il connaît l’état d’esprit des parties prenantes, selon la capacité du test à servir un choix d’acceptation.
Les principes ci-dessus ont d’importantes conséquences.
Premièrement, si vous ne connaissez pas l’état d’esprit des parties prenantes, votre perception de la valeur des tests a peu de chances de correspondre à la leur. Si vous sélectionnez vos tests sans tenir compte de leurs critères, alors, au moment de présenter vos résultats, vos parties prenantes pourraient constater qu’elles disposent de trop peu de données pour certains aspects et trop d’informations pour d’autres. Elles ne se sentiront certainement pas aussi confiantes qu’elles le devraient.
Deuxièmement, lorsque vous concevez ou exécutez un test, quelle est sa contribution à la prise de décision des parties prenantes ? Si un test n’apporte pas d’information complémentaire facilitant une décision, ou si les parties prenantes se moquent que votre test soit réussi ou échoué, alors ce test n’a pas sa place dans un plan de test.
Nous avons dit dans l’article 3 sur les modèles que les modèles de test que vous utilisez doivent être pertinents pour les parties prenantes. Si vos résultats de tests correspondent à des modèles que les parties prenantes comprennent et jugent utiles, alors elles accorderont de la valeur à votre contribution.
La théorie quantique et la théorie de la relativité
Il existe deux autres principes concernant la valeur et la signification des tests. J’appelle l’un la théorie quantique et l’autre la théorie de la relativité. Ces intitulés paraissent pompeux (et sont sans doute ironiques) mais ils décrivent deux phénomènes qui sous-tendent toute discussion sur la valeur du test, la priorisation et le périmètre.
Lorsque nous effectuons un test, nous interprétons généralement le résultat comme un succès ou un échec. Ce jugement de réussite/échec est un résultat binaire – vrai ou faux, oui ou non, un ou zéro. Ce résultat de test génère une preuve discrète et quantifiable. Les preuves s’accumulent à mesure que nous exécutons de plus en plus de tests. Quoi qu’il arrive, chaque test augmente de manière incrémentale la couverture de notre modèle de test et la connaissance que nous avons du comportement du système. Les tests qui n’ajoutent rien à votre savoir n’apportent aucune valeur.
Si un test n’augmente pas la couverture de façon incrémentale, il a peu de valeur.
Le second aspect est la valeur d’un test. Quelle est la valeur d’un test ? Pouvez-vous vraiment attribuer une valeur en dollar, livre ou euro à un test unique ? Probablement pas. Mais ce que nous pouvons faire – et souvent facilement – c'est dire : « ce test a plus de valeur que celui-là ».
Supposons que nous utilisions un modèle de couverture de code tel que la couverture des instructions. Nous pourrions exécuter un test qui couvre cinq lignes de code ou cinq mille lignes de code. Quelle est la valeur de chacun ? C’est difficile à dire. Mais si notre objectif est la couverture des instructions, le second test a plus de valeur.
Nous ne pouvons pas attribuer de valeur absolue à un test, mais nous pouvons généralement comparer les tests et en déduire la valeur relative de chacun. Autrement dit, sous la pression du temps, nous pouvons généralement dire qu’un test a moins de valeur qu’un autre et, par conséquent, retirer du périmètre le premier si nécessaire.
Nous pouvons comparer la valeur des tests mais seulement s’ils proviennent du même modèle.
Nous devons cependant insister sur le fait que ces comparaisons n’ont de sens que si elles reposent sur le même modèle. Un test qui couvre un large éventail de conditions extrêmes dans un processus a probablement plus de valeur qu’un test du chemin « nominal ». Les tests de bout en bout d’un processus complexe ne peuvent pas être directement comparés aux tests unitaires de composants critiques, par exemple.
Bien que les théories de la physique quantique et de la relativité ne s’appliquent pas directement aux tests logiciels, les principes d’adaptabilité et de perspective, eux, s’appliquent. Trouvez un outil de gestion de tests qui s’aligne sur ces principes pour optimiser votre stratégie de tests.
Utiliser le bon langage
Maintenant que nous avons défini qui est responsable de décider « combien de tests sont suffisants », comment pouvons-nous, en tant que testeurs consciencieux, soutenir cette prise de décision ?
Notez que notre traitement de la valeur des tests est très similaire à notre évaluation des risques. Comme discuté dans l’article précédent, il est très difficile d’attribuer des valeurs numériques à l’échelle ou à l’exposition au risque. Cependant, il est généralement possible de comparer un risque à un autre et de les classer afin de faire des choix sur les risques à prendre en compte dans la portée des tests.
En utilisant le langage du risque, les testeurs seront entendus par la direction.
Les chefs d’équipe de développement semblent souvent écoutés par les gestionnaires, même lorsqu’ils s’expriment en termes techniques. La différence, c’est qu’ils présentent la technologie comme quelque chose d’excitant et de bénéfique. Lorsque les testeurs parlent avec leurs propres termes techniques – des détails « administratifs » des tests, comme les statistiques d’incidents – le message tend à être négatif, et les responsables peuvent s’ennuyer ou s’irriter.
La direction pense peut-être déjà que les testeurs sont quelque peu « fades » comme espèce, mais c’est sans doute parce que beaucoup de managers ne comprennent pas vraiment ce que font les testeurs et la valeur qu’ils apportent. Les testeurs devraient donc élever leur langage au niveau de la direction.
Les tests fondés sur les risques s’adressent à la gestion des utilisateurs et à la gestion de projet dans leur propre langage.
Ce sont des personnes qui pensent avant tout en termes de risques et de bénéfices. Si les testeurs s’adressent à eux dans des termes similaires, ils seront plus susceptibles d’être écoutés, et la direction pourra ainsi prendre de meilleures décisions. En liant les tests aux objectifs du projet, nous pouvons diriger l’attention vers les livrables qui ont le plus de valeur pour les parties prenantes afin de tester en priorité ce qui compte le plus.
De plus, à mesure de l’avancement des tests, nous pouvons démontrer que les avantages les plus importants sont désormais disponibles. La décision de mise en production revient finalement à juger si les avantages obtenus l’emportent sur les risques, les tests permettent ainsi d’apporter de meilleures données à la direction pour appuyer ses décisions.
Utilisez le langage du risque (et des avantages) pour définir le périmètre, planifier et rapporter l’avancement des tests.
Les testeurs ont évidemment besoin de parler technique avec les développeurs et les membres techniques. Par exemple, la qualité des rapports d’incidents est un facteur clé pour corriger rapidement et fiablement les défauts. Je souhaite simplement dire que, lorsqu’il s’adresse à la direction, le testeur s’exprime en termes de risques traités et restant à traiter, plutôt qu’en termes de tests, d’incidents ou de défauts.
Estimations, Budgets et Négociation
Au début d’un nouveau projet, votre chef de projet vous demande : « Je dois planifier et affecter des ressources pour les tests à temps, peux-tu me donner une estimation du nombre de personnes et du temps nécessaires pour réaliser les tests du système ? »
Vous réfléchissez un peu et allez discuter avec le patron.
« J'ai besoin de six testeurs pendant huit semaines. »
Le chef de projet réfléchit un instant et consulte son projet de planning et de plan de ressources.
« Tu peux avoir quatre testeurs pendant six semaines, et c’est tout. »
Vous protestez et répondez : « Mais cela prendra plus de six semaines ! Cela coûtera plus cher que ce que tu as prévu pour tester ce système. Le système est plus gros que la dernière fois. Il est plus complexe. C’est vraiment trop risqué d’économiser sur les tests cette fois. Ce n’est tout simplement pas suffisant. »
Mais le chef de projet reste inflexible, marmonnant quelque chose à propos d’autres dépendances, d’autorités supérieures, etc.
Quel était l'intérêt de faire une estimation si le chef de projet savait dès le départ le budget à respecter ? Quelle pertinence a un budget arbitraire par rapport à la tâche à accomplir ? Pourquoi ne prennent-ils jamais les tests au sérieux ? Les développeurs obtiennent toujours le temps qu'ils demandent, non ? Cela ne paraît pas juste.
Vous pouvez ressentir de la frustration et avoir l'impression que votre jugement professionnel est remis en cause. Mais le problème, depuis le début, c’est que le budget de test dans cette situation était fixe. Tout ce que vous pouvez faire, c’est déterminer quels sont les tests les plus importants ou les plus précieux que vous pouvez réaliser avec votre budget.
Cependant, bien souvent, le chef de projet veut vraiment savoir combien de temps les choses vont prendre pour pouvoir ajuster le plan. Si vous pensez être en négociation, vous avez besoin d’arguments pour négocier. Il faut aussi discuter des résultats du plan, et non de ses apports. Le périmètre découle de la planification, l’effort fourni est une donnée d’entrée.
Vous devez négocier le périmètre.
La négociation des budgets de test devrait toujours porter sur le périmètre, pas sur l’effort.
Le périmètre peut se présenter sous une ou plusieurs formes, et la façon dont vous le présentez ou en parlez pourra varier, mais voici quelques schémas fréquents. Quel que soit le périmètre que vous avez, vous utiliserez cela comme base pour votre estimation et votre défense :
Périmètre comme inventaire d’exigences ou de fonctionnalités
Lorsque l’estimation est réduite de 30%, demandez : « Quels 30% du système ne dois-je pas tester ? »
Périmètre comme inventaire de risques
Lorsque l’estimation est réduite de 30%, demandez : « Quels risques des parties prenantes dois-je supprimer du plan ? »
Périmètre comme modèle tabulaire ou graphique
Lorsque l’estimation est réduite de 30%, demandez : « Quels parcours/chemins/éléments dois-je avertir les parties prenantes qu’ils ne seront pas testés ? »
J’espère que vous voyez ce qui se joue ici.
- Le périmètre des tests repose sur un modèle qui a d’abord été discuté et validé avec les parties prenantes. Ce périmètre est provisoire, sous réserve que les ressources et le temps soient disponibles, et vous devez le rappeler aux parties prenantes.
- Vous estimez sur la base de ce périmètre provisoire. Utilisez le modèle (risques, exigences, processus métier ou tout autre modèle) pour fixer un objectif de couverture et compter les points de couverture et estimer sur cette base.
- Discutez avec le chef de projet. Si l’estimation est trop élevée, utilisez les questions ci-dessus pour déclencher des discussions avec les parties prenantes.
En tant que testeur ou responsable des tests, vous n’êtes pas idéalement placé pour négocier les tests avec le chef de projet. Les parties prenantes ont des préoccupations et, si vous partagez les modèles qui définissent le périmètre des tests, elles auront des avis, s’approprieront le périmètre et pourront le défendre. Les parties prenantes sont aussi responsables de la justification du budget pour leur système, elles sont donc les mieux placées pour équilibrer le coût des tests avec la nécessité de répondre à leurs préoccupations.
Quelques pistes de réflexion
Réfléchissez à qui, dans vos projets, prend la responsabilité de la quantité de tests à réaliser :
- Est-ce vous, en tant que testeur, qui définissez le périmètre et la quantité de tests ?
- Est-ce le chef de projet qui fixe un budget et vous faites de votre mieux avec le temps imparti ?
- Le périmètre est-il négocié avec le chef de projet et les parties prenantes pour convenir d’un équilibre entre l’effort et le périmètre de test à effectuer ?
L’une des principales responsabilités du testeur est de s’assurer que le projet a conscience des risques produits encourus et de les documenter. Ce n’est que si ces risques sont visibles que la direction pourra prendre conscience des risques qu’elle prend en compressant les phases de test.
Il n’existe pas de formule pour déterminer la bonne quantité de tests. Dans la plupart des environnements, le niveau de test ne peut être fixé que par consensus entre la gestion de projet, les sponsors clients, les développeurs, les spécialistes techniques et les testeurs – les tests sont considérés comme dans le périmètre s’ils couvrent les risques identifiés comme prioritaires.
La quantité de tests suffisante doit être déterminée par consensus, le testeur facilitant et apportant des informations au processus d’accord collectif.
Abonnez-vous à la newsletter The QA Lead pour être averti de la sortie des nouveaux épisodes de la série. Ces articles sont extraits du cours Leadership In Test de Paul que nous recommandons vivement pour approfondir ce sujet et d’autres. Si vous vous inscrivez, utilisez notre code promo exclusif QALEADOFFER pour économiser 60 $ sur le tarif complet du cours !
Articles associés :
