Comment faire

Comment rédiger un document de stratégie de test (avec un exemple de modèle de stratégie de test)

Apprenez à rédiger efficacement un document de stratégie de test

Un plan stratégique pour définir l’approche de test, ce que vous voulez accomplir et comment vous allez y parvenir.

Ce document supprime toutes les incertitudes ou les déclarations d’exigences vagues avec un plan d’approche clair pour atteindre les objectifs du test. La stratégie de test est l’un des documents les plus importants pour l’équipe d’assurance qualité.

=> Cliquez ici pour une série de didacticiels sur le plan de test complet

Rédaction d’un document de stratégie de test

Stratégie de test

Rédiger efficacement une stratégie de test est une compétence que chaque testeur devrait acquérir au cours de sa carrière. Il initie votre processus de réflexion qui aide à découvrir de nombreuses exigences manquantes. Les activités de réflexion et de planification des tests aident l’équipe à définir la portée des tests et la couverture des tests.

Il aide les responsables de test à obtenir l’état clair du projet à tout moment. Les chances de manquer une activité de test sont très faibles lorsqu’une stratégie de test appropriée est en place.

L’exécution des tests sans aucun plan fonctionne rarement. Je connais des équipes qui rédigent des documents de stratégie mais ne s’y réfèrent jamais lors de l’exécution des tests. Le plan de stratégie de test doit être discuté avec l’ensemble de l’équipe afin que l’équipe soit cohérente avec son approche et ses responsabilités.

Dans des délais serrés, vous ne pouvez pas simplement renoncer à toute activité de test en raison de la pression du temps. Il doit au moins passer par un processus formel avant de le faire.

Qu’est-ce qu’une stratégie de test ?

La stratégie de test signifie « Comment allez-vous tester l’application ? » Vous devez mentionner le processus/la stratégie exacte que vous allez suivre lorsque vous recevrez la demande de test.

Je vois de nombreuses entreprises qui suivent très strictement le modèle de stratégie de test. Même sans modèle standard, vous pouvez garder ce document de stratégie de test simple mais toujours efficace.

Stratégie de test vs. Plan de test

Au fil des ans, j’ai vu beaucoup de confusion entre ces deux documents. Commençons donc par les définitions de base. En général, peu importe ce qui vient en premier. Le document de planification de test est une combinaison de stratégie branchée avec un plan de projet global. Selon la norme IEEE 829-2008, le plan stratégique est un sous-élément d’un plan de test.

Chaque organisation a ses propres normes et processus pour maintenir ces documents. Certaines organisations incluent des détails de stratégie dans le plan de test lui-même (voici un bon exemple). Certaines organisations répertorient la stratégie en tant que sous-section dans un plan de test, mais les détails sont séparés dans différents documents de stratégie de test.

La portée du projet et l’objectif du test sont définis dans le plan de test. Fondamentalement, il traite de la couverture des tests, des fonctionnalités à tester, des fonctionnalités à ne pas tester, de l’estimation, de la planification et de la gestion des ressources.

Alors que la stratégie de test définit des lignes directrices pour l’approche de test à suivre afin d’atteindre les objectifs de test et l’exécution des types de test définis dans le plan de test. Il traite des objectifs de test, des approches, des environnements de test, des stratégies et des outils d’automatisation et de l’analyse des risques avec un plan d’urgence.

Pour résumer, le Plan de Test est une vision de ce que vous voulez réaliser et la Stratégie de Test est un plan d’action conçu pour réaliser cette vision !

J’espère que cela dissipera tous vos doutes. James Bach a plus de discussion sur ce sujet ici.

Processus pour développer un bon document de stratégie de test

Ne vous contentez pas de suivre les modèles sans comprendre ce qui fonctionne le mieux pour votre projet. Chaque client a ses propres exigences et vous devez vous en tenir aux choses qui fonctionnent parfaitement pour vous. Ne copiez aveuglément aucune organisation ni aucune norme. Assurez-vous toujours que cela vous aide, vous et vos processus.

Vous trouverez ci-dessous un exemple de modèle de stratégie qui décrira ce qui devrait être couvert dans ce plan ainsi que quelques exemples pour illustrer ce qu’il est logique de couvrir sous chaque composante.

