.svg){kind=logo}
Back
Il est impossible de touttester ; c'est pourquoi vous devez réfléchir aux risques métier liés à votre projet de développement. À partir de là, vous pouvez planifier l'ordre dans lequel vous allez effectuer les tests, la manière dont vous allez minimiser les risques liés à ces derniers et la façon dont vous allez les hiérarchiser, afin de tester en priorité les éléments les plus critiques. Votre stratégie de test aura alors la même priorité métier que celle qui régit l'ensemble du projet de développement. Dans cet article de blog, je décris la manière dont vous devriez aborder les tests basés sur les risques.
L’importance des tests s’apprécie également sous l’angle métier. Le secteur d’activité dans lequel votre système est développé joue également un rôle important. Si votre projet relève, par exemple, du secteur bancaire, des assurances, des technologies médicales ou des administrations publiques, l’entreprise a la réputation de devoir fonctionner correctement. Même s’il ne s’agit que d’une simple faute d’orthographe, cela peut nuire à la confiance accordée à l’ensemble de l’entreprise. Dans d’autres cas, il peut être primordial pour l’entreprise pour laquellevous travaillez de commercialiser un produit avant tout le monde ; il est donc possible qu’elle accepte la présence de quelques bogues dans la première version du produit. Dans tous les projets, il existe généralement un compromis entre le délai, le coût et la qualité. Si vous privilégiez la qualité, cela aura une incidence sur les délais et les coûts. Si le délai est prioritaire, les coûts et la qualité en pâtiront.
En d’autres termes, les facteurs temps, coût et qualité constituent également des paramètres importants pour la planification de vos tests. Il est en effet possible que vous testiez « trop » par rapport à la priorité globale du projet. Il est important que les efforts de test s’inscrivent dans le même objectif que celui à l’aune duquel l’ensemble du projet sera évalué. Lorsque vous planifiez vos tests, vous élaborez vos cas de test, vos scénarios de test ou les conditions préalables aux tests exploratoires, et vous obtenez une liste de tout ce qui doit être testé. Mais tous les tests n’ont pas la même importance : il y a toujours des fonctions du système qui sont exécutées de nombreuses fois, tandis que d’autres le sont moins souvent. D’autres facteurs déterminent également si une fonction du système nécessite plus ou moins de tests. La complexité d’une fonction, tant en termes d’exigences que de développement, pèse lourdement dans la hiérarchisation de vos tests.
Un test basé sur les risques s’appuie sur une analyse des risques, généralement fondée sur ce qui doit être testé au sein d’un niveau de test particulier, par exemple un test système ou au cours d’un sprint. Le type d’analyse des risques que vous choisissez n’a pas beaucoup d’importance ; l’essentiel est de prendre en compte la probabilité et la cohérence des aspects sélectionnés par le projet, tels que les aspects critiques pour l’activité, la complexité de la mise en œuvre, la complexité des données, etc. Tenez également compte des facteurs de temps, de coût et de qualité mentionnés ci-dessus.
COMMENT RÉALISER UNE ANALYSE DE TEST BASÉE SUR LES RISQUES
Une analyse de test basée sur les risques peut être réalisée de différentes manières; voici une proposition qui vous montre comment vous pouvez vous y prendre. Elle ne conviendra peut-être pas à votre projet, mais nous partageons ici quelques conseils utiles que vous pourrez mettre en pratique.
1. Désignez une personne comme responsable des risques, qui se chargera de mener l’analyse des tests basée sur les risques – de préférence le chef des tests.
2. Il faut tout d’abord identifier les risques dans le cadre de la mission, ce qui peut se faire de manière classique à l’aide de « post-it jaunes ». Ou pourquoi ne pas utiliser le mind mapping, où vous notez les risques – qu’ils soient élevés ou faibles. Il est préférable de le faire en groupe, dans une salle commune par exemple, afin de pouvoir s’inspirer mutuellement, de stimuler la créativité et de sortir des sentiers battus.
3. Une fois la liste des risques établie, ceux-ci doivent être regroupés, généralement par fonction ou par domaine. Il peut toutefois exister d’autres méthodes de regroupement mieux adaptées à la mission. Ce regroupement est effectué par le responsable de la gestion des risques.
4. Le gestionnaire des risques convoque une nouvelle réunion d’analyse des risques au cours de laquelle il présente les risques et leur regroupement. Les participants peuvent alors formuler des commentaires et ajouter de nouveaux risques ; si nécessaire, les risques peuvent être décomposés plus en détail. À l’issue de cette réunion, la cartographie des risques doit être prête, et les conditions préalables doivent être identifiées pour mener une analyse des risques permettant d’évaluer les probabilités et les conséquences.
5. Le responsable des risques organise un nouvel atelier au cours duquel l’analyse des risques proprement dite est réalisée.Parmi les participants figurent notammentle responsable des tests,un testeur expérimenté,un client,un architecte, un chef de projet,un product owner/responsable système etun développeur expérimenté.
6. La probabilité et les conséquences doivent être évaluées pour chaque risque. Commencez par examiner la probabilité que le risque se produise (sur une échelle de 1 à 4) et inscrivez-la dans la feuille de calcul.
Probabilité
En matière de probabilité, nous prenons en compte divers facteurs qui influent sur la probabilité que le risque se réalise.
Continuez à évaluer les conséquences de chaque risque. Masquez la colonne « Probabilité » afin qu'elle n'influence pas la pondération des conséquences.
Conséquences
Il est important ici d’identifier toutes les parties prenantes concernées et de déterminer si certaines d’entre elles sont plus importantes que d’autres et, le cas échéant, comment elles doivent être pondérées.
7. Multipliez la probabilité par la conséquence pour obtenir une valeur de risque. Classez les risques en fonction de leur valeur de risque :
- 1-4 = faible
- 5-9 = moyen
- 10-16 = élevé
8. Déterminez comment éliminer les risques :
- Faut-il éliminer tous les risques en même temps, en commençant par ceux qui présentent la valeur de risque la plus élevée et en descendant progressivement ?
- Commencer par la fonction ou le domaine concerné, puis éliminer les risques
- Faut-il commencer par les livraisons/sprints ?
- Faut-il rédiger des cas de test ou des scénarios, voire définir des conditions pour des tests exploratoires, pour les risques présentant une faible valeur de risque ?
9. Commencer par traiter les risques présentant la valeur de risque la plus élevée :
- Vérifiez si le risque peut être associé à une exigence ou à son équivalent, notez-le dans la colonne « Exigence associée »
- Identifiez un ou plusieurs cas de test, scénarios ou conditions de tests exploratoires (ou équivalents) permettant de vérifier que le risque est éliminé. Notez-les au niveau de l’en-tête afin d’avoir une vue d’ensemble de l’ampleur du travail de test à réaliser.
10. Il est alors temps de commencer à rédiger les cas de test, les scénarios ou à définir les conditions pour les tests exploratoires de manière détaillée.
- Désignez des responsables pour chaque cas de test, scénario ou condition des tests exploratoires.
- Commencez par une ébauche générale pour vous faire une idée du nombre de tests à réaliser. Il est recommandé d’utiliser un outil de test ; sinon, continuez à développer la feuille Excel, ce qui deviendra très complexe
- Rédigez les cas de test, les scénarios et les prérequis pour les tests exploratoires de manière détaillée
- Déterminez si le cas de test ou le scénario doit être exécuté automatiquement ou manuellement.
- Les cas de test/scénarios doivent être revus avant leur exécution.
- Si possible, déterminez l’ordre dans lequel les cas de test, scénarios ou tests exploratoires doivent être effectués. À titre indicatif, les tests présentant un risque élevé devraient être effectués en premier, mais il peut y avoir des fonctionnalités de base dont vous souhaitez vérifier le bon fonctionnement avant de commencer les autres tests.
11. Si vous souhaitez une couverture complète des exigences, parallèlement à la définition détaillée des tests, vous pouvez vérifier dans quelle mesure les exigences sont testées. Au point 9, les risques, les exigences et les tests ont été mis en correspondance ; vous pouvez désormais vérifier s’il existe des exigences pour lesquelles aucun test n’a été défini. S’il y a des exigences qui ne sont pas couvertes par des cas de test, des scénarios de test ou des tests exploratoires, notez-les et ajoutez-les, de préférence dans un nouvel onglet de la feuille Excel.
12. Répétez les étapes 3 à 10 pour les exigences qui n’ont pas été couvertes par l’analyse des risques. Gérez ces exigences de la même manière que les risques, c’est-à-dire en leur attribuant une valeur de risque, ce qui vous aidera à planifier l’ordre dans lequel les tests doivent être élaborés et exécutés.
13. Vous disposez désormais d’un système qui sera testé avec une couverturecomplète des exigences et vous avez éliminé tous les risques élevés grâce à des cas de test, des scénarios de test et des tests exploratoires qui garantiront que toutes les fonctionnalités importantes sont testées.
14. À l’approche de la prochaine livraison ou du prochain sprint, il est utile de revenir sur l’analyse des risques précédente et de vous poser les questions suivantes :
- La probabilité ou la conséquence du risque peut-elle évoluer ? Avons-nous éliminé ou partiellement éliminé le risque grâce aux tests développés ou effectués ?
- 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 prochaine livraison/du prochain sprint, procédez de la même manière que ci-dessus, mais veillez à identifier également les tests de régression. Il est alors conseillé de sélectionner des cas de test, des scénarios ou des tests exploratoires pour lesquels des anomalies ont été détectées et corrigées, ainsi que ceux présentant une valeur de risque élevée.
—
J'espère que cela vous aidera dans votre travail. Tous les tests sont différents et vous devez improviser pour vous adapter à l'organisation, au niveau de test ou au type de sprints avec lesquels vous travaillez.
.png)
