Etablir des critères d’exécution de cas de test

/>

Et, pour aggraver la situation, qu’adviendra-t-il si le projet est en retard et si la phase est raccourcie ? Comment être sûrs que nous pourrons tout tester ? En réalité, nous ne le pouvons pas, parce qu’il n’y a pas de baguette magique capable de tout corriger. Mais nous pouvons limiter les risques en procédant à une petite analyse lorsque nous créons la documentation de test. Il s’agit de déterminer les domaines du test système qui présentent la plus grande probabilité de risques, puis utiliser un cas de test de construction d’algorithme simple sur une valeur de probabilité calculée, puis exécuter en commençant avec la valeur la plus haute. Ça paraît simple non ? Le plus difficile est de déterminer la probabilité de l’occurrence et le risque.

Probabilité
Comme le terme l’indique, quelle est la probabilité de voir l’événement ou la situation se produire ? Par exemple, dans une application de commandes, trois types de commandes sont traités : commandes permanentes, commandes planifiées et commandes standard. En discutant avec les concepteurs ou utilisateurs de l’application, on voit que 75 % de toutes les commandes sont des commandes standard, 20 % sont des commandes permanentes et les 5 % restants sont des commandes planifiées. Nous avons donc la probabilité : nous savons que nous devons concentrer la plupart de nos cas de tests sur les commandes standard – mais nous n’avons pas fini.

Risque
Voilà qui semble plus subjectif. Nous devons déterminer le risque que court l’entreprise en cas d’échec d’un cas de test particulier. Par exemple, si l’application de saisie de commandes testée ne nous permet pas de saisir une commande standard, existe-t-il un contournement (par exemple utiliser une commande permanente avec une seule livraison) ? Comme pour la probabilité, nous devrons consulter le sponsor du projet, les utilisateurs du système ou l’analyste de gestion ; ou bien faire preuve d’intuition. Après avoir identifié la probabilité et le risque, nous devons les classer en haut, moyen ou bas et leur attribuer un poids numérique.

Par exemple, nous pourrions déterminer que haut a la valeur 5, moyen 3 et bas 1. Nous pourrions retenir la même pondération pour la probabilité et le risque. Bien sûr, si votre activité est très sensible au risque, il conviendra d’attribuer au risque une valeur plus élevée. L’étape finale consiste à multiplier le risque par la probabilité pour obtenir notre priorité d’exposition de cas de test globale. Nous exécuterons nos cas de test en ordre numérique décroissant. Ce faisant, si nous sommes obligés de réduire notre test, nous aurons exécuté tous les cas de tests de priorité haute et moyenne pour la release logicielle et réduit le risque pour l’entreprise. Pour que le test soit utile, il faut que les exigences soient testables. Si une exigence n’est pas testable, nous ne pouvons pas la mesurer ou déterminer si elle a été satisfaite ou non.

Est-ce si évident qu’il y paraît ? A titre d’exemple, prenons une exigence utilisateur stipulant que le système doit fournir des détails sur le catalogue au moyen d’un dialogue convivial. Fort bien, mais qu’est-ce qu’un dialogue convivial et comment mesurer les exigences ? Si la requête avait stipulé que le système doit renseigner sur le catalogue par un dialogue intuitif pour quelqu’un ne connaissant rien de l’application, il aurait été plus facile de concevoir un test mesurable. Nous aurions pu trouver quelqu’un d’étranger au système, et voir s’il pouvait y naviguer facilement.