Les typologies de test

La mise en place « des tests » au sein de l’équipe est un vrai challenge : nous partons de 0. Les réactions ont rarement été positives : « Ca sert à rien », « De tout façon, je ne fais pas de Bug », « Le projet existe depuis 5 ans sans tests, donc soit on fait tout, soit on fait rien … Et comme on n’a pas le temps de faire des tests sur tout l’existant, ca sert en rien d’en faire » et le dernier « De toute façon, tout ne peut tester : on n’est pas dans la tête des utilisateurs ».

Bon, une fois qu’on a dit ca, qu’est-ce que l’on fait ? Et bien pour ma part, je prend mon bâton de pèlerin et on essaye d’expliquer :

  • Il faut être pragmatique dans les tests : Entre rien faire et tout faire, il y a évidemment un compromis à trouver.
  • Il y a des tests souvent plus prioritaire que d’autres (En tout cas, avec une valeur métier plus importante que d’autres)
  • Il pourrait même être envisageable d’être piloté par les tests ! (Sisi, j’vous assure .. ça existe !).

Bref, on est parti pour faire œuvre de pédagogie avec l’équipe (Est-ce le rôle du ScrumMaster ?).La plus grande difficulté qu’a rencontré l’équipe était de savoir « Quoi tester ? Comment tester ? Quelle « Stratégie » de test ?

Je me suis donc inspiré d’une matrice proposée par Brian Marick (signataire du Manifeste Agile) comme base de réflexion dans le cadre de notre projet :

Quels sont les typologies de test ?

Un axe de réflexion portant sur le domaine (Plutôt Business ou Plutôt technique ?). Un autre portant sur le contexte d’utilisation (Environnement Standard ou utilisation aux limites). (C’est notamment sur cette axe que j’adapte la vision de Brian Marick à mon contexte).

On obtient alors 4 « typologies » de tests :

  1. Performances
  2. Qualité de l’information
  3. Analyse du comportement
  4. Exploratoire

J’ai alors essayé d’illustrer ces 4 typologies par des « questions type ». Il est tout à fait possible qu’il y ait des discutions sur la typologie à associer à une question : Et alors ? C’est le but recherché ? Au lieu de baisser les bras, on commence à envisager des solutions :) De même, il est évident que certaines questions ne rentrerons pas dans une seule case : Une problématique entrainera alors plusieurs tests pour couvrir correctement le périmètre.

Maintenant, comment peut-on tester ces 4 typologies ?

Loin de moi l’idée de lister tous les « formidables » outils qui existent sur le marché du test. L’idée était surtout d’expliquer à l’équipe que chaque outil à son objectif qui lui est propre ! Il est toujours possible de tordre le système (Ma machine a café peut surement me servir pour faire cuire un œuf dur … Mais bon, c’est pas le plus simple !)

Il était aussi important de mettre en évidence que « tous » les tests ne sont pas forcément à « coder », ni à « automatiser ». Là aussi, il faut savoir être pragmatique et rechercher l’efficacité.

Enfin, il faut bien être conscient que réaliser ces tests demandent un effort ! Cet effort ne doit pas être « insurmontable », mais il n’est pas non plus négligeable. Il faut accepter cet effort, souvent nécessaire à la qualité de l’application.

Quels sont les difficultés liés aux tests ?

Chaque typologie comporte ses propres difficultés, plus ou moins importantes.

Notre principale difficulté réside maintenant dans l’expression et la communication du scénario de test entre les « fonctionnels » et l’équipe technique. Nous avons plusieurs tentatives en cours : je ferrai un retour lorsque nous aurons un résultat concluant.

4 Réponses à “Les typologies de test”

  1. Tweets that mention Ca Scrum ! » Blog Archive » Les typologies de test -- Topsy.com :

    [...] This post was mentioned on Twitter by Jean Helou, cascrum. cascrum said: Ca Scrum ! Les typologies de test http://bit.ly/fHVzmY [...]

  2. Nicolas Chambrier :

    Un seul truc me gêne dans cet article, la partie « entretenir les tests » qui n’apparait que dans une seule des 4 typologies, et qui semble reléguée à du « pas très important » (ou peut-être l’auteur veut-il dire « pas très difficile »).

    Or c’est à mon avis sur un gros projet, avec beaucoup d’existant, et beaucoup d’évolutions à venir, justement LE point critique. Quand on teste des choses précises, et qu’elles évoluent beaucoup, il faut investir pour maintenir en vie les tests.
    Et si on parle de Selenium, à chaque refonte graphique le moindre changement HTML doit donner lieu à une réécriture de certains tests.

    Bref, le coût de maintenance lié aux tests eux-mêmes me semble un peu négligé ici :)

  3. dibus :

    NIcolas,
    Ton commentaire méritait un article : c’est maintenant chose faite ! De même Selenium donnera lieu a plusieurs articles (toujours en cours de réflexion). Je suis étonné que tu dises « Le moindre changement HTML doit donner lieu à une réécriture de certains tests » : utilises tu l’écriture XPath pour accéder aux éléments de ta page ?

  4. Mathieu Petitdant :

    Super article !
    De mon côté j’adore : « Tester c’est douter ! » :-)

Mettre un commentaire