Test basé sur les risques

Comme nous le savons tous, réaliser des tests exhaustifs est impossible. À quelques exceptions près, il faut faire un choix et concentrer ses activités d’assurance qualité sur les aspects les plus critiques du produit ou du projet. Alors que les méthodes agiles abordent le principal risque de tout projet – des exigences floues ou volatiles – elles ne répondent pas vraiment à la question « Que tester, et dans quelle mesure ? ». De plus, des méthodes comme Scrum ont tendance à mettre l’accent sur les tests automatisés des composants et des user stories, tout en négligeant les tests système. Si elles existent, les testeurs système ont souvent du mal à suivre le rythme des changements continus qui sont inhérents à chaque méthode agile.

Le test basé sur les risques représente une stratégie de test adaptée à ces problèmes. Il permet de cibler de manière appropriée les efforts d’assurance qualité. En règle générale, c’est la stratégie idéale si vous manquez de temps, d’argent ou si le projet de test lui-même présente un risque élevé.

L’idée de base consiste à concentrer l’effort de test sur les fonctionnalités présentant le plus grand risque de défaillance. Pour cela, la première chose à faire est d’effectuer une analyse des risques des workflows, des user stories et/ou des exigences associées. Habituellement, chaque risque est classé dans une catégorie, par exemple : Élevé, Moyen et Faible. Ces niveaux de risque définissent la priorité et l’intensité des tests à réaliser.

Cependant, il est souvent difficile de définir des critères précis pour l’intensité du test. Une bonne pratique consiste à appliquer des critères de couverture pour les classes d’équivalence, les valeurs limites, les tables de décision ou les éléments structurels d’un modèle.

Mais avant d’examiner de plus près la stratégie de test basée sur les risques, examinons d’abord l’analyse des risques. L’analyse des risques est un effort collectif. Il est important d’impliquer à la fois les analystes métier et les techniciens dans l’analyse des risques. Les premiers sont des experts dans les risques associés à l’utilisation du produit, tandis que les seconds ont une bonne idée des difficultés techniques susceptibles de conduire à des défaillances. Malheureusement, la communication entre ces deux parties est loin d’être évidente. Surtout dans les grandes entreprises, il existe encore des silos entre les départements métier et informatique. Enfin, il y a la confusion liée au langage babylonien entre ceux qui connaissent par cœur les codes opérationnels du système et ceux qui les ont codés de la même manière en tant qu’ensemble.