Stratégie de test en STLC :

STLC

[image source]

Sections communes du document de stratégie de test

Étape 1 : portée et aperçu

Présentation du projet ainsi que des informations sur les personnes qui doivent utiliser ce document. Incluez également des détails tels que qui examinera et approuvera ce document. Définir les activités et les phases de test à effectuer avec des échéanciers par rapport aux échéanciers globaux du projet définis dans le plan de test.

Étape 2 : Approche de test

Définissez le processus de test, le niveau de test, les rôles et les responsabilités de chaque membre de l’équipe.

Pour chaque type de test défini dans le plan de test (Par example, Tests d’unité, d’intégration, de système, de régression, d’installation/désinstallation, d’utilisabilité, de charge, de performance et de sécurité) décrivent pourquoi il doit être effectué ainsi que des détails tels que le moment où commencer, le propriétaire du test, les responsabilités, l’approche de test et les détails de la stratégie et de l’outil d’automatisation le cas échéant.

Lors de l’exécution des tests, il existe diverses activités telles que l’ajout de nouveaux défauts, le triage des défauts, les affectations de défauts, les nouveaux tests, les tests de régression et enfin l’approbation des tests. Vous devez définir les étapes exactes à suivre pour chaque activité. Vous pouvez suivre le même processus qui a fonctionné pour vous lors de vos cycles de test précédents.

Une présentation Visio de toutes ces activités incluant un certain nombre de testeurs et qui travaillera sur quelles activités serait très utile pour comprendre rapidement les rôles et responsabilités de l’équipe.

Par example, cycle de gestion des défauts – mentionnez le processus pour enregistrer le nouveau défaut. Où se connecter, comment consigner les nouveaux défauts, quel devrait être le statut du défaut, qui doit effectuer le triage des défauts, à qui attribuer les défauts après le triage, etc.

Définissez également le processus de gestion du changement. Cela inclut la définition des soumissions de demande de changement, des modèles à utiliser et des processus pour gérer la demande.

Étape 3 : environnement de test

La configuration de l’environnement de test doit fournir des informations sur le nombre d’environnements et la configuration requise pour chaque environnement. Par example, un environnement de test pour l’équipe de test fonctionnel et un autre pour l’équipe UAT.

Définissez le nombre d’utilisateurs pris en charge dans chaque environnement, les rôles d’accès pour chaque utilisateur, les exigences logicielles et matérielles telles que le système d’exploitation, la mémoire, l’espace disque libre, le nombre de systèmes, etc.

La définition des exigences en matière de données de test est tout aussi importante. Fournissez des instructions claires sur la façon de créer des données de test (générez des données ou utilisez des données de production en masquant les champs pour la confidentialité).

Définir la stratégie de sauvegarde et de restauration des données de test. La base de données de l’environnement de test peut rencontrer des problèmes en raison de conditions non gérées dans le code. Je me souviens des problèmes auxquels nous avons été confrontés sur l’un des projets lorsqu’aucune stratégie de sauvegarde de base de données n’était définie et que nous avons perdu toutes les données en raison de problèmes de code.

Le processus de sauvegarde et de restauration doit définir qui effectuera les sauvegardes quand effectuer une sauvegarde, ce qu’il faut inclure dans la sauvegarde quand restaurer la base de données, qui la restaurera et les étapes de masquage des données à suivre si la base de données est restaurée.

Étape 4 : outils de test

Définir les outils de gestion et d’automatisation des tests requis pour l’exécution des tests. Pour les tests de performances, de charge et de sécurité, décrivez l’approche de test et les outils requis. Indiquez s’il s’agit d’un outil open source ou commercial et combien d’utilisateurs sont pris en charge et planifiez en conséquence.

Étape #5 : Libérer le contrôle

Comme mentionné dans notre article UAT, les cycles de publication non planifiés peuvent entraîner des versions logicielles différentes dans les environnements de test et UAT. Le plan de gestion des versions avec un historique des versions approprié garantira l’exécution des tests de toutes les modifications dans cette version.

