Leadership dans les tests : planification des tests

Le plan n’est pas la réalité ; c’est un modèle de la réalité qui nécessite des changements constants.

Dans cet article, je couvrirai chaque étape de la planification des tests, notamment :

• Livrables
• Comment
• Ressources
• Votre réseau de soutien
• Estimations
• Dépendances, risques et hypothèses
• Communication, engagement et suivi de l’avancement

Mais commençons par nous faire une idée précise de l’utilité d’un plan. 

Pourquoi planifier ?

L’objectif de la planification est généralement de définir une approche convenue, un ensemble d’engagements, de dépendances, de coûts et un calendrier pour mener à bien un projet. Le plan constitue un accord entre les parties prenantes du projet, les fournisseurs et les participants, qui définit généralement les éléments suivants :

• Les ressources nécessaires et le moment où elles le seront
• Le moment où les tâches doivent commencer et se terminer, ainsi que les personnes qui les réaliseront
• Les compétences nécessaires pour mener les tâches à bien
• Les outils et les technologies qui soutiennent le plan
• Les livrables et le moment où ils seront fournis
• Les coûts liés aux efforts et aux ressources nécessaires
• Le processus permettant de faire progresser le projet ou le processus à travers ses différentes étapes
• Les risques qui menacent la livraison.

Certaines de ces dimensions peuvent être définies dans une stratégie ou déjà être en place. Il se peut, par exemple, que l’on sache quels fournisseurs participent au projet et quelles seront leurs responsabilités. Les outils et les technologies à utiliser peuvent déjà être connus et disponibles. Les personnes, les environnements de test et les données peuvent être prêts. Il peut également exister une stratégie définissant le processus, l’approche ou les techniques à employer.

Mais alors que la stratégie expose les principes ou la théorie, le plan décrit les aspects pratiques et la logistique de la réalisation concrète du projet.

Une stratégie définit la manière dont un projet sera exécuté en principe ; le plan définit et confirme la manière dont le projet sera exécuté en pratique.

Pour de nombreux chefs de projet, le plan est conservé dans un logiciel comme Microsoft Project, mais un plan viable dépend du fait que tous les participants au projet sachent ce qu’ils doivent faire et comment le faire. Pour y parvenir, le plan et les connaissances sur la manière dont les choses seront réalisées doivent être communiqués à toutes les personnes concernées, qui doivent s’y engager.

La planification est un parcours, pas une tâche

Pour citer l’ancien président des États-Unis Dwight D. Eisenhower : « planifier, c’est tout. Le plan n’est rien. » Ce sentiment est si important qu’il mérite d’être répété dans presque tous les contextes de travail liés aux projets de systèmes. Mais que signifie dire que le plan n’est rien ? Quel est l’intérêt de planifier si le résultat est un plan sans valeur ? 

Le plan auquel vous aboutissez n’est jamais sans valeur, mais le sentiment d’Eisenhower concerne l’acte de planifier et sa valeur comparée à celle du plan. Comparons rapidement le fonctionnement de la planification dans les projets structurés de longue durée et dans les projets agiles/continus, séparément.

REJOIGNEZ LA COMMUNAUTÉ

Améliorez votre boîte de réception avec plus de conseils en leadership technologique pour livrer de meilleurs logiciels et systèmes.

Create Free Account

Have an account? Log In

Planification structurée ou agile

Dans un projet à long terme, votre entreprise, vos fournisseurs et votre personnel informatique interne doivent savoir quel engagement est attendu de leur part afin de pouvoir planifier la disponibilité des personnes et des ressources matérielles.

Il faut un temps précieux pour rassembler les informations nécessaires à la création d’un plan. Avec toutes les dépendances liées aux ressources et aux personnes, ainsi que l’engagement et les performances des fournisseurs et du personnel interne, beaucoup de choses peuvent mal tourner. Certaines choses vont mal tourner. Pour cette raison, le plan, en tant que 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 apparaissent et certains ajustements deviennent nécessaires. Des exigences sont abandonnées ; les fournisseurs livrent en retard ; les environnements, les données de test ou les outils ne sont pas prêts à temps. La liste est longue. La planification n’est jamais une tâche ponctuelle, c’est une activité continue — presque quotidienne.

