Leadership en test : Exécuter un projet de test

La pression classique sur le test

Toute personne ayant testé des systèmes a déjà vécu la livraison tardive du système à tester. À presque tous les niveaux, des composants aux systèmes entiers, les développeurs rencontrent des problèmes et la livraison est soit retardée soit incomplète. Dans la plupart des cas, lorsque qu'une période est attribuée pour procéder aux tests, la date limite ne change pas et le temps de test est réduit. Ceci oblige les équipes à choisir entre la qualité et la rapidité. Pour découvrir des outils qui offrent le meilleur des deux mondes, consultez notre liste des meilleures plateformes de test logiciel.

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.

Sign up with:

LinkedInGoogleMicrosoft

Or sign up with email:

Name*

First name Last name

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Business email*

Create Password*

This field is hidden when viewing the form

LinkedIn profile

This field is hidden when viewing the form

Company's AI adoption maturity

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

Livraison partielle et incrémentale

Bien que le système complet ne puisse pas être livré pour les tests, certaines fonctionnalités — un système partiel — peuvent être livrées avec la promesse que des versions ultérieures contiendront le reste des fonctionnalités. À tout moment, l'état des fonctionnalités dans une version sera :

• Complétées comme requis : ces fonctionnalités sont testables — au moins isolément.
• Incomplètes : les fonctionnalités omettent de la fonctionnalité et/ou sont connues pour être défectueuses.
• Manquantes : reportées pour être livrées dans un prochain lot.

Concernant les fonctionnalités disponibles, il peut être possible de les tester isolément. Cependant, elles peuvent dépendre de données créées par d'autres fonctionnalités pas encore disponibles, ce qui peut compliquer leur test.

Des fonctionnalités peuvent être disponibles, mais la sortie de ces fonctionnalités ne peut pas être vérifiée par d'autres fonctionnalités non encore accessibles ; il devient alors nécessaire d'examiner la base de données de test avant et après exécution. Il est presque certain que vos tests de bout en bout impliquant des chaînes de fonctionnalités testables seront pour la plupart bloqués.

À tous égards, les tests au niveau du système de systèmes partiels sont sérieusement entravés.

Défendre le test

Votre équipe doit progresser, coûte que coûte. Si le système n'est pas disponible, ou seulement partiellement disponible pour l'équipe, il faudra gérer les attentes et défendre votre plan. 

Votre plan de test, à petite ou grande échelle, dépend de la disponibilité du système — c'est une hypothèse — donc ce plan doit changer. Vous ne documenterez peut-être pas formellement les critères d'entrée, mais le message reste le même :

Les critères d'entrée sont des hypothèses de planification – si ces critères ne sont pas remplis, vos hypothèses de planification sont erronées et le plan doit être ajusté.

Que vous attendiez la livraison du système ou que vous ayez accès à un système partiel, vous manquerez rapidement de tâches utiles à réaliser. Vous devrez alors avoir une conversation difficile avec votre responsable produit ou chef de projet. Si la date limite d'achèvement ne bouge pas, vous serez contraint de réduire les tests prévus. Certaines fonctionnalités pourraient être moins testées, voire retirées totalement du périmètre de test.

Le manager peut croire que vous pourrez rattraper le retard plus tard, mais cela est très rarement réalisable en pratique.

Le temps de test perdu en raison de livraisons tardives ou partielles ne peut pas être récupéré en 'travaillant plus dur'.

Pourquoi les tests sont-ils retardés ? Les causes sont multiples, mais elles suivent généralement l’un de ces schémas :

• Les environnements ne peuvent pas être configurés à temps. Les travaux de préparation ont commencé tard, les personnes étaient trop occupées ou pas assez qualifiées pour créer un environnement de test pertinent. Ce qui est disponible est partiel, mal configuré ou incomplet.
• La livraison est retardée car l'ampleur du travail a été sous-estimée.
• La livraison est retardée car le logiciel est bogué, difficile à tester et à corriger.
• La livraison est retardée car l’équipe de développement manque de compétences, d’expérience ou de maîtrise du domaine métier ou des technologies utilisées.
• La livraison est retardée car le développement a débuté en retard.
• La livraison est retardée car les exigences ne cessent d’évoluer.

