lundi 26 novembre 2012

Agile Tour Paris 2012 : Tests et agilité - la vraie vie

Sylvain François de la start-up Kalistick nous propose une démystification des tests.
Il part du constat suivant :
- L'agilité est empreinte de la notion de "Definition of Done" pour les user story et les tâches.
- Cependant il subsiste une difficulté à définir le Done pour les tests.

Cela est difficile en Agile à cause :
- des livraisons rapides
- du développement incrémental
- de l'adaptation au changement
...
beaucoup de challenges donc et un besoin d'automatisation des tests.

Différents mythes tournants autour des tests ont engendré ce constat.

Mythe n°1 : la phase de test est incontournable
Dans les faits, cela n'arrive pas forcément, on a plutôt ça :
- pas de ressource spécialisée dans le test
- P.O = testeur
- pas de stratégie de test
- mal outillé pour les tests
exemples concrets :
- pas de tests fonctionnels poussés
- désactivation voir modification des tests pour les faire passer


Mythe n°2 : il existe une synergie testeurs / développeurs
En réalité, les testeurs et les développeurs ne vivent pas dans le monde et les objectifs sont parfois antagonistes (surtout quand les testeurs sont par exemple objectivés sur le nombre de bugs découverts). Les testeurs ont pour tâche d'identifier du bug Les développeurs ont pour tâche de "cacher" du bug
exemples concrets :
- des développeurs qui refusent des fiches de bugs si elles ne sont pas assez précises
- des testeurs qui refusent de tester
- des testeurs et des développeurs qui ne se parlent pas


Mythe n°3 : l'application est testée le plus en amont possible
Sylvain François nous explique que la pyramide de Mike Cohn est souvent inversée en tests manuels :
Il faut donc mettre en place des tests dès le développement !
Mais ce n'est pas évident : les TDD par exemple sont difficiles à mettre en place, l'écriture et la maintenance sont coûteuses.
Exemples concrets :
- des tests manuels sont effectués sur le sprint n puis les tests automatisés sont écrits au sprint n+1
- il faut alors dédier une équipe à l'automatisation des tests


Syndrome du fromage suisse
Le principe est que chaque couche de tests ne peut être exhaustif mais chaque couche couvrant potentiellement des parties non couvertes par d'autres, les zones se recouperont.
Il arrive que des cas ne soient pas testés du tout et là, il y a deux scénarios :
- cette partie ne fait pas partie des modifications livrées donc elle n'a pas généré de bug avant
- cette partie fait partie des modifications livrées et elle devient donc prioritaire à tester


Le graal de l'automatisation
Automatiser les tests c'est :
- des gains de productivité
- de la reproductibilité
- de la traçabilité
- moins ingrat pour les testeurs


Mais il y a des problèmes :
- le démarrage (monter en compétence, prioriser les tests à automatiser, refondre les tests existants, choisir l'outil)
- le coût de maintenant (compléxité d'implémentation, résistance des tests au changement)
- l'exploitation des résultats (origine des KO ?, pertinence des OK ?)
- performances (volume à analyser)


Conclusion :
- il est important de savoir ce qui est testé ici et là
- il est important de prioriser les tests car l'exhaustivité n'est pas atteignable
- il y a des écarts entre objectifs et réalité
- automatiser ne solutionne pas tout
- il faut identifier des critères de priorisation
- la couverture de code est une réponse mais il y en a d'autres


ROTI : 4/5

1 commentaire:

  1. Très bon article et bonne présentation aussi.

    J'ai beaucoup aimé la partie où il montre que son logiciel sait déterminer une couverture multi couche car c'est vraiment difficile.

    J'aimerais toutefois réagir sur un truc qui m'a semblé vraiment dangereux. Il indique, à raison, que beaucoup d'équipes développent des fonctionnalités durant le sprint N mais ne codent les tests que lors des sprints suivants (ie. N+1, N+2, etc.) Or c'est une grave erreur de procéder de cette manière. D'abord, les tests doivent faire partie du périmètre des US. Ensuite, dans une démarche comme TDD (Test Driven Developement), les tests sont écrits en amont et aident les développeurs, d'où le nom. Lorsqu'on code les tests en aval, on perd au moins 50% de l’intérêt des tests. En outre, on se retrouve très vite dans une situation où les développeurs écrivent des tests de complaisance sans grande valeur ajoutée. Et là, les tests coutent effectivement cher. Au moins, dans une équipe qui code des tests sérieux, on peut se dire qu'il serviront de validation et dans le cadre de la non régression.

    Dans une démarche utilisant 3T (Tests en Trois Temps), qui est une méthode inspirée des TDD, ça va plus loin. on écrit les prototypes (descriptifs des fonctions), puis écrit les tests en s'inspirant du cahier des charges (quitte à le compléter) et enfin on développe les fonctionnalités. La méthode 3T conseille d'ailleurs que ce soit trois personnes différentes qui s'occupent de ces trois parties. Et si seulement deux personnes sont disponibles, 3T préconise que la personne qui écrit les tests ne soit pas celle qui développe les fonction, afin de garantir la qualité.

    RépondreSupprimer