Prioriser les tests avec l'approche risk-based testing

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. 

COMMENT EFFECTUER UNE ANALYSE DE TEST BASÉE SUR LE RISQUE

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. 

Probabilité 

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. 

Conséquence 

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 :

• 1-4 = moindre
• 5-9 = pondérée
• 10-16 = élevée

8. Décidez de la manière d'éliminer les risques :

• Faut-il éliminer tous les risques en même temps, en commençant par ceux dont la valeur de risque est la plus élevée et en procédant à une élimination descendante ?
• Faut-il commencer par la fonction/le domaine concerné(e) et éliminer ensuite les risques ?
• Faut-il commencer par les livraisons/prints ?
• Faut-il rédiger des cas de test/scénarios ou prévoir des conditions pour des tests exploratoires pour les risques ayant une faible valeur de risque ? 
  

9. Commencez à travailler avec les risques qui ont la valeur de risque la plus élevée :

• Vérifiez si le risque peut être lié à une exigence ou l'équivalent, notez-le dans la colonne "Exigence liée"
• Identifiez un ou plusieurs cas de test/scénarios/conditions pour les tests exploratoires ou équivalents qui vérifient que le risque est éliminé. Rédigez les au niveau de l'en-tête pour avoir une vue d'ensemble de l'ampleur du travail de test.

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.

• Assignez des responsables à chaque cas de test, scénario ou condition pour les tests exploratoires.
• Commencez par établir une structure générale pour avoir une vision d'ensemble du nombre de tests requis. Il est mieux d'utiliser un outil de test car poursuivre sur une feuille Excel peut s'avérer fastidieux compte tenu de sa complexité croissante.
• Rédigez les cas de test, les scénarios et les prérequis pour les tests exploratoires avec attention aux détails.
• Déterminez si chaque cas de test ou scénario doit être exécuté automatiquement ou manuellement.
• Assurez vous que tous les cas de test et scénarios sont examinés avant leur exécution.
• Si possible, établissez l'ordre d'exécution des cas de test et des scénarios. Il est conseillé de tester en priorité les éléments présentant un risque élevé, bien qu'il puisse être nécessaire de valider en premier une fonctionnalité de base avant d'entreprendre d'autres tests.

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 :

• La probabilité/conséquence du risque peut-elle être modifiée ? Les tests effectués ont-ils permis d'éliminer le risque, en tout ou en partie ?
• Y a-t-il eu de nouveaux risques ou de nouvelles exigences qui doivent être traités de la manière décrite ci-dessus ?

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.