Temps de lecture : 1 Minutes
Ce que nous négligeons lors de la construction de notre stratégie de test de bout en bout
Il va sans dire que la documentation d’une stratégie de test clairement articulée aide à garantir la qualité du logiciel. Il y a tellement de blogs sur le sujet, et il y a des principes fondamentaux qui doivent être suivis lors de l’approche d’une stratégie de test.
En règle générale, une stratégie de test devrait avoir :
- Objectifs/portée des tests
- Aperçu clair du projet
- Risques liés au projet
- Ressources de test
- Test schedule
Cela devrait également aider à identifier les domaines où des tests supplémentaires peuvent être nécessaires. Rédiger une stratégie de test efficace est une compétence que les testeurs acquièrent avec l’expérience. Par conséquent, la possibilité de manquer une activité de test est très faible lorsqu’une stratégie de test appropriée est définie.
Stratégie de test de bout en bout
La stratégie de test de bout en bout définit la couverture de test pour l’ensemble de l’application et garantit que le flux de données est maintenu pour toutes sortes d’actions de l’utilisateur final.
Les testeurs doivent toujours s’assurer que la stratégie de test de bout en bout couvre tout ce dont un client a besoin et, parfois, peut même aller plus loin que nécessaire pour lui fournir un produit satisfaisant.
Cet article fournira un aperçu de ce qui devrait être inclus dans une stratégie de test, ce que nous négligeons lors de la construction d’une stratégie de test et comment en créer une qui fonctionnera pour votre projet.
Formuler une stratégie de test E2E
Une image représentant les composants de la stratégie de test
#Portée des tests et aperçu
Celui-ci doit contenir la portée principale du projet et les informations générales sur les personnes qui accéderont à ce document, ainsi que des détails tels que : qui examinera et approuvera ces documents.
Les personnes qui réviseront généralement la stratégie de test :
- Chef d’équipe de test
- Directeur du développement
- Responsable analyste qualité
- Chef de produit
#Approche de test
Le composant suivant de la stratégie de test concerne l’approche de test. Ce qui suit peut vous aider à démarrer.
- Processus de test
- Rôle et responsabilité au sein de l’équipe d’AQ
- Processus de gestion du changement
- Types de tests pouvant être présentés au client
- Techniques d’essai
- Mécanismes de traitement des défauts
- Validation du test
#Environnements de test
L’environnement de test spécifie – les environnements dans lesquels les types de test auront lieu ainsi que les configurations.
Il doit spécifier des instructions sur la création de données de test et le processus de récupération des données. Une stratégie de test faible avec des informations incomplètes peut entraîner des déploiements finaux en proie à des défauts et des erreurs.
#Outils de test
Un élément essentiel d’un document de stratégie de test car il contient les informations sur les outils d’automatisation et de gestion des tests pour effectuer l’exécution des tests.
Détermine le ratio d’outils open source et commerciaux pour assurer des paramètres non fonctionnels tels que la sécurité, les performances, la convivialité et le nombre d’utilisateurs qui prendront en charge.
#Versions de test
Cette partie de la stratégie de test définit le plan de gestion des versions et l’historique des versions pour garantir que toutes les modifications apportées à cette version sont incluses.
Cela se prête à la construction d’un processus de gestion pour déterminer où la nouvelle version doit être disponible lorsqu’elle sera livrée, qui la déploiera, comment arrêter la version en cas d’erreur, etc.
#La planification des ressources
Comme son nom l’indique, il détermine le nombre de ressources qui seront impliquées dans le processus de test et leurs responsabilités pour la tâche qui leur est assignée.
#Analyse de risque
Analyse des risques – pour estimer les risques possibles qui pourraient survenir pendant l’exécution des tests et un plan clair pour atténuer les risques et un plan d’urgence lorsque les risques se produisent en temps réel.
#Revues et Approbations
Il s’agit de la dernière information dans le document de stratégie de test où l’équipe de gestion de projet et de développement examine toutes ces activités et approuve.
Un résumé des modifications apportées à la révision doit figurer au début du document, accompagné d’une date d’approbation, d’un nom et d’un commentaire.
La section suivante vous guide à travers une discussion différente sur la stratégie de test par Harini Mohan, notre responsable des tests.
Qu’est-ce que les testeurs négligent lorsqu’ils élaborent une stratégie de test ?
L’estimation et la planification des tests impliquent de nombreuses dépendances qui peuvent entraîner une variance dans l’estimation des tests.
Lors de l’élaboration d’une stratégie de test, les responsables et les testeurs doivent être conscients des problèmes de coordination et de mauvaise communication et planifier une stratégie adaptée à un projet.
Notre ingénieur de test senior, Harini Mohan, partage certains des facteurs que les responsables de test négligent lors de l’élaboration d’une stratégie de test.
Modification des exigences
Une application avec des exigences changeantes entraîne des estimations de test inexactes. Il est impératif de mettre en place un bon processus de gestion du changement pour suivre les exigences afin de minimiser les risques commerciaux.
Une capture d’écran mettant en évidence les pratiques de conduite du changement de notre client :
| OBSERVATION/CONSTATATIONS | NIVEAU D’IMPACT | COMMENTAIRES |
|---|---|---|
| Aucun conseil/comité formel de gestion du changement établi | Haut | Les membres du CAB doivent évaluer les demandes de changement. Les membres du CAB formulent des recommandations basées sur l’impact sur les services existants, le coût du changement et d’autres facteurs pertinents. Les membres du CAB doivent être choisis pour s’assurer que les postes commerciaux et techniques sont adéquatement représentés. |
| Priorisation | Haut | Une approche formelle de la hiérarchisation doit être écrite en fonction de critères tels que le retour sur investissement, l’augmentation des revenus, l’amélioration de la rentabilité, le coût de mise en œuvre, l’amélioration du service client, l’augmentation de la concurrence et les ressources nécessaires à la mise en œuvre. |
| Aucun processus d’approbation formel | Haut | Un processus d’approbation formel est nécessaire pour minimiser les risques commerciaux et pour examiner les étapes globales de mise en œuvre des modifications suivies dans le cadre de la version. L’audit des étapes de modification, telles que la révision du code, les tests de bout en bout, les approbations, etc., est important avant que la modification puisse être transmise aux clients. |
Pas de données de test/Mauvaises données de test
Les données de test sont les prérequis les plus importants à prendre en compte avant de commencer l’exécution du test. Certains projets ne disposent pas de données de test appropriées, ce qui entraîne un chaos lors des tests.
Par conséquent, les testeurs doivent continuellement explorer, apprendre et appliquer les approches les plus efficaces pour la collecte, la génération, la maintenance, l’automatisation et la gestion complète des données pour tout type de test fonctionnel et non fonctionnel.
Communication/coordination de projet
Certains chefs de projet oublient d’allouer du temps à la collaboration dans leur stratégie de test, ce qui, en particulier dans un modèle offshore/sur site, entraînerait plus d’efforts que prévu pour le projet.
Ambiguïté dans la planification
Le manque ou l’ambiguïté au cours de la phase de planification se prépare à un échec dès le départ. Lorsque suffisamment d’attention n’est pas accordée à la phase de planification, il est possible d’arriver à une stratégie de test inefficace, ce qui implique d’investir beaucoup de temps et d’efforts aux mauvais endroits et de laisser de côté les zones à haut risque.
Stratégie de test en agile
Dans un monde agile où les testeurs travaillent sur plusieurs projets/user stories dans des sprints de deux semaines, il est naturel de se demander si nous avons besoin d’une stratégie de test pour des sprints aussi courts. Si nous créons un document de stratégie de test pour chaque projet, beaucoup de temps serait passé à itérer la documentation.
Nous avons donc identifié quelques questions des communautés de test sur ce sujet et essayé d’y répondre.
Clause de non-responsabilité : vous faites ce qu’il y a de mieux pour votre équipe
Un document de stratégie de test « par projet » est-il la bonne approche dans un environnement agile ?
Dans l’environnement Waterfall, vous devez être familiarisé avec toute la documentation lourde associée au processus de test. Vous connaissez le format et le contenu de ces documents et, comme nous le savons, l’élaboration de tous ces documents prend énormément de temps.
Mais la stratégie que vous mettez en place décrit vos approches de test, vos méthodes de rapport de test, votre stratégie de gestion des environnements, votre stratégie de signalement des bogues, les principales parties prenantes et décideurs, etc.
Cependant, une stratégie de test Lean devrait fonctionner à la fois pour les modèles en cascade et agiles. Le document peut concerner l’ensemble du projet au lieu des sprints dans le modèle agile. Ce n’est qu’alors qu’il est logique que les chefs d’équipe ou les responsables disposent de suffisamment d’informations, élaborent des plans pour la conception des tests, etc.
Un document de stratégie de test global serait-il la bonne approche, qui serait davantage un document de stratégie de test statique à l’échelle de l’entreprise, agissant davantage comme une gouvernance, plutôt que de le faire pour chaque projet ?
L’idée d’un document global doit être revue, car les équipes doivent pouvoir décider à tout moment de ce qui convient à leur projet.
Un document de stratégie de test est-il même nécessaire ?
Bien sûr que oui! Chaque projet doit avoir une stratégie de test car elle aide à mettre en place le cadre de test pour tout projet.
An INFJ personality wielding brevity in speech and writing. Marketer @ Zucisystems.
Partagez ce blog, choisissez votre plateforme !
Articles Similaires
