Comment cultiver son jeu de test ?

Comme on me l’a fait remarqué dans un précédent article, l’entretien d’un jeu de test est une problématique à part entière.

Je n’ai pas la prétention d’avoir trouvé « LA » solution miracle, mais disons que nous avons trouvé une organisation qui nous simplifie grandement l’entretien de nos cas de test : « nous n’en avons pas » !

Rappel de notre contexte : nous sommes une entreprise « client final » et nos logiciels sont très dépendants de notre base de données.

Comme tout le monde (je pense), nos premiers tests (Selenium pour l’exemple) ont commencé par ressemblé à ça :

Imaginons un formulaire de recherche de produit simple : un champ de saisie (identifier par id= »monChamp ») + un bouton valider (identifier par id= »monBouton »). L’objectif du test est de vérifier que le résultat propose aussi les autres DVD de la collection « Docteur House » !

selenium.type("monChamp", "Docteur House Saison 2");//Héhé
selenium.click("monBouton");

Selenium (et surtout l’écriture XPath) nous permet d’écrire des tests fonctionnels « indépendant » de la construction de l’IHM, c’est chouette. Mais à quoi ca sert si mon « cas de test » est codé en dur ?

Notre première étape a été de mettre cette référence dans un fichier de cas de test. Notre cas de test est alors devenu :

Un fichier CasDeTest.properties, avec :

PRODUIT_TEST=Docteur House Saison 2

Et notre fichier de test : 

String monProduit = getBundle("PRODUIT_TEST");
selenium.type("monChamp", monProduit);
selenium.click("monBouton");

C’est déjà mieux car mon cas de test n’est situé plus que dans 1 fichier texte : les cas de test ne faisant qu’y faire référence !

Un jour, le test n’a plus fonctionné : comme il y avait une rupture de stock (je sais, c’est inadmissible, mais ça arrive), la recherche ne retournait plus de résultat : donc le test était « En échec ». Alors on s’est posé la questions suivante : « qui a choisit ce produit comme cas de test ? ». La vraie question était surtout de savoir « Pourquoi as-tu choisi ce produit plutôt qu’un autre ? ». « Et bien, parce que c’est un produit souvent vendu, qui se décline en saison, avec plusieurs CD, disponible dans plusieurs format (DVD/blueray/…) ».

Notre idée (toute simple ?) a été de nous dire : mais des produits comme cela, on en a plein la base de donnée ! On pourrait donc demander :

  1. Au P.O ses critères de définition du cas de test (Au lieu du cas de test lui même)
  2. A la base de donnée de nous trouver un cas de test correspondant aux critères du P.O

Maintenant, notre cas de test ressemble à ceci :

String monProduit = getProduitEnStockBienVenduSousPlusieursFormat();
selenium.type("monChamp", monProduit);//Héhé
selenium.click("monBouton");

Et la gentille fonction getProduitEnStockBienVenduSousPlusieursFormat() va nous chercher dans la base un exemple « au hasard », mais correspondant au besoin métier du P.O pour son cas de test !

Cette écriture nous permet :

  • De ne plus entretenir nos cas de tests (Indépendant de l’IHM + Indépendant des « données »)
  • En cas d’échec (aucun produit qui ne correspond aux critères business), d’informer le P.O que cette fonctionnalité n’a plus d’utilité / n’est plus utilisable.

Tags: ,

«
»