Souvent, les événements imprévus sont considérés comme du bruit et ne reçoivent guère d’attention. Mais, plus tard, certains de ces incidents mineurs deviennent des problèmes majeurs. L’un des défis des projets en cascade est que cet ajustement continu peut être contraignant, car toute modification est perçue comme une intervention inutile. Les projets poursuivent souvent leur course malgré tout, en espérant que les choses « se passeront bien le moment venu ». Mais c’est rarement le cas, et on l’a dit de nombreuses fois :

Comment un projet peut-il prendre un an de retard ? Un jour à la fois.

L’approche agile est en partie une réaction à la frustration provoquée par les plans fixes ou inflexibles. L’agilité est l’alternative éprouvée à l’inertie des approches lourdes et par étapes. Mais cela signifie-t-il que les projets agiles ne font pas de planification ? Non. 

Même dans un contexte agile, une certaine planification initiale est nécessaire pour structurer le travail, mobiliser les ressources et planifier — au moins à un niveau général — le processus de mise en production pour les mois à venir. Mais, itération après itération, et souvent jour après jour, le plan global est continuellement ajusté afin de tenir compte des événements et des nouvelles informations qui apparaissent.

La planification est un parcours d’apprentissage continu, et non une tâche assortie d’un livrable.

Planification des tests

Jusqu’à présent, nous avons examiné la planification des projets dans son ensemble et suggéré qu’il s’agit surtout d’une activité continue. Nous allons maintenant nous concentrer spécifiquement sur la planification des tests dans les projets. 

La planification des tests est très similaire à la planification d’un projet : il s’agit simplement d’un plan à plus petite échelle. Bien entendu, le plan de test doit également s’intégrer au plan global du projet, car il dépend d’autres activités et livrables du projet (et d’autres tâches dépendent des tests). Les plans de test sont souvent perturbés parce que ces dépendances ne sont pas respectées.

Les plans de test sont relativement simples dans leur vue d’ensemble. Plusieurs activités peuvent dépendre du projet parent. Ce sont souvent elles qui apparaissent comme des tâches dans le plan global du projet. Mais ces activités sont réparties au sein d’une équipe, qui dispose peut-être d’un vaste inventaire d’éléments de test pour lesquels les tests doivent être planifiés et exécutés. 

Ce niveau de détail n’est pas très 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 fondamentaux de votre plan de test.

Livrables

Quels sont les livrables des tests ?

Quelle question ! Il s’agit sûrement des spécifications de test, des tests, des résultats et des rapports ? Les livrables sont essentiellement contenus dans la documentation, donc tout ce qui nous importe est de produire les documents et de cocher quelques cases. 

Mais cette approche, bien que courante, contribue en partie à donner aux tests (et aux testeurs) la réputation de bureaucrates coûteux et rigides, qui apportent peu de valeur. Après tout, qui lit ces documents volumineux ?

Supposons qu’il n’y ait aucune intention de produire de la documentation de test dans un projet agile. C’est très probable ; alors, que produisent réellement les tests dans ces situations ? Quelle valeur les tests apportent-ils réellement ? Il est un peu tard pour poser ces questions, n’est-ce pas ?

Lorsqu’un composant, un sous-système ou l’ensemble du système est testé, le résultat consiste en des preuves du comportement du système dans une situation ou un contexte donné. Les preuves du comportement du système sont recueillies et rassemblées afin d’être présentées aux parties prenantes (développeurs, utilisateurs, responsables, etc.) pour leur permettre de prendre une décision : corriger des bogues, intégrer un composant, accepter ou rejeter une fonctionnalité, mettre en production ou déployer un sous-système ou l’ensemble du système.