Sont exclus de la liste ci-dessus les cas de force majeure et autres facteurs externes échappant au contrôle de l’équipe projet. Si le chef de projet insiste pour que la date de début des tests ne change pas, et que le périmètre des tests reste aussi inchangé, vous faites face à un défi de taille. Dans tous les cas ci-dessus, les causes des retards de livraison militent pour effectuer davantage de tests, non moins.

Si le travail de développement est sous-estimé, il en va probablement de même pour les tests. Si le logiciel comporte de nombreux bugs, le test prendra plus de temps. Si les développeurs manquent de compétences, le logiciel sera probablement de mauvaise qualité et plus long à tester. Si les développeurs ont commencé tard (pour quelle raison ?) et que le périmètre reste inchangé, pourquoi les tests devraient-ils être réduits ? Si les exigences changent, il est probable que vos plans soient de toute façon erronés – s’en tenir à un mauvais plan rend forcément la tâche plus compliquée.

Combien de ces causes courantes de retard de livraison suggèrent qu'il faut moins tester ? Aucune. Défendez votre plan.

Rapporter le succès et l'échec

La plupart des testeurs savent qu’un test efficace requiert de la curiosité, de la persévérance et du flair pour le problème. La motivation principale est de provoquer des échecs et de recueillir suffisamment de preuves pour que ces échecs soient reliés à des défauts qui pourront ensuite être corrigés. 

Bien que détecter (et corriger) des défauts soit bénéfique pour la qualité du produit, communiquer sur ces défauts donne souvent l’impression d’annoncer de mauvaises nouvelles à quelqu’un. Il peut s’agir d’un développeur qui s’est trompé et doit corriger son erreur, ou vous pouvez devoir signaler à des parties prenantes qu’une fonctionnalité critique ne fonctionne pas correctement et que le système sera retardé.

Personne n'aime annoncer de mauvaises nouvelles et il est naturel d'hésiter à contrarier autrui, en particulier des collègues proches. Mais la nature bonne ou mauvaise de votre message ne devrait pas préoccuper celui qui transmet l'information. 

Un défaut est toujours une mauvaise nouvelle pour quelqu’un, mais le rôle du testeur n’est pas d’être dans le jugement. À certains égards, le testeur est semblable à un journaliste qui cherche la vérité. L’histoire de l’enfant d’éléphant, écrite par Kipling, contient ces vers :

J’emploie six serviteurs honnêtes :
    (Ils m’ont tout appris ce que je sais)
Leurs noms sont Quoi et Où et Quand
    Et Comment et Pourquoi et Qui.

De la même manière qu’un journaliste raconte un fait d’actualité, vous relatez le récit de ce que vous avez découvert en testant un système.

La vérité – la nouvelle – peut être bonne ou mauvaise, mais votre responsabilité est simplement de rechercher au mieux aussi bien les problèmes que les succès. Vous tentez de découvrir ce que fait un système et comment il s’y prend. 

À la toute fin d’un projet, l’objectif est de livrer la solution en production avec le moins de problèmes non résolus possible. Vous souhaitez que tous vos tests aboutissent, mais le chemin vers le succès est semé d’échecs de tests qui doivent être investigués et résolus. Votre objectif tactique est de trouver les problèmes rapidement, mais votre objectif ultime est de n’avoir aucun problème à signaler. 

Pour rapporter fidèlement le succès ou l’échec de votre mission de test, envisagez d’intégrer des outils avancés de gestion des tests qui offrent des analyses complètes

Vous devez agir comme un journaliste d’investigation – chercher l’histoire avec un esprit critique et indépendant. Comme l’a écrit Kipling :

Si tu peux rencontrer Triomphe après Désastre, et traiter ces deux imposteurs de la même manière…

Alors, vous garderez la tête froide et ferez du bon travail pour votre projet et vos parties prenantes.

