Leadership en Test : Exécution d’un Projet de Test

Êtes-vous prêt ?

Gladiateurs, le moment est venu de passer à l'action. Le but de cet article est de vous guider dans l’exécution d’un projet de test. Voici les sujets abordés :

• La pression classique sur les tests
• Rapport sur la réussite et l’échec
• Érosion de la couverture
• Gestion des incidents
• Gestion de la phase finale

Alors, êtes-vous prêt ? Il y a quatre aspects critiques :

• Personnes – votre équipe est-elle prête ?
• Environnements – disposez-vous des technologies, des données, des appareils, des interfaces nécessaires pour réaliser des tests pertinents ?
• Connaissances – avez-vous préparé vos tests avec un niveau de détail approprié ou votre équipe est-elle prête et capable d'explorer et de tester le système de manière dynamique ?
• Système à tester – le logiciel ou le système à tester est-il réellement disponible ?

Les trois premiers aspects sont sous votre contrôle ou vous avez les moyens d'assurer la surveillance, la gestion et la coordination pour fournir les personnes, environnements et connaissances nécessaires. Le système à tester est une autre question. Si ce dernier est livré en retard, il n’est alors pas possible de commencer les tests de façon significative. C’est la pression classique qui s’exerce sur la phase de test.

La pression classique sur les tests

Toute personne qui a testé des systèmes a déjà connu la livraison tardive du système à tester. À presque tous les niveaux, des composants aux systèmes entiers, les développeurs rencontrent des problèmes, ce qui conduit à des livraisons retardées ou incomplètes. La plupart du temps, lorsqu’une période dédiée aux tests a été planifiée, l’échéance de fin de projet n’est pas repoussée pour autant et la phase de test se retrouve comprimée. Cela oblige les équipes à choisir entre la qualité et la rapidité. Pour des outils alliant ces deux qualités, consultez notre liste des meilleures plateformes de test logiciel.

A WEEKLY 5 MINUTE READ

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

Company

This field is for validation purposes and should be left unchanged.

Your email*

By submitting you agree to receive occasional emails and acknowledge our Privacy Policy. You can unsubscribe at anytime.

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 les versions suivantes intégreront les fonctionnalités restantes. À tout moment, l’état des fonctionnalités d’une version peut être :

• Terminées comme prévu : ces fonctionnalités sont testables – au moins isolément.
• Incomplètes : des fonctionnalités sont manquantes et/ou des bugs connus existent.
• Absentes : reportées à une prochaine version.

Concernant les fonctionnalités disponibles, il peut être possible de les tester individuellement. Cependant, elles peuvent dépendre de données créées par d’autres fonctionnalités encore indisponibles, rendant leur test plus difficile.

Des fonctionnalités peuvent être présentes, mais leur résultat ne peut pas être vérifié par d’autres fonctionnalités encore non livrées, il est donc nécessaire d’analyser la base de données de test avant et après. Il est presque certain que la majorité de vos tests de bout en bout nécessitant des enchaînements de fonctionnalités testables seront totalement bloqués.

Sous presque tous les aspects, la phase de test au niveau système des systèmes partiels est sévèrement compromise.

Défendre la phase de test

Votre équipe doit progresser, quoiqu’il arrive. Si le système n’est pas disponible, ou seulement partiellement accessible, il faudra gérer les attentes et défendre votre plan. 

Votre plan de test, qu’il concerne des tests unitaires ou globaux, suppose que le système soit disponible – c’est une hypothèse – donc votre plan devra évoluer. Vous ne formalisez peut-être pas de critères d’entrée officiels, 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 respectés, 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 allez rapidement manquer de tâches utiles à accomplir. Vous devrez alors avoir une conversation difficile avec votre product owner ou chef de projet. Si la date limite d'achèvement ne change pas, vous serez forcé de réduire le temps consacré aux tests. Certaines fonctionnalités pourront être moins testées, voire exclues totalement des phases de test.

Le responsable peut croire que vous pourrez rattraper le temps perdu plus tard, mais cela s'avère rarement réalisable en pratique.

Le temps de test perdu à cause 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 nombreuses, mais elles suivent généralement l'un de ces schémas :

• Les environnements ne peuvent pas être configurés à temps. Les équipes ont débuté trop tard, étaient trop occupées ou n'étaient pas suffisamment 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 parce que l'ampleur du travail a été sous-estimée.
• La livraison est retardée parce que 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émarré en retard.
• La livraison est retardée parce que les exigences ne cessent de changer.

Sont exclus de cette liste les catastrophes naturelles et autres facteurs externes échappant au contrôle de l’équipe projet. Si le chef de projet insiste pour ne pas modifier la date de fin des tests et garder le périmètre fixé, le défi est de taille. Dans tous les cas évoqués, les raisons du retard plaident pour réaliser plus de tests, pas moins.