Le livrable des tests consiste en des preuves du comportement du système, utilisées par les parties prenantes pour prendre une décision.

Désormais, dans certains projets, il est essentiel de fournir une documentation de test afin de consigner la manière dont un test a été défini, conçu, mis en œuvre et exécuté. Mais c’est la preuve du comportement du système qui constitue le livrable final ayant le plus de valeur pour les parties prenantes.

La valeur des tests réside dans le niveau de confiance dont disposent les parties prenantes pour prendre des décisions fondées sur les preuves issues des tests.

Ces preuves peuvent être collectées, mises en tableau et analysées de manière systématique dans des solutions de gestion des tests sophistiquées, puis présentées aux parties prenantes sous des formes graphiques élégantes. Les notes manuscrites peuvent également être utilisées par un testeur pour présenter oralement le récit des tests à un propriétaire de produit lors d’une réunion quotidienne.

Quelle que soit la manière dont elles sont collectées et présentées, la tâche finale des tests consiste à transmettre les preuves.

Comment

Quelle que soit l’ampleur ou la méthodologie du projet, les tests reposent sur une certaine série d’activités. Nous examinerons un processus générique du point de vue du testeur (ou de l’équipe), puis nous étudierons certaines des variantes qui se présentent. 

On distingue ce que l’on pourrait appeler les « activités de test » et les activités « de soutien aux tests » ou « logistiques ». Pour vous assurer d’inclure toutes les activités dans le plan, vous trouverez peut-être les tableaux ci-dessous utiles comme listes de contrôle.

Dans le tableau ci-dessus, une activité que vous ne reconnaissez peut-être pas vraiment est l’activité de retour d’information. Vous avez certainement déjà dû travailler avec des exigences de mauvaise qualité. 

L’activité de retour d’information, de revue et de remise en question intervient lorsque les testeurs, après avoir examiné et modélisé une exigence, découvrent des problèmes et peuvent utiliser des exemples pour démontrer que certaines exigences sont manquantes, ambiguës ou contradictoires.

Si vous considérez que les exigences sont de mauvaise qualité, il vaut certainement la peine de prévoir cette activité.

Logistique des tests

La logistique des tests vient soutenir les activités de test mentionnées ci-dessus. Alors que la liste des activités de test que j’ai fournie est relativement exhaustive, la logistique des tests varie selon chaque projet et chaque 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 à la réalisation des tests.

Ressources (humaines, matérielles)

Nous utilisons souvent le mot ressources pour désigner les personnes qui travaillent sur nos projets, ce qui peut mettre certains mal à l’aise. Les personnes ne sont pas des choses, ce sont bien sûr des êtres humains. Dans les projets de petite taille, il peut être possible d’utiliser des noms, mais dans les grandes organisations, lorsque des équipes de projet sont concernées et qu’elles ne sont peut-être pas encore constituées, parler d’un certain nombre de ressources est simplement une façon abrégée de désigner un certain nombre de personnes.

Plus important encore, ce n’est pas nécessairement le nombre de personnes qui compte : ce sont leurs compétences qui importent réellement. Bien sûr, les personnes travaillent de façons différentes et généralement à des rythmes différents ; vous devrez donc en tenir compte dans votre planification.

Au-delà des personnes, vous aurez besoin, à différentes étapes, de diverses ressources matérielles pour que les tests puissent se dérouler. Elles vont du matériel courant au matériel très spécifique, et l’absence de l’une d’entre elles peut compromettre la mission de test.

Vous avez peut-être déjà la chance d’avoir accès à un laboratoire de test dédié, entièrement équipé et géré. Dans le cas contraire, vous devrez peut-être tout spécifier : de l’espace physique et du mobilier jusqu’aux notes adhésives et aux gommes, afin de définir votre environnement de travail.

Le tableau ci-dessous présente quelques ressources généralement nécessaires. Votre liste sera sans aucun doute très différente. 