Érosion de la couverture

Quels que soient les objectifs de couverture fixés au début des tests, plusieurs facteurs contribuent à réduire la couverture réellement atteinte. Le terme « érosion » est approprié car il traduit vraiment la réduction progressive du périmètre des tests prévus et la réalisation inévitable que tous les tests planifiés ne pourront pas être exécutés dans le temps imparti.

L'érosion de la couverture a plusieurs causes avant l'exécution des tests :

• Tout d'abord, les plans de test identifient les risques à traiter et l’approche à adopter pour les traiter. Les plans supposent généralement un budget pour les tests – ce qui implique toujours un compromis.
• Des exigences, conceptions ou spécifications système incomplètes, instables ou non finalisées rendent la spécification des tests plus difficile. La couverture du système est compromise par un manque de détails dans les spécifications.
• La disponibilité tardive ou l’insuffisance des environnements de test rendent certains tests prévus impossibles à réaliser ou dépourvus de sens. Des tests d’intégration à plus grande échelle peuvent être impossibles à exécuter comme prévu parce que toutes les interfaces ou tous les systèmes d’interfaçage ne peuvent pas être mis à disposition.
• Les tests de performance peuvent être compromis parce que les environnements ne sont pas à l’échelle ou ne reflètent pas la production.
• La livraison tardive du logiciel à tester fait que, lorsque les délais restent fixes, le volume de tests réalisables doit être réduit.

L'érosion de la couverture lors de l'exécution des tests a elle aussi plusieurs causes :

• Si la qualité du logiciel à tester est médiocre à l’entrée d’une phase de test, l'exécution des tests peut devenir particulièrement frustrante. Les tests les plus basiques peuvent échouer, et les défauts trouvés peuvent être si fondamentaux que les développeurs ont besoin de plus de temps pour les corriger que prévu. Si les tests sont suspendus parce que la qualité logicielle est trop basse, vous serez en retard. Si la date limite ne change pas, certains tests seront retirés du périmètre.
• Si plus de défauts que prévu surviennent, le cycle de correction et de re-test prend plus de temps et il ne sera pas possible de terminer tous les tests dans les temps.
• Quand le temps est écoulé et que l’on décide de livrer, tous les tests ne seront pas terminés. Soit certains tests prévus n’ont pas été atteints dans le plan, soit des défauts restants bloquent l’achèvement de tests échoués. Lorsque la date de mise en production ne change pas, il s’agit du classique « écrasement » du processus de test mentionné plus haut.

Gérer l’érosion de la couverture des tests est l’un des défis auxquels les testeurs sont confrontés dans tous les projets. Les choses se passent rarement de manière fluide et diminuer le temps consacré aux tests (et leur couverture) est bien souvent la seule façon de respecter le calendrier du projet.

Il n’est pas mauvais de réduire la quantité de tests ; cela ne l’est que si on réduit arbitrairement. Par conséquent, lorsque vous faites des choix sur les tests à supprimer, l’impact sur vos objectifs de test et les risques à couvrir doit être examiné. Il vous faudra probablement avoir quelques discussions délicates avec les parties prenantes.

Lorsque l’impact est significatif, il peut être nécessaire de faciliter une réunion entre ceux qui demandent ces réductions (généralement la gestion de projet) et ceux dont les intérêts pourraient être affectés (les parties prenantes). Votre rôle consiste à exposer la situation concernant les tests réalisés, l’état connu à date du système testé, les tests qui échouent ou bloquent la progression, ainsi que la quantité de tests restant à réaliser.

Vos plans et modèles expriment le périmètre original des tests et sont essentiels pour aider les parties prenantes et la gestion à comprendre les lacunes et risques non couverts afin de décider de poursuivre ou non les tests.

Gestion des incidents

Une fois que le projet passe aux phases de test système et de test d’acceptation, il est largement guidé par les incidents survenant lors de l’exécution des tests. Les incidents déclenchent des activités pour le reste du projet, et les statistiques sur les incidents peuvent parfois donner une bonne indication de l’avancement du projet. Lors de la catégorisation des incidents, il faut anticiper l’utilisation ultérieure de ces informations.

