Il est impossible de tout tester, c'est pourquoi vous devez réfléchir aux risques qui existent dans votre projet de développement. Avec ce point de départ, vous pouvez élaborer une stratégie de test en planifiant soigneusement l'ordre des tests en fonction de leur priorité, minimisant ainsi les risques associés. En effet, en déterminant quelle fonctionnalité ou quel aspect du produit est le plus critique pour le succès global du projet, vous pouvez vous assurer que ces éléments sont testés en premier. Cette approche garantit que votre stratégie de test est alignée sur les objectifs du projet de développement. Dans cet article de blog, je vais décrire comment élaborer une stratégie de tests basés sur les risques.
L'importance des tests réside également dans une perspective commerciale, influencée par le secteur dans lequel votre logiciel est développé. Par exemple, dans des domaines comme la banque, l'assurance, la technologie médicale ou le secteur public, la fiabilité est cruciale pour maintenir la réputation et la confiance des clients. Même une petite erreur, comme une faute d'orthographe, peut ébranler la confiance envers l'ensemble de l'entreprise. Cependant, dans certains cas, l'urgence de mettre un produit sur le marché peut primer, et il est possible de tolérer quelques défauts dans la première version. Cela dit, dans tous les projets, il existe un équilibre entre le temps , le coût et la qualité. Si la qualité est prioritaire, cela peut impacter le temps et le coût. Si le temps est le facteur prédominant, cela peut influencer à la baisse le coût et la qualité.
En d'autres termes, les facteurs temps , le coût sont également des paramètres importants pour la planification des tests. Il est possible que vous testiez "trop" de cas par rapport aux priorités du projet. L'effort de test doit être aligné sur les objectifs du projet, tout comme l'ensemble des activités de développement. Lors de la planification des tests, que ce soit la création de cas de test, de scénarios ou la préparation des conditions pour des tests exploratoires, une liste exhaustive des éléments à tester est générée. Cependant, tous les tests ne revêtent pas la même importance. Certaines fonctionnalités du système sont plus critiques et sont utilisées fréquemment, tandis que d'autres le sont moins. Divers facteurs, tels que la complexité des exigences et du développement, influent également sur le niveau de test nécessaire.
L'approche risk-based testing repose sur une analyse de risque, qui peut être effectuée à différents niveaux de test, comme les tests système ou les sprints. Le type d'analyse du risque sélectionné importe moins que la prise en compte de la probabilité et de l'impact des différents aspects, tels que leur importance commerciale, leur complexité d'implémentation ou de données. Il est également crucial d'intégrer les considérations de temps, de coût et de qualité évoquées précédemment.
Une analyse de test basée sur le risque peut être réalisée de différentes manières; cette proposition vous montre comment procéder. Il se peut que cette méthode ne corresponde pas à votre situation et à votre projet, mais nous espérons que vous en tirerez quelques bons conseils.
1. Désignez une personne -de préférence le Test Lead - que l'on nommera dans cet article : Risk Manager. Cette personne dirigera l'analyse de test basée sur les risques.
2. Les risques doivent, tout d'abord, être identifiés dans le cadre de la mission, ce qui peut être fait de manière classique à l'aide de post-it. Ou pourquoi ne pas utiliser le Mind Mapping, où l'on note les risques - élevés et faibles. Il est préférable de faire cela en groupe, dans une salle commune par exemple, afin de s'inspirer les uns des autres, de devenir plus créatif et de sortir des sentiers battus.
3. Lorsque la collecte des risques est terminée, ceux-ci doivent être regroupés, ce qui se fait généralement par fonctions ou par domaines. Mais il peut y avoir d'autres façons de regrouper les risques qui conviennent mieux à la mission. Le regroupement est effectué par le Risk Manager.
4. Le Risk Manager convoque une nouvelle réunion d'analyse des risques au cours de laquelle il présente les risques et leur regroupement. Les participants peuvent maintenant commenter et ajouter des nouveaux risques, ces derniers peuvent être décomposés de manière plus détaillée si nécessaire. À l'issue de cette réunion, le mapping des risques doit être prêt et les conditions préalables doivent être réunies pour effectuer une analyse de risque dans laquelle la probabilité et les conséquences sont évaluées.
5. Le Risk Manager organise un nouvel atelier au cours duquel l'analyse de risques proprement dite est effectuée. Exemples de participants: test lead, testeur expérimenté, client, architecte IT, Chef de projet, Product owner / Manager system, développeur expérimenté.
6. Les probabilités et conséquences doivent être évaluées pour chaque risque. Commencez par examiner la probabilité que le risque se produise, 1-4 et entrez-la dans la feuille de calcul.
Lorsqu'il s'agit des probabilités, nous prenons en compte différents facteurs qui affectent la probabilité que le risque se produise.
Continuez à évaluer les conséquences de chaque risque. Masquez la colonne Probabilité afin qu'elle n'affecte pas la pondération des conséquences.
Il est important d'identifier toutes les parties prenantes concernées et de se demander si certaines d'entre elles sont plus importantes que d'autres et, si c'est le cas, comment les pondérer.
7. Multipliez la probabilité par la conséquence et vous obtenez une valeur de risque. Répartissez les risques en fonction de leur valeur de risque :
8. Décidez de la manière d'éliminer les risques :
9. Commencez à travailler avec les risques qui ont la valeur de risque la plus élevée :
10. Maintenant que les bases sont posées, il est temps d'entrer dans le vif du sujet en rédigeant les cas de test, les scénarios et les conditions pour les tests exploratoires avec un niveau de détail minutieux.
Pour une couverture exhaustive des exigences, en parallèle des tests détaillés, vérifiez dans quelle mesure les exigences sont testées. À partir des étapes précédentes où les risques, les exigences et les tests ont été cartographiés, vous pouvez désormais repérer les exigences dépourvues de tests définis. Identifiez ces lacunes et documentez les de préférence dans un nouvel onglet de la feuille Excel ou tout autre outil de suivi utilisé.
12. Effectuez les étapes 3 à 10 pour les exigences qui n'ont pas été couvertes par l'analyse des risques. A titre d'exemple, gérez les exigences de la même manière que le risque, c'est-à-dire en produisant une valeur de risque, qui vous aidera à planifier l'ordre dans lequel les tests doivent être produits et réalisés.
13. Vous avez maintenant un système qui sera testé avec une couverture complète des exigences et vous avez éliminé tous les risques élevés en ayant des cas de test/scénarios/tests exploratoires qui garantiront que toutes les fonctionnalités importantes sont testées.
14. Au moment de la prochaine livraison/ du prochain sprint, il est utile d'effectuer un suivi de l'analyse des risques précédents et de se poser les questions suivantes :
15. Lors de la planification de la livraison/du sprint à venir, procédez de la même manière que celle décrite ci-dessus, mais les tests de régression doivent également être identifiés à ce stade. Un conseil est alors de sélectionner les cas de test/scénarios/tests exploratoires pour lesquels des écarts ont été trouvés et corrigés et de sélectionner les cas de test/scénarios/tests exploratoires ayant une valeur de risque élevée.
—
J'espère que cela vous sera utile sur le moment. Tous les tests sont différents et vous devez improviser pour qu'ils conviennent à l'organisation, au niveau de test ou les sprints sur lesquels vous travaillez actuellement.