Lorsque vous avez identifié toutes les ressources nécessaires à la réalisation de votre plan, déterminez si vous devez prévoir des activités supplémentaires dans votre plan pour les obtenir.

Votre réseau de soutien

Si les personnes et les compétences dont vous avez besoin pour effectuer les tests étaient sous votre contrôle, les projets pourraient être beaucoup plus simples ! Mais rares sont les équipes qui disposent de toutes les compétences nécessaires, ou de l’autorisation et de l’accès aux ressources matérielles indispensables. De nombreux projets sont dotés en personnel et gérés selon le principe de la gestion matricielle. Les membres clés de l’équipe rendent effectivement compte à des responsables d’autres services spécialisés, et vous n’obtiendrez de leur part qu’un engagement limité.

Vous devrez peut-être spécifier un nombre défini d’heures par jour ou planifier des créneaux horaires pour accéder aux compétences spécialisées ci-dessus. Parfois, on vous demandera quel niveau de service est acceptable, par exemple : « les demandes hautement prioritaires recevront une réponse dans les trente minutes », et ainsi de suite.

Estimations

L’estimation dans les projets logiciels est une entreprise délicate. De nombreux articles ont été écrits sur la difficulté, voire l’impossibilité, de faire des estimations. Pourtant, les estimations sont nécessaires dans tous les projets, et plus le projet est important, plus nous dépendons d’elles.

Nous avons besoin d’estimations pour créer un calendrier, mais le problème est qu’une estimation ne garantit pas la précision. Tout ce que nous pouvons faire au mieux est de calculer un effort ou un temps écoulé avec un certain niveau de confiance ou de probabilité.

Certaines personnes considèrent l’estimation comme un art occulte, et il existe même un mouvement #NoEstimates qui compte de nombreux adeptes. Les débats sont nombreux sur la question de savoir si une estimation peut un jour être suffisamment précise ou s’il s’agit même d’une bonne pratique dans les projets logiciels.

L’estimation ne sera jamais une science exacte. Mais, d’après mon expérience, voici certains principes que je me sens à l’aise de partager :

• Les exigences sont faillibles et imprécises.
• Les personnes sont plus ou moins compétentes, consciencieuses et travailleuses.
• Plus l’élément de travail est petit, plus il est facile à estimer ; divisez les tâches importantes en unités plus petites chaque fois que possible, puis regroupez les estimations pour obtenir celle de la tâche globale.
• L’estimation repose sur l’expérience. Si vous n’en avez pas, cherchez dans quelles situations l’expérience d’autres personnes est pertinente et peut être adaptée.
• Votre élément de travail est unique ; recherchez donc des schémas de travail dans d’autres situations connues pour lesquelles vous avez de l’expérience.
• Demandez à d’autres personnes d’estimer et comparez les résultats. La discussion des écarts révèle les différences d’attentes, de confiance et de minutie.
• Estimez la situation la plus favorable, puis la situation la plus défavorable. Une bonne estimation se situe quelque part entre les deux.

Estimez aujourd’hui et commencez le travail ; demain, puis chaque jour suivant, grâce aux connaissances acquises, votre estimation du temps nécessaire pour terminer s’améliorera.

Dépendances, risques et hypothèses

Dans un article précédent, nous avons abordé le risque et le rôle des tests dans la gestion des risques. Les risques liés au produit concernent la question de savoir si le produit répond aux besoins des utilisateurs au regard des exigences fonctionnelles ou techniques. Ici, l’accent est mis sur les risques liés au plan de livraison réel.

Les projets ne se déroulent pas toujours comme prévu. Dans le cadre de votre planification, vous devez clairement indiquer les risques d’échec que vous avez pris en compte et pour lesquels vous avez prévu des mesures. Cela comporte trois aspects : les dépendances, les risques et les réponses.

Dépendances

Les dépendances représentent une liste des ressources humaines et matérielles nécessaires, ainsi que des activités préalables qui doivent être terminées pour que vos activités planifiées réussissent et aboutissent. 

