Plan de test et stratégie de test : Les meilleures pratiques qui feront de votre développement de produit un succès

Sans une compréhension claire des processus qui se déroulent lorsqu’une équipe travaille sur un produit logiciel, il peut être tentant de penser que tous les problèmes proviennent d’ingénieurs d’assurance qualité sous-qualifiés qui cliquent au hasard et ruinent le travail acharné de l’ensemble de l’équipe. La valeur et l’objectif du processus d’assurance qualité ne sont pas transparents sans documentation. C’est là qu’un plan et une stratégie de test peuvent être utiles.

Même pour ceux qui connaissent bien les processus, il reste le problème de la mesure de la qualité fournie par les QA. Si vous ne mesurez pas la qualité, vous n’avez aucun contrôle sur le processus de test ni aucune capacité à anticiper les résultats. Comment savoir exactement ce que vous avez payé ?

L’importance d’un plan de test

Un plan de test est un contrat de sous-traitance qui vous permet de planifier les dépenses et les ressources sur une longue période, de planifier les budgets, d’analyser les performances et d’augmenter la valeur du produit. L’existence de documents d’assurance qualité contribue à un processus structuré, ce qui est largement accepté comme une meilleure pratique. Pourtant, de nombreuses équipes sautent cette étape dans leurs produits.

L’effort et le coût de correction des défauts négligés sont moindres, car le coût de correction d’un défaut augmente de manière exponentielle à chaque étape du cycle de vie. C’est pourquoi la couverture des tests et les critères méritent d’être définis de manière explicite.

Dans cet article, j’aimerais discuter des avantages de maintenir un plan de test et une stratégie de test, ainsi que des éléments les plus utiles de chaque document pour l’équipe.

Plan de test : La feuille de route vers la qualité

Un plan de test bien élaboré comporte plusieurs avantages cruciaux :

1. Coordination d’équipe simplifiée

J’ai vu des dizaines de plans et de stratégies de test, et je peux affirmer en toute confiance qu’il n’existe pas de document unique, correct et universel qui puisse être considéré comme une norme et appliqué à tous les types de projets. Le contenu de ces documents peut varier d’un projet à l’autre, et les documents eux-mêmes peuvent soit exister séparément et se référer l’un à l’autre, soit la stratégie de test peut faire partie du plan de test. Étant donné que le plan de test est mis à jour assez souvent et que la stratégie de test reste généralement inchangée pendant le projet, je préfère les diviser en deux documents.

Voici une liste des sections à inclure dans ces deux documents :

Plan de test

• Étendue des travaux

• Critères de qualité et d’acceptation

• Ressources (équipe, outils, environnements)

• Documentation de l’essai et produits livrables

• Évaluation des risques

• Description du processus

Stratégie de test

• Approche de test

• Niveaux de test

• Types de tests

• Priorités des tests de compatibilité

• Atténuation des obstacles

• Phases de test

• Vérification de la version

• Rapports

• Correctif

• Pipeline de test CI/CD

La valeur de la mise en œuvre de ces documents affecte l’ensemble de l’équipe au sens le plus large du terme, c’est-à-dire toutes les personnes impliquées dans le développement du produit. Avec l’aide d’un plan et d’une stratégie de test, il est plus facile de comprendre ce que fait une équipe d’assurance qualité et de coordonner le travail avec d’autres équipes.

2. Transfert de connaissance

Vous avez besoin de développer votre équipe et vous ne voulez pas lier toute la connaissance des produits à des membres individuels de l’équipe. Avec un plan de test et une stratégie de test bien rédigés, l’équipe a une compréhension unifiée de tous les processus de test du projet et peut travailler efficacement même en l’absence de la direction pendant un certain temps. En outre, une documentation de haut niveau permet de mettre rapidement à niveau les nouveaux venus et de synchroniser l’équipe distribuée.

Par exemple, l’intégration comprend normalement le nombre d’heures de non-production (taux multiplié par le nombre d’heures), le temps consacré par le responsable aux réunions de présentation et le temps consacré par les autres spécialistes à la mise à niveau du nouveau venu. Les documents de test vous permettent de réduire le nombre d’heures que les spécialistes des autres départements consacrent à l’intégration en prescrivant des parties des processus dans un format accepté par l’industrie, ce qui permet également de gagner du temps lors de la lecture de ces documents.

3. Gestion du projet améliorée

Les documents d’QA permettent aux gestionnaires de projet de se faire une idée complète de ce que les ingénieurs d’QA testent et comment, de la qualité attendue et de la quantité de travail qui sera effectuée par l’équipe de test à chaque phase du développement du produit, sans avoir de connaissances approfondies en matière de test.

4. Gestion des risques optimisée

Le plan de test dévoile ce dont l’équipe est responsable et ce qui n’est pas sous son contrôle. Il énumère les services et produits de tiers, les cas limites qui ne peuvent être capturés dans l’environnement de test, etc. Cela permet de gérer non seulement les risques, mais aussi les attentes.

5. Prédiction de la qualité du produit

Plusieurs fois dans ma vie professionnelle, j’ai été confronté à des situations où le produit que je gérais est devenu partenaire d’autres produits financiers ou médicaux importants. Ces organisations demandent souvent une documentation qui régit entièrement le développement du produit, y compris la gestion des risques, les plans de continuité des activités, les feuilles de route pour le développement du produit, etc. Dans la plupart des cas, un plan et une stratégie de test bien rédigés répondent parfaitement à cette demande.

