Ca Scrum !

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.