Un incident est un événement imprévu qui survient pendant les tests et qui peut avoir une incidence sur la réussite des tests, la décision d’acceptation, ou encore nécessiter une autre action.

Nous utilisons un terme neutre pour ces événements imprévus – incident. Cependant, ces événements sont souvent désignés par d’autres termes ; certains plus neutres que d’autres. 

Les tests qui échouent peuvent être désignés comme des observations, des anomalies ou des problèmes – des termes neutres qui ne présument pas de la cause. On utilise parfois aussi les mots problèmes, bogues, défauts ou erreurs – ceux-ci supposent que le système est défectueux. Cependant, cette conclusion peut être prématurée et ces étiquettes peuvent induire en erreur.

Nous vous conseillons de réserver les termes bogue, défaut ou erreur pour les résultats du diagnostic des échecs de construction du système testé, qui nécessitent généralement des correctifs de la part de l’équipe de développement.

Les incidents se manifestent de deux façons :

1. Défaillance du système : le système ne se comporte pas comme prévu lors d’un test, c’est-à-dire qu’il échoue d’une manière ou d’une autre ou semble ne pas répondre à certaines exigences.
2. Interruption ou compromission des tests : un événement qui affecte la capacité des testeurs à terminer leurs tâches, tel que la perte ou la défaillance de l’environnement de test, des données, des interfaces ou de systèmes ou services supportant ou intégrés, ou toute autre influence externe.

Défaillance du système

Ces incidents sont souvent de la plus grande préoccupation car ils sapent la confiance dans la qualité du système. 

Interruptions et Tests Compromis

Certaines organisations ne considèrent pas ces incidents comme des incidents à part entière – les interruptions font partie du tumulte des projets arrivant à leur terme. Les tests compromis, c’est-à-dire ceux pour lesquels l’environnement ou la configuration du test sont erronés, pourraient être imputés à l’équipe de test (pour la préparation ou tout au moins pour ne pas avoir vérifié la configuration avant le test).

Dans les deux cas, l’avancement des tests est affecté et, si vous gérez le processus, vous êtes responsable d’expliquer les retards. Pour cette raison, vous devriez soit consigner ces événements en tant qu’incidents, soit demander à l’équipe de tenir un journal de test et d’y enregistrer les pannes d’environnement, les problèmes de configuration ou l’absence de versions logicielles appropriées pour assurer les tests. Si vous ne le faites pas, vous aurez du mal à justifier les retards et cela pourrait nuire à la réputation de vous-même et de votre équipe.

Faut-il consigner les incidents ou non ?

Avec l’arrivée des méthodes agiles et des approches de livraison continue, la vision traditionnelle de la gestion des incidents a été remise en question. Dans les projets classiques, les incidents sont traités comme des lots de travaux potentiels pour les développeurs, approuvés selon la gravité et/ou l’urgence. 

On suit alors un processus formel, souvent bureaucratique, où les incidents sont revus, classés par ordre de priorité, puis traités par l’équipe de développement (ou autre). Des outils sophistiqués de gestion des incidents peuvent être utilisés.

Dans de petites équipes agiles, la relation entre testeur et développeur est étroite. L’équipe dans son ensemble peut se réunir quotidiennement pour discuter des incidents majeurs mais, la plupart du temps, les bugs sont détectés, diagnostiqués, corrigés et retestés de manière informelle sans qu’il soit nécessaire de consigner un incident ou d’impliquer d’autres membres de l’équipe ou des intervenants externes. Les bogues les plus sérieux peuvent être discutés et intégrés aux travaux d’un user story, ou regroupés dans des itérations/sprints dédiés à la correction des bugs.

Nous avons discuté de l’objet et le besoin de documentation dans un article précédent. Cette discussion s’applique aussi aux incidents. L’équipe doit se demander si un outil et un processus de gestion des incidents sont nécessaires, s’ils sont utiles à l’équipe et/ou exigés par des personnes extérieures à l’équipe.