Si le travail de développement est sous-estimé, il y a de fortes chances que ce soit aussi le cas pour les tests. Si le logiciel comporte des bogues, les tests prendront plus de temps. Si les développeurs manquent de compétences, le logiciel sera probablement de moindre qualité et nécessitera davantage de tests. Si les développeurs ont commencé en retard (pourquoi ?) et que le périmètre reste inchangé, pourquoi faudrait-il réduire les tests ? Si les exigences évoluent, il est probable que vos plans soient incorrects de toute façon – travailler sur de mauvaises bases ne fait qu’aggraver la situation.

Combien des causes courantes de retard de livraison suggèrent qu’il faut moins de tests ? Aucune. Défendez votre plan.

Rapport sur la réussite et l’échec

La plupart des testeurs savent qu’un test efficace nécessite curiosité, persévérance, et un certain flair pour repérer les problèmes. La principale motivation est de provoquer des défaillances et de collecter suffisamment de preuves pour que les défauts puissent être tracés puis corrigés. 

Même si trouver (et corriger) des défauts améliore la qualité du produit, communiquer ces défauts donne souvent l’impression d’annoncer une mauvaise nouvelle à quelqu’un. Il peut s’agir d’un développeur qui a commis une erreur et doit la corriger, ou bien d’informer les parties prenantes que des fonctionnalités critiques ne fonctionnent pas correctement et que le système sera donc retardé.

Personne n’aime porter de mauvaises nouvelles et il est naturel d’hésiter à contrarier ses collègues, surtout proches. Mais le sentiment que votre information soit positive ou négative ne devrait pas concerner le messager. 

Les défauts sont toujours une mauvaise nouvelle pour quelqu’un, mais le rôle du testeur n'est pas d'être juge en la matière. D’un certain point de vue, le testeur ressemble à un journaliste en quête de vérité. L’histoire de l’Enfant d’Éléphant de Kipling contient les lignes suivantes :

J’ai six serviteurs honnêtes :
    (Ils m’ont tout appris)
Leur nom est Quoi et Où et Quand
    Et Comment, Pourquoi et Qui.

De la même façon qu’un journaliste raconte une actualité, vous racontez ce que vous avez découvert en testant un système.

La vérité — l’information — peut être bonne ou mauvaise, mais votre responsabilité est de rechercher au mieux les problèmes comme les succès. Vous tentez de découvrir ce qu’un système fait et comment il le fait. 

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

Pour rendre compte de la réussite ou de l’échec de votre projet de test avec précision, envisagez d’intégrer des outils avancés de gestion des tests offrant des analyses complètes

Vous devez agir comme un journaliste d’investigation : chercher l’information 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 façon …

Alors vous garderez la tête froide, et vous rendrez un fier service à votre projet et à vos parties prenantes.

Érosion de la couverture

Quel que soit l'objectif de couverture défini au début des tests, plusieurs facteurs contribuent à réduire la couverture réellement atteinte. Érosion est un terme approprié car il reflète parfaitement la réduction progressive de l'étendue des tests prévus et la réalisation inévitable que tous les tests planifiés ne pourront être exécutés dans le temps imparti.

L’érosion de la couverture a plusieurs causes avant même l’exécution des tests :

• Premièrement, les plans de test identifient les risques à traiter et la démarche à adopter pour les adresser. Les plans supposent généralement un budget pour les tests – il s’agit toujours d’un compromis.
• Des exigences, conceptions ou spécifications du système de mauvaise qualité, instables ou inachevées rendent la spécification des tests plus difficile. La couverture du système est compromise par le manque de détails dans les spécifications.
• La disponibilité tardive ou l’insuffisance des environnements de test rendent certains tests prévus irréalisables ou dénués de sens. Les tests d'intégration à grande échelle peuvent s’avérer impossibles à exécuter comme prévu car toutes les interfaces ou systèmes interfacés ne sont pas forcément disponibles.
• Les tests de performance peuvent être compromis parce que les environnements manquent d’envergure ou ne reflètent pas la production.
• La livraison tardive du logiciel à tester signifie que, les délais demeurant inchangés, la quantité de tests à réaliser doit être réduite.

L’érosion de la couverture lors de l’exécution des tests a également plusieurs causes :

