Leadership en Test : Planification des Tests
Note de la rédaction : Bienvenue dans la série Leadership In Test par le gourou du test logiciel et consultant Paul Gerrard. Cette série est conçue pour aider les testeurs ayant quelques années d’expérience — notamment ceux qui travaillent en équipes agiles — à exceller dans leurs rôles de chef de test et de gestionnaire.
Dans l’article précédent, nous sommes entrés dans les détails de la documentation et de quelques bonnes pratiques. Cette fois-ci, nous appliquons une grande partie des connaissances des articles précédents pour planifier un projet de test.
Inscrivez-vous à la newsletter The QA Lead pour être informé dès que de nouveaux épisodes de la série sont publiés. Ces articles sont des extraits du cours Leadership In Test de Paul, que nous vous recommandons vivement pour approfondir ce sujet et d’autres thématiques. Si vous vous inscrivez, utilisez notre code promotionnel exclusif QALEADOFFER pour obtenir 60 $ de réduction sur le prix total du cours !
Qu’est-ce qu’un plan, au juste ?
Un plan de projet rassemble les tâches du projet, les durées estimées, les dépendances et les livrables dans un modèle planifié de la réalité.
Si vous considérez le plan comme une prédiction de l’avenir, vous seriez très prudent avant de vous y fier, mais c’est ce que nous faisons généralement.
Vous avez peut-être déjà croisé des chefs de projet qui traitent leur plan comme leur réalité personnelle — un monde imaginaire qui leur est propre. Mais ne soyons pas trop sévères avec les chefs de projet — ils sont souvent motivés à créer un plan et à s’y tenir coûte que coûte.
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
Le plan n’est pas la réalité ; c’est un modèle de la réalité nécessitant des changements constants.
Dans cet article, je couvrirai chaque étape de la planification des tests, y compris :
- Livrables
- Comment
- Ressources
- Votre réseau de soutien
- Estimations
- Dépendances, risques et hypothèses
- Communication, engagement et suivi d’avancement
Mais d’abord, tâchons de comprendre à quoi sert réellement un plan.
Pourquoi planifier ?
Le but de la planification est généralement de créer une approche convenue, un ensemble d’engagements, de dépendances, de coûts et un calendrier afin de livrer un projet. Le plan est un accord entre les parties prenantes, les fournisseurs et les participants au projet, qui détaille généralement les points suivants :
- Quelles ressources sont nécessaires et à quel moment
- À quel moment les tâches doivent commencer et finir, et qui les réalisera
- Les compétences requises pour accomplir les tâches
- Les outils et technologies qui soutiennent le plan
- Les livrables et leur date de livraison prévue
- Les coûts en effort et en ressources nécessaires
- Le processus pour faire avancer le projet ou le processus à travers ses étapes
- Les risques pouvant compromettre la réalisation du projet.
Certaines de ces composantes peuvent être définies dans une stratégie ou déjà en place. Par exemple, il se peut qu’on sache déjà quels fournisseurs participent et ce qu’ils feront dans le projet. Les outils et technologies à utiliser peuvent être déjà connus et présents. Les personnes, les environnements de test et les données peuvent être prêts. Il peut aussi exister une stratégie définissant le processus, l’approche ou les techniques à utiliser.
Cependant, tandis que la stratégie pose les principes ou la théorie, le plan décrit les aspects pratiques ou la logistique sur la façon dont le projet sera livré en réalité.
La stratégie exprime comment un projet sera exécuté en principe, le plan définit et confirme comment le projet sera mené en pratique.
Pour nombre de chefs de projet, le plan est ce qui est saisi dans Microsoft Project ; mais un plan viable dépend de la connaissance, par tous les participants au projet, de ce qu’ils doivent faire et comment. Pour y arriver, le plan et la façon de s’y prendre doivent être communiqués et acceptés par tous les intervenants.
Planifier est un voyage, pas une tâche
Pour citer l’ancien président américain Dwight D. Eisenhower, « la planification est primordiale. Le plan ne compte pas. » Ce point de vue est si important qu’il mérite d’être répété dans presque tous les contextes de travail sur les projets informatiques. Mais qu’est-ce que cela signifie de dire que le plan ne compte pas ? Quel est l’intérêt de planifier si le résultat est un plan sans valeur ?
Le plan sur lequel vous vous retrouvez n'est jamais inutile, mais le point de vue d’Eisenhower concerne l’acte de planifier et la valeur de cet acte comparée à celle du plan en lui-même. Comparons rapidement la façon dont la planification fonctionne dans des projets longs structurés et dans des projets agiles/continus séparément.
Planification structurée vs agile
Dans un projet à long terme, votre entreprise, vos fournisseurs et l’équipe informatique interne doivent savoir à quel engagement ils sont soumis afin de pouvoir planifier la disponibilité des personnes et des ressources matérielles.
Il faut du temps précieux pour rassembler les informations nécessaires afin de bâtir un plan. Avec toutes les dépendances liées aux ressources et aux personnes, ainsi qu’à la performance et à l’engagement des fournisseurs comme du personnel interne, de nombreuses choses peuvent mal tourner. Certaines vont mal tourner. C’est pour cette raison que le plan, prédiction de l’avenir, est semé d’embûches.
Le lendemain de la publication d’un plan, puis chaque jour qui suit, de nouvelles informations émergent et des ajustements s’imposent. Des exigences sont abandonnées, des fournisseurs livrent en retard, les environnements, données de test ou outils ne sont pas prêts à temps. La liste est longue. Planifier n’est jamais une tâche ponctuelle, c’est une activité continue — presque quotidienne.
Souvent, les événements non prévus sont considérés comme du bruit et suscitent peu d’attention. Mais, par la suite, ces petits accrocs peuvent devenir de sérieux problèmes. L’un des défis des projets en cascade est que ces ajustements continus peuvent devenir lourds à porter, car tout changement est perçu comme un bidouillage inutile. Les projets continuent souvent à avancer coûte que coûte, espérant que « tout ira bien le jour J ». Mais c’est rarement le cas et on l’a dit plusieurs fois :
Comment un projet peut-il avoir un an de retard ? Un jour à la fois.
L’approche agile s’inscrit en partie en réaction à la frustration face aux plans rigides ou trop figés. L’agilité est l’alternative éprouvée à l’inertie de méthodes lourdes, en étapes. Mais cela signifie-t-il que les projets agiles ne prévoient pas de planification ? Non.
Même en agile, une certaine planification initiale est nécessaire pour structurer le travail, mobiliser les ressources et établir — au moins à haut niveau — le processus de livraison sur les prochains mois. Mais itération après itération, et souvent au quotidien, le plan global est continuellement ajusté pour tenir compte des événements et des nouvelles informations qui apparaissent.
La planification est un parcours d’apprentissage continu, pas une tâche avec un livrable.
Planification des tests
Jusqu’ici, nous avons envisagé la planification de projet de façon générale et suggéré qu’il s’agit bien d’une activité continue. Focalisons-nous désormais sur la planification des tests au sein des projets.
La planification des tests ressemble beaucoup à la planification de projet – il s’agit en réalité d’un plan à plus petite échelle. Bien sûr, le plan de test doit aussi s’intégrer au plan projet global car il dépend d’autres activités et livrables du projet (et d’autres tâches dépendent des tests). Fréquemment, les plans de tests sont bouleversés car ces dépendances ne sont pas respectées.
Les plans de tests sont relativement simples en aperçu. Plusieurs activités peuvent dépendre du projet principal. Ce sont ces activités qui figurent souvent comme des tâches dans le plan de projet plus vaste. Mais ces activités sont réparties au sein de l’équipe, avec peut-être un large inventaire d’éléments à tester et à planifier/exécuter.
Ce niveau de détail n’est pas aussi pertinent pour le calendrier du chef de projet et est généralement défini et géré localement au sein de l’équipe de test.
Examinons quelques-uns des éléments essentiels de votre plan de test.
Livrables
Quels sont les livrables des tests ?
Quelle question ! Il s'agit forcément des spécifications de tests, des tests eux-mêmes, des résultats et des rapports, n’est-ce pas ? Les livrables se trouvent essentiellement dans la documentation, donc il suffirait de compléter la paperasse et cocher des cases.
Mais cette approche, bien que courante, est en partie responsable de la mauvaise réputation des tests (et des testeurs) considérés comme des bureaucrates coûteux et lents apportant peu de valeur. Après tout, qui lit ces documents volumineux ?
Supposons qu’il ne soit pas prévu de produire de documentation de test dans un projet agile. C’est très probable, alors que livrent réellement les tests dans ces situations ? Quelle valeur ont-ils ? Il est un peu tard pour se poser ces questions, non ?
Lorsqu’un composant, un sous-système ou le système entier est testé, le résultat est une preuve du comportement du système dans une situation ou un contexte donné. Les preuves de ce comportement sont collectées et rassemblées pour être présentées aux parties prenantes (développeurs, utilisateurs, responsables, etc.) afin qu’ils prennent une décision : corriger les anomalies, intégrer un composant, accepter ou rejeter une fonctionnalité, livrer ou déployer un sous-système ou le système entier.
Le livrable des tests est la preuve du comportement du système, utilisée par les parties prenantes pour prendre une décision.
Dans certains projets, il est essentiel de fournir une documentation de test permettant de retracer comment un test a été spécifié, conçu, mis en œuvre et exécuté. Mais ce sont les preuves du comportement du système qui constituent au final le véritable livrable de valeur pour les parties prenantes.
La valeur des tests réside dans le niveau de confiance qu'ont les parties prenantes pour prendre des décisions basées sur les preuves issues des tests.
Ces preuves peuvent être collectées, recensées et analysées de manière systématique dans des solutions de gestion des tests sophistiquées et présentées aux parties prenantes sous des formats graphiques élégants. Ou bien des notes manuscrites peuvent être utilisées par un testeur pour présenter verbalement le bilan des tests à un propriétaire produit lors d'une réunion quotidienne.
Quelle que soit la manière de collecter et présenter, la tâche finale du test consiste en la transmission des preuves.
Comment
Quel que soit l'envergure ou la méthodologie du projet, les tests reposent sur une série d'activités. Nous allons examiner un processus générique du point de vue du testeur (ou de l'équipe) puis observer quelques variations pouvant survenir.
On distingue ce qu'on pourrait appeler les « activités de test » et les activités de soutien ou logistiques au test. Pour vous assurer d'inclure toutes les activités dans le plan, vous pourrez trouver les tableaux ci-dessous utiles comme listes de contrôle.
Une activité du tableau ci-dessus que vous ne reconnaîtrez peut-être pas autant est l'activité de retour d'information. Vous avez sûrement déjà eu à travailler avec des exigences de mauvaise qualité.
L'activité de retour d'information, de revue et de remise en question est celle où les testeurs, après avoir réfléchi et modélisé une exigence, identifient des problèmes et peuvent utiliser des exemples pour démontrer où les exigences sont manquantes, ambiguës ou contradictoires.
Si vous jugez que les exigences sont mauvaises, il est vraiment pertinent de prévoir une place pour cette activité.
Logistique des Tests
La logistique des tests soutient les activités de test ci-dessus. Alors que la liste des activités de test que j'ai donnée est assez complète, la logistique des tests varie selon chaque projet et organisation. La liste ci-dessous n'est donc pas exhaustive. Dans votre projet, prenez le temps de réfléchir à chaque activité ou dépendance nécessaire pour réaliser les tests.
Ressources (humaines, matérielles)
Nous utilisons souvent le terme ressources pour désigner les personnes sur nos projets et, pour certains, ce n'est pas très approprié. Les individus ne sont pas des objets, ils sont bien entendu des êtres humains. Dans les projets plus réduits, il est peut-être possible d'utiliser les noms des personnes mais, dans les grandes organisations, lorsque des équipes projet sont impliquées et ne sont pas encore constituées, parler de nombre de ressources est simplement une abréviation pour un nombre de personnes.
Plus important encore, ce n’est pas forcément le nombre de personnes qui compte – ce sont plutôt leurs compétences qui sont cruciales. Bien sûr, les personnes travaillent de façon différente et généralement à des rythmes différents, il vous faudra donc en tenir compte pendant la planification.
Au-delà des personnes, vous aurez, à différentes étapes, besoin de diverses ressources matérielles pour que les tests puissent se dérouler. Cela va du plus banal au plus spécifique et l'absence de l'une de ces ressources peut mettre en péril la mission des tests.
Vous avez peut-être déjà la chance d’avoir accès à un laboratoire de test tout équipé, géré et dédié. Si ce n’est pas le cas, il faudra peut-être tout spécifier — depuis l’espace physique et le mobilier jusqu'aux post-its et gommes — afin de définir votre environnement de travail.
Dans le tableau ci-dessous, on trouve quelques ressources typiques requises. Votre liste sera sans doute très différente.
Une fois que vous avez identifié toutes les ressources nécessaires à la réalisation de votre plan, réfléchissez à l'opportunité d'ajouter des activités dans votre plan pour leur acquisition.
Votre réseau de soutien
Si les personnes et les compétences nécessaires à la réalisation des tests étaient sous votre contrôle, les projets seraient bien plus simples ! Mais rares sont les équipes à disposer de toutes les compétences requises, ou de l'autorisation et de l'accès aux ressources matérielles nécessaires. Beaucoup de projets sont dotés et gérés selon le mode matriciel. Les membres clés de l'équipe relèvent en réalité de responsables d'autres départements spécialisés et vous n'obtiendrez qu'un engagement limité de leur part.
Vous devrez peut-être spécifier un nombre d'heures par jour ou planifier des créneaux horaires pour accéder aux compétences spécialisées mentionnées ci-dessus. Parfois, on vous demandera quel niveau de service est acceptable, par exemple "les demandes à haute priorité recevront une réponse sous trente minutes", etc.
Estimations
L’estimation dans les projets logiciels est une tâche complexe. Beaucoup d’articles ont expliqué à quel point il est difficile, voire impossible, d'estimer précisément. Pourtant, les estimations sont requises dans tous les projets, et plus le projet s’agrandit, plus nous en dépendons.
Nous avons besoin d’estimations pour établir un calendrier, mais le problème est que l’estimation ne procure pas de précision. Au mieux, nous pouvons calculer un effort ou un délai écoulé avec un certain niveau de confiance ou de probabilité.
Certaines personnes considèrent l’estimation comme une pratique ésotérique, et il existe même un mouvement #NoEstimates qui compte de nombreux adeptes. Il y a beaucoup de débats sur le fait de savoir si l’estimation peut jamais être suffisamment précise ou si elle représente une bonne pratique dans les projets informatiques.
L’estimation ne sera jamais une science exacte. Mais, selon mon expérience, je me sens à l’aise de partager ces principes :
- Les exigences sont faillibles et imprécises.
- Les personnes sont plus ou moins compétentes, consciencieuses et travailleuses.
- Plus un travail est petit, plus il est facile à estimer ; décomposez les tâches importantes en plus petites unités quand c’est possible et regroupez les estimations pour la tâche plus globale.
- L’estimation repose sur l’expérience. Si vous n’en avez pas, trouvez dans quelle mesure l’expérience des autres est pertinente et peut être adaptée.
- Votre élément de travail est unique, alors recherchez des schémas de travail dans d’autres situations connues où vous disposez d’expérience.
- Demandez à d’autres d’estimer et comparez. Discuter des écarts met au jour les différences de points de vue, de confiance et d’exhaustivité.
- Estimez la meilleure situation possible puis la pire. Une bonne estimation se situe entre les deux.
Estimez aujourd’hui et commencez le travail ; demain et chaque jour suivant, grâce aux connaissances acquises, votre estimation jusqu’à la fin s’améliorera.
Dépendances, Risques et Hypothèses
Dans un article précédent, nous avons abordé les risques et le rôle des tests dans la gestion des risques. Les risques produits concernent le fait que le produit réponde ou non aux besoins des utilisateurs en termes d’exigences fonctionnelles ou techniques. Ici, l’accent est mis sur les risques liés au plan de livraison réel.
Les choses ne se passent pas toujours comme prévu dans les projets. Lors de votre planification, vous devez clarifier quels risques d’échec vous avez pris en compte et anticipé. Trois aspects doivent être couverts : les dépendances, les risques et les réponses.
Dépendances
Les dépendances correspondent à une liste de ressources humaines et matérielles requises, ainsi que des activités préalables, devant toutes être terminées pour que vos activités prévues aboutissent et soient livrées.
Il existe toujours des dépendances pour toute activité de test, qu’il s’agisse d’un test à grande échelle au niveau système ou d’une session de test exploratoire sur une fonctionnalité. Les dépendances couvrent trois aspects principaux.
Risques
Le risque est la probabilité que votre plan échoue lors de son exécution. Le risque concerne notamment :
- Vos estimations : qu’est-ce qui pourrait fausser vos estimations ? Un système plus complexe, défectueux, incomplet ou en évolution constante pourrait toutes influencer vos estimations.
- Des personnes indisponibles, manquant d’expérience ou de compétences, ou n’étant pas pleinement engagées dans votre phase du projet. Il peut s’agir de membres de l’équipe ou de personnes de votre réseau de soutien.
- Des infrastructures comme les environnements de test, les outils (ou la formation à leur usage) ou l’espace de bureau indisponibles, mal préparés ou défectueux.
- Des activités préalables qui ne se terminent pas à temps (ou qui sont abandonnées, livrant des produits partiels ou défectueux ou ne livrant rien du tout).
Réponses
Pour chacun de ces risques, il vous faut évaluer la probabilité, l’impact, et, s’ils sont significatifs, prévoir une réponse appropriée ou une conséquence attendue. Ces réponses prennent généralement l’une de ces formes :
- Hypothèse : le risque est jugé suffisamment faible pour être ignoré ou considéré comme négligeable. Cependant, il reste à surveiller et est consigné comme une hypothèse (de disponibilité, de complétude, etc.).
- Ajustement : le risque est important, mais il existe une action possible pour en réduire l’impact sur le plan. Par exemple, si le système en test est partiellement livré, avec des fonctionnalités manquantes, le plan peut être ajusté pour ne tester que les fonctionnalités disponibles.
- Conséquence : certains risques ne peuvent pas être absorbés. Si le système est livré en retard, alors les tests ne peuvent commencer qu’à la livraison.
Communication, Engagement et Suivi de l’avancement
Enfin, abordons un aspect crucial mais souvent négligé de la planification. Vous pouvez produire un plan de projet détaillant toutes les tâches, les participants, les ressources, les responsabilités, les dépendances, la planification, l’effort et les coûts. Ou il peut s’agir d’un accord verbal entre les membres d’une équipe agile.
Dans tous les cas, le plan doit être communiqué de façon efficace à tout le monde pour que chacun sache ce qui est attendu et quand.
Un plan convenu est un contrat entre les participants. Si un responsable d’équipe valide un plan, cela représente un engagement, explicite ou implicite, à remplir la part du contrat qui lui revient.
Le plan est un contrat entre les participants.
Dans les projets moins formels, il se peut qu’il n’y ait aucun plan écrit ni aucun engagement formel. Dans ces circonstances, le plan prend la forme d’une conversation continue entre les membres de l’équipe. L’équipe se réunit quotidiennement et les tâches actives du plan sont discutées en temps réel. Sur quoi chacun travaille-t-il ? Les progrès correspondent-ils aux attentes ? Quels problèmes les membres rencontrent-ils ? Quels obstacles bloquent la progression ?
Dans tous les projets, l’objectif du rapport d’avancement est double. Bien sûr, il s’agit de communiquer où chacun en est dans ses activités actuelles du projet. Mais le rapport d’avancement est aussi un contrôle périodique continu pour s’assurer que l’avancement peut se poursuivre et vérifier que l’engagement des participants est fiable.
Merci de votre lecture, et retrouvez-nous la prochaine fois pour… oui, vous l’avez deviné, l’exécution !
Inscrivez-vous à la newsletter The QA Lead pour être informé(e) de la publication des nouveaux épisodes de cette série. Ces articles sont extraits du cours Leadership In Test de Paul que nous vous recommandons vivement 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 !