Les équipes plus importantes tendent à s’appuyer sur des processus et des outils pour gérer les incidents pour trois raisons : 

1. Pour s’assurer qu’aucun incident n’est oublié
2. Que les problèmes graves soient examinés par les parties prenantes et la gestion de projet 
3. Pour recueillir des indicateurs pouvant être utiles pendant et après le projet.

More Articles

• 9 Types de tests logiciels en ingénierie logicielle
• 5 types de tests de performance + meilleurs outils
• Tendances du Test Logiciel : Nouvelles Technologies QA, Statistiques & Données

Distinguer Urgence et Gravité

Quel que soit le processus de gestion des incidents adopté, nous recommandons d’attribuer à tous vos incidents à la fois un code de priorité et un code de gravité.

• La priorité est attribuée du point de vue des tests et influe sur le moment où un incident sera résolu. Le testeur doit décider si un incident est prioritaire ou non (ou selon tous les degrés intermédiaires permis). La priorité indique l’urgence de ce défaut pour les testeurs eux-mêmes et dépend de l’impact de cet échec sur le reste de la campagne de tests.
• La gravité est attribuée du point de vue de l’utilisateur, et indique le caractère acceptable ou non (généralement) d’un défaut. Les utilisateurs finaux ou leur direction devraient attribuer la gravité, ou (plus efficacement) l’ajuster si besoin à la vue initiale des testeurs. La gravité reflète l’impact de ce défaut sur l’entreprise s’il n’était pas corrigé avant la livraison. En général, un défaut grave rend le système inacceptable. Si un défaut est de faible gravité, il pourra être jugé trop anodin pour être corrigé avant la mise en production, mais pourra l’être dans une version ultérieure.

Si un incident arrête les tests et que les tests sont sur le chemin critique, alors c’est tout le projet qui s’arrête.

Un incident très prioritaire arrête tous les tests, et généralement le projet.

L’essentiel à retenir avec les systèmes de classification des incidents est que tout incident urgent n’est pas forcément grave, et qu’un incident grave n’est pas toujours urgent.

Gérer la phase finale (End-Game)

Nous appelons les dernières étapes de notre processus de test la « phase finale (End-Game) » car la gestion des activités de test durant ces derniers jours, parfois effrénés et stressants, requiert une discipline différente de celle, apparemment bien plus détendue, de la période de planification des tests.

N’oubliez pas, le but du test est de fournir aux parties prenantes les informations nécessaires pour leur permettre de prendre une décision – accepter, corriger, rejeter, prolonger le projet ou l’abandonner complètement. 

Si vous partagez une compréhension commune des modèles à utiliser pour les tests, il est beaucoup plus facile d’expliquer ce qui « fonctionne » (par rapport au modèle), mais aussi où les choses échouent et quels sont les risques associés à ces échecs. C’est aux parties prenantes d’utiliser ces informations pour prendre leurs décisions – guidées par vous.

L’un des avantages d’adopter une approche de test basé sur les risques est que, lorsque le temps de test est réduit, en fin de projet, nous utilisons le risque résiduel pour justifier la nécessité de continuer les tests, voire d’en ajouter davantage. 

Lorsque la direction insiste pour restreindre les tests, les testeurs devraient simplement présenter les risques qui sont « mis en balance ». Cela est beaucoup plus simple lorsqu’une analyse de risques a été réalisée en amont, utilisée pour orienter les activités de test et suivie tout au long du projet. Lorsque la direction est continuellement informée des risques résiduels, il est moins probable qu’elle impose une réduction du temps consacré aux tests.

Et voilà, c’est fini, bonne chance pour vos tests !

Inscrivez-vous à la newsletter The QA Lead pour être averti lorsque de nouveaux articles de la série seront publiés. Ces articles sont extraits de la formation Leadership in Test de Paul que nous recommandons vivement pour approfondir ce sujet et bien d’autres. Si cela vous intéresse, utilisez notre code promotionnel exclusif QALEADOFFER pour obtenir 60 $ de réduction sur le prix total de la formation !