6. Accès à de nouveaux marchés et clients

Les exigences en matière de sécurité des données et de l’ensemble du processus sont très élevées dans des secteurs tels que la finance et les soins de santé. C’est pourquoi ils exigent souvent des audits et des certifications, qui impliquent la formalisation de tous les processus de l’équipe du partenaire et de l’équipe de développement du produit.

Les audits et les certifications ont une incidence directe sur l’expansion de l’entreprise, car ils permettent d’accéder à un plus grand nombre de clients. Les investisseurs peuvent également demander de tels audits en vue d’une introduction en bourse, ainsi que pour mener une procédure de connaissance du client qui garantit que l’entreprise n’a jamais été impliquée dans un délit ou n’est soumise à aucune restriction.

Un plan ou une documentation de test peut être nécessaire pour couvrir les lacunes suivantes : processus de développement, employés (ressources), intégrité des données, continuité des activités, réponse aux incidents, dépendance à l’égard de tiers, résilience opérationnelle, réseau d’infrastructure, etc.

7. Synchronisation avec l’équipe de développement

Pour la mise en place d’un processus CI/CD, le plan de test comporte une section dédiée qui régule les étapes de qualité que chaque fonctionnalité accomplit avant d’être déployée en production. Ce processus est invisible pour les parties prenantes et se déroule en mode automatique, mais il est crucial pour garantir que tout se passe bien. En utilisant cette section du plan de test, les développeurs peuvent trouver des réponses aux questions concernant les cas dans lesquels la fonctionnalité développée sera testée, le retour au développement, la spécification de l’étape et de l’environnement, le niveau de couverture des tests unitaires attendu et les portes de qualité qui seront configurées lorsque le code passera d’un environnement à l’autre.

Erreurs fréquentes dans la documentation des tests

Quoi (doit être testé), quand, qui (testera), et avec l’aide de quoi – si vous ne pouvez pas répondre à l’une de ces questions, il y a certainement des lacunes et un risque élevé de négliger des bogues.

J’examinerai ici des exemples montrant comment des éléments mal sélectionnés ou l’absence d’éléments correctement sélectionnés peuvent nuire au projet et ce qu’il faut rechercher dans le plan et la stratégie de test.

Exemple n° 1 : Transfert de connaissances difficile

Votre équipe s’est agrandie et il est devenu difficile de transférer des informations sur les processus. Le nombre de problèmes a augmenté et tous les processus de développement ont ralenti. Malgré le manque de temps consacré au projet, vous gagnerez beaucoup plus de temps en introduisant la documentation des tests : les ingénieurs QA nouvellement recrutés peuvent lire vos processus de manière autonome et revenir à leur description si nécessaire.

Exemple n° 2 : Critères de qualité vagues

Imaginez la situation suivante : le projet avait des critères de sortie vagues. Chaque membre de l’équipe les a interprétés à sa manière, ce qui a entraîné l’apparition de bogues importants dans la version. En conséquence, la sortie du produit a dû être reportée de quelques semaines, parce que l’équipe a enregistré le mauvais niveau de gravité.

Ce n’est qu’un exemple de la manière dont des critères de qualité incomplets peuvent affecter le développement d’un produit. Si vous avez déjà rencontré un tel problème, il est temps de penser à formaliser les critères de qualité et d’acceptation dans la section du plan de test.

Exemples de bons critères de validation :

• « Tous les tickets du carnet de commandes sont implémentés, déployés et testés conformément aux critères d’acceptation et à la description du ticket.

• « L’ensemble des tests manuels et automatisés ont été passés avec succès après le gel du code.

• « Tous les scénarios E2E sont terminés.

• « Tous les scripts qui ont échoué ont été analysés et des rapports de bogues ont été ajoutés au système de suivi des bogues.

• « Les tests de compatibilité ont été réussis conformément à la liste prioritaire des navigateurs et des systèmes d’exploitation décrite dans la stratégie de test.

• « Aucun bogue ouvert avec une priorité critique ou majeure.

Exemple n° 3 : Gestion des risques négligée

Pendant les tests, l’équipe peut rencontrer divers problèmes susceptibles d’affecter le calendrier ou la qualité : abandon de l’environnement de test, congé de maladie d’un membre de l’équipe, gel inattendu du code, mauvais détail des exigences, modifications des exigences alors qu’elles sont à moitié terminées, et ainsi de suite. L’équipe doit disposer d’un plan d’urgence pour minimiser les dommages causés par le risque déclenché et d’un plan de contre-mesures pour prévenir de tels risques. C’est pourquoi je pense que l’évaluation des risques est l’une des sections les plus importantes du plan de test. Elle consiste en une liste de risques, leur probabilité, leur impact sur le processus de test, leur priorité et un plan de réponse.

Conclusion

Cela peut sembler évident, mais un plan et une stratégie de test sont essentiels – même si vous avez l’impression de vous en sortir très bien sans eux. Essayez d’intégrer des documents d’QA dans votre flux de travail et vous constaterez rapidement à quel point ils contribuent à réduire le nombre d’erreurs, de malentendus et le temps de travail, car vous ne ferez plus de double travail et ne manquerez plus d’étapes.