Il existe toujours des dépendances pour toute activité de test, qu’il s’agisse d’un test système à grande échelle ou d’une session de test exploratoire d’une fonctionnalité. Les dépendances couvrent trois aspects principaux.

More Articles

• 9 types de tests logiciels en ingénierie logicielle
• 5 types de tests de performance + meilleurs outils
• Tendances des tests logiciels : dernières technologies QA, statistiques et données

Risques

Le risque correspond à la probabilité que votre plan échoue lors de son exécution. Les risques concernent notamment les éléments suivants :

• Vos estimations : qu’est-ce qui pourrait les rendre erronées ? Un système plus complexe, défectueux, incomplet ou en évolution constante pourrait avoir une incidence sur vos estimations.
• Des personnes qui ne sont pas disponibles, qui manquent d’expérience ou de compétences, ou qui ne sont 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.
• Une infrastructure, comme les environnements de test, les outils (ou la formation à leur utilisation) ou les locaux, qui n’est pas disponible, qui est mal préparée ou qui est défectueuse.
• Des activités préalables qui ne sont pas terminées à temps (ou qui sont abandonnées, qui fournissent des produits partiels ou défectueux, ou qui n’aboutissent à aucune livraison).

Réponses

Pour chacun de ces risques, vous devez évaluer la probabilité, l’impact et, lorsque cela est important, une réponse appropriée ou une conséquence attendue. Ces réponses prennent généralement l’une des formes suivantes :

• Hypothèse : le risque est jugé suffisamment faible pour être ignoré ou considéré comme négligeable. Il reste toutefois surveillé et consigné comme une hypothèse (de disponibilité, d’exhaustivité, etc.).
• Adaptation : le risque est important, mais une action peut en réduire l’impact sur le plan. Par exemple, si le système testé est livré partiellement, avec des fonctionnalités manquantes, le plan peut être adapté afin de tester uniquement les fonctionnalités disponibles.
• Conséquence : certains risques ne peuvent pas être absorbés. Si le système est livré en retard, les tests ne peuvent commencer qu’une fois la livraison effectuée.

Communication, engagement et rapports d’avancement

Enfin, nous arrivons à un aspect crucial, mais souvent négligé, de la planification. Vous pouvez produire un plan de projet comprenant toutes les tâches, les participants, les ressources, les responsabilités, les dépendances, les délais, les efforts et les coûts. Il peut également s’agir d’une compréhension verbale entre les membres d’une équipe agile. 

Dans tous les cas, le plan doit être communiqué efficacement à chacun afin que tous sachent ce qui est requis et à quel moment.

Un plan approuvé constitue un contrat entre les participants. Si un responsable d’équipe valide un plan, cela implique explicitement ou implicitement un engagement à respecter la part du contrat qui incombe à son équipe.

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. 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 les membres travaillent-ils ? Les progrès suivent-ils les attentes ? Quels problèmes rencontrent-ils ? Quels problèmes entravent la progression ?

Dans tous les projets, le suivi de l’avancement a un double objectif. Il est évidemment nécessaire de communiquer la situation de chacun concernant son activité actuelle sur le projet. Mais le rapport d’avancement constitue également une vérification périodique continue permettant de s’assurer que les progrès peuvent être maintenus et de vérifier que l’engagement des participants peut être honoré.

Merci de nous avoir lus, et rendez-vous la prochaine fois pour… vous l’avez deviné, l’exécution !

Inscrivez-vous à la newsletter de The QA Lead pour être informé de la mise en ligne des nouvelles parties de la série. Ces articles sont extraits du cours de leadership dans les tests de Paul, que nous recommandons vivement pour approfondir ce sujet et bien d’autres. Si vous vous inscrivez, utilisez notre code promotionnel exclusif QALEADOFFER pour bénéficier de 60 $ de réduction sur le prix total du cours !