Par example, définir le processus de gestion des builds qui répondra – où la nouvelle build doit être disponible, où elle doit être déployée, quand obtenir la nouvelle build, d’où obtenir la build de production, qui donnera le feu vert, le signal de non-droit pour la production libération, etc.

Étape #6 : Analyse des risques

Énumérez tous les risques que vous envisagez. Fournissez un plan clair pour atténuer ces risques ainsi qu’un plan d’urgence au cas où vous verriez ces risques dans la réalité.

Étape n°7 : Examen et approbations

Lorsque toutes ces activités sont définies dans le plan de stratégie de test 1, elles doivent être examinées pour approbation par toutes les entités impliquées dans la gestion de projet, l’équipe commerciale, l’équipe de développement et l’équipe d’administration du système (ou de gestion de l’environnement).

Un résumé des modifications apportées à l’examen doit être enregistré au début du document avec le nom, la date et le commentaire de l’approbateur. En outre, il s’agit d’un document évolutif, ce qui signifie qu’il doit être continuellement révisé et mis à jour avec des améliorations du processus de test.

Conseils simples pour rédiger un document de stratégie de test

  • Inclure l’historique du produit dans le document de stratégie de test. Répondez au premier paragraphe de votre document de stratégie de test – Pourquoi les parties prenantes veulent-elles développer ce projet ? Cela nous aidera à comprendre et à prioriser les choses rapidement.
  • Dressez la liste de toutes les fonctionnalités importantes que vous allez tester. Si vous pensez que certaines fonctionnalités ne font pas partie de cette version, mentionnez-les sous l’étiquette « Fonctionnalités à ne pas tester ».
  • Écrivez une approche de test pour votre projet. Indiquez clairement quel type de test vous allez effectuer ?
    c’est-à-dire les tests fonctionnels, les tests d’interface utilisateur, les tests d’intégration, les tests de charge/stress, les tests de sécurité, etc.
  • Répondre à des questions telles que comment allez-vous effectuer des tests fonctionnels ? Tests manuels ou automatisés ? Allez-vous exécuter tous les cas de test à partir de votre outil de gestion de test ?
  • Quel outil de suivi des bogues allez-vous utiliser ? Quel sera le processus lorsque vous découvrirez un nouveau bug ?
  • Quels sont vos critères d’entrée et de sortie de test ?
  • Comment suivrez-vous la progression de vos tests ? Quelles métriques allez-vous utiliser pour suivre l’achèvement des tests ?
  • Répartition des tâches – Définissez les rôles et les responsabilités de chaque membre de l’équipe.
  • Quels documents allez-vous produire pendant et après la phase de test ?
  • Quels risques voyez-vous dans l’achèvement du test ?
  • Conclusion

    La stratégie de test n’est pas un morceau de papier. C’est le reflet de toutes les activités d’assurance qualité dans le cycle de vie des tests logiciels. Référez-vous à ce document de temps en temps pendant le processus d’exécution du test et suivez le plan jusqu’à la sortie du logiciel.

    Lorsque le projet approche de sa date de sortie, il est assez facile de réduire les activités de test en ignorant ce que vous avez défini dans le document de stratégie de test. Cependant, il est conseillé de discuter avec votre équipe pour savoir si la réduction d’une activité particulière aidera ou non à la publication sans risque potentiel de problèmes majeurs après la publication.

    La plupart des équipes agiles réduisent la rédaction de documents de stratégie car l’équipe se concentre sur l’exécution des tests plutôt que sur la documentation.

    Mais avoir un plan de stratégie de test de base aide toujours à planifier et à atténuer clairement les risques impliqués dans le projet. Les équipes agiles peuvent capturer et documenter toutes les activités de haut niveau pour terminer l’exécution des tests à temps et sans aucun problème.

    Je suis sûr que développer un bon plan de stratégie de test et s’engager à le suivre améliorera certainement le processus de test et la qualité du logiciel. Ce serait avec plaisir que cet article vous inspire pour rédiger un plan de stratégie de test pour votre projet !

    Si vous aimez cet article, n’hésitez pas à le partager avec vos amis !

    => Visitez ici pour une série de didacticiels sur le plan de test complet

    Back to top button