• Si la qualité du logiciel à tester est médiocre à l’entrée d’une phase de test, exécuter les tests peut être particulièrement frustrant. Les tests les plus basiques peuvent échouer, et les défauts détectés être tellement fondamentaux que les développeurs nécessitent plus de temps que prévu pour les corriger. Si les tests sont suspendus en raison d’une qualité logicielle insuffisante, vous prendrez du retard. Si l’échéance ne bouge pas, certains tests seront retirés du périmètre.
• Lorsque plus de défauts que prévu apparaissent, le cycle de correction et de re-test prend plus de temps et vous manquerez de temps pour terminer tous vos tests.
• Quand le temps vient à manquer et que la décision de livrer est prise, tous les tests ne seront pas achevés. Soit certains tests n’ont jamais été atteints dans le plan, soit quelques défauts bloquent la réalisation des tests échoués. Lorsque la date de mise en production n'est pas repoussée, il s’agit de la classique contrainte mentionnée plus haut.

Faire face à 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 sans accroc, et la réduction du temps consacré aux tests (et donc de la couverture) est habituellement la seule option pour maintenir le projet sur les rails.

Il n’est pas mauvais de réduire la quantité de tests ; il est seulement erroné de les supprimer arbitrairement. Par conséquent, au moment de faire des choix sur les tests à supprimer, il faut analyser l’impact sur vos objectifs de test et sur les risques à couvrir. Des discussions difficiles avec les parties prenantes pourraient alors être nécessaires.

Lorsque l’impact est important, il peut être nécessaire d’organiser une réunion entre ceux qui demandent des coupes (généralement la gestion de projet) et ceux dont les intérêts peuvent être affectés (les parties prenantes). Votre rôle est d’exposer la situation en ce qui concerne les tests complétés, l’état actuel connu du système testé, les tests échoués et/ou bloqués, ainsi que la quantité de tests restant à effectuer.

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

Gestion des incidents

Lorsque le projet bascule en phases de tests système puis d’acceptation, il est en grande partie rythmé par les incidents qui surviennent pendant l’exécution des tests. Les incidents déclenchent des actions pour la suite du projet et les statistiques d’incidents peuvent parfois fournir un bon aperçu de l’état du projet. Lorsque nous catégorisons les incidents, nous devons anticiper la façon dont cette information sera exploitée par la suite.

Un incident est un événement imprévu qui survient pendant les tests et qui peut avoir une incidence sur leur achèvement, la décision d’acceptation ou la nécessité de prendre toute autre mesure.

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

Des tests échoués peuvent être qualifiés d’observations, d’anomalies ou de problèmes – des termes neutres qui ne présument pas d’une cause. Mais parfois, on parle de problèmes, bogues, défauts ou fautes – ce qui suppose que le système est défectueux. Cependant, il peut s’agir d’une conclusion prématurée et ces étiquettes peuvent induire en erreur.

Nous vous suggérons de réserver les termes bogue, défaut ou faute aux diagnostics d’échecs dans la construction du système testé, qui entraînent généralement des correctifs pour l’équipe de développement.

Les incidents se manifestent de deux manières :

1. Défaillance du système : le système ne se comporte pas comme prévu au cours d’un test, c’est-à-dire qu’il échoue d’une certaine manière ou semble ne pas satisfaire à une exigence.
2. Interruption ou remise en cause des tests : un événement qui affecte la capacité des testeurs à effectuer leurs tâches, comme la perte ou l’indisponibilité de l’environnement de test, de données, d’interfaces, de systèmes ou services intégrés ou toute autre influence externe.

Défaillance du système

Ces incidents sont souvent ceux qui préoccupent le plus directement, car ils sapent la confiance dans la qualité du système. 

Interruptions et tests compromis

Certaines organisations ne considèrent même pas ces incidents comme des incidents – les interruptions font partie du tumulte inévitable des projets en phase de finalisation. Quant aux tests compromis, lorsque l’environnement ou la configuration de test est incorrect, l’équipe de test peut être rendue responsable (soit pour la mise en place, soit pour ne pas avoir vérifié avant de tester).

Dans les deux cas, l’avancement des tests est affecté et, si vous gérez le processus, vous êtes responsable d’expliquer les retards. C’est pourquoi vous devez soit enregistrer ces événements comme incidents, soit demander à l’équipe de tenir un journal des tests et d’y consigner les interruptions de l’environnement, les problèmes de configuration ou le manque de versions logicielles appropriées pour les tests. Sinon, il vous sera difficile de justifier les retards de progression et cela pourrait nuire à votre réputation, ainsi qu’à celle de votre équipe.

Faut-il enregistrer les incidents ou non ?

Avec l’avènement des approches agiles et de la livraison continue, la vision traditionnelle de la gestion des incidents a été remise en question. Dans les projets en étapes, les incidents sont considérés comme des lots de travaux potentiels pour les développeurs, approuvés selon la gravité et/ou l’urgence. 

Il existe un processus formel, souvent bureaucratique, à suivre où les incidents sont examinés, priorisés et pris en charge par l’équipe de développement (ou autre). Des outils sophistiqués de gestion des incidents peuvent être utilisés.

Dans les petites équipes agiles, la relation entre testeur et développeur est étroite. L’équipe entière peut se réunir quotidiennement pour discuter des incidents majeurs mais, bien souvent, les bugs sont détectés, diagnostiqués, corrigés et retestés de façon informelle sans aucun besoin d’enregistrer un incident ou d’impliquer d’autres membres de l’équipe ou des intervenants externes de l’entreprise ou de l’IT. Les bugs plus sérieux peuvent être discutés et intégrés aux travaux d’une user story, ou regroupés dans des itérations ou sprints dédiés à la correction de bugs.

Nous avons abordé le but et la nécessité de la documentation dans un article précédent. Cette réflexion s’applique aussi aux incidents. L’équipe doit se demander si un outil et un processus de gestion des incidents sont nécessaires et si cela est utile à l’équipe et/ou imposé par des personnes extérieures à l’équipe.

Les grandes équipes s’appuient souvent sur des processus et outils pour gérer les incidents pour trois raisons : 

1. Pour garantir que les incidents ne soient pas oubliés
2. Pour que les problèmes graves soient examinés par les parties prenantes et la gestion de projet 
3. Pour recueillir des métriques qui pourraient être précieuses pendant et après le projet.

Distinguer l’urgence de la gravité

Quel que soit le processus de gestion des incidents que vous adoptez, nous recommandons d’attribuer à chacun de vos incidents un code de priorité et un code de gravité.

• La priorité est attribuée du point de vue du test et influence quand un incident sera résolu. Le testeur doit décider si un incident est prioritaire ou non (ou selon les degrés intermédiaires éventuellement prévus). La priorité indique le caractère urgent de ce défaut pour les testeurs eux-mêmes et dépend de l’impact de l’échec du test sur le reste des tests.
• La gravité est attribuée du point de vue de l’utilisateur et indique si (en général) un défaut est acceptable ou non. Ce sont les utilisateurs finaux ou leur management qui doivent définir la gravité, ou (de façon plus efficace) corriger si besoin la première estimation des testeurs. La gravité reflète l’impact qu’aurait ce défaut sur l’entreprise s’il n’était pas corrigé avant la livraison. Typiquement, un défaut grave rend le système inacceptable. Si un défaut est de faible gravité, il peut être considéré comme trop mineur pour justifier une correction avant la mise en production, mais pourra l’être dans une version ultérieure.

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

Un incident de haute priorité arrête tous les tests, et généralement le projet.

L’essentiel à retenir au sujet des schémas de classification des incidents est que tout incident urgent n’est pas forcément grave et que tout incident grave n’est pas forcément urgent.

Gérer la phase finale

Nous appelons les dernières étapes de notre processus de test la « phase finale » car la gestion des activités de test durant ces journées finales, souvent frénétiques et stressantes, exige une discipline différente de celle des premières phases — en apparence bien plus relaxantes — de la planification des tests.

Rappelez-vous, l’objectif des tests est de fournir des informations aux parties prenantes pour leur permettre de prendre une décision – accepter, corriger, rejeter, prolonger le projet ou l’abandonner totalement. 

Si vous partagez une compréhension commune des modèles utilisés pour les tests, il sera bien plus facile d’expliquer ce qui « fonctionne » (par rapport au modèle), ainsi que de souligner ce qui ne fonctionne pas et les risques liés à ces échecs. C’est ensuite aux parties prenantes d’utiliser ces informations pour prendre leurs décisions – guidées par vous.

L’un des avantages de l’approche test basé sur les risques est que, lorsque le temps de test vient à manquer en fin de projet, nous utilisons le risque résiduel pour argumenter la poursuite ou même l’ajout de nouveaux tests. 

Lorsque la direction insiste pour réduire la phase de test, les testeurs devraient simplement présenter les risques qui sont ainsi « compromis ». Cela est beaucoup plus facile lorsqu’une évaluation des risques a été réalisée tôt, utilisée pour orienter les activités de test, et suivie tout au long du projet. Lorsque la direction reste continuellement informée des risques résiduels, il est moins probable qu’elle cherche à réduire la phase de test dès le départ.

Et voilà, bonne chance avec vos tests !

Inscrivez-vous à la newsletter The QA Lead pour être averti lorsque de nouvelles parties de la série sont publiées. Ces articles sont des extraits du cours Leadership In Test de Paul que nous vous recommandons vivement pour approfondir celui-ci et d’autres sujets. 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 !