Les tests dans un processus itératif Scrum

Les méthodes Agiles cherchent à produire du logiciel avec un haut niveau de qualité. Pour arriver à cet objectif, plusieurs principes sont mis en œuvre, parmi lesquels on peut trouver, une meilleure communication et des livraisons régulières visant à éviter les incompréhensions. Mais il y a aussi une utilisation des tests qui est faite de façon poussée.

Ceci ne veut bien sûr pas dire que les processus de réalisation dits "classiques" ne prévoient pas de faire des tests, mais plutôt que les processus Agiles les utilisent de façon différente.

Le timing du test

Il est bien connu que plus un bug est identifié tard dans le processus de développement  plus son coût de correction et son impact est élevé. En effet, prenons pour exemple les 3 situations suivantes :

• Un bug est identifié en développement : Dans ce cas c'est le développeur qui identifie le problème à partir de ses tests unitaires. Les causes possibles du problème sont normalement peu nombreuses, le test étant unitaire, il ne doit tester qu'une petite partie du code et éviter au maximum les interactions avec d'autres composants du système.  De plus c'est le développeur lui-même qui identifie le problème, il n'y a donc pas de problème de communication entre plusieurs intervenants. 
• Un bug identifié en recette : Dans ce cas c'est un testeur fonctionnel qui identifie le problème. Il doit alors passer un peu de temps pour s'assurer que c'est un vrai problème, le formaliser dans une fiche de description. Côté technique, le développeur doit comprendre la fiche, se remettre dans les conditions du test (ce qui n'est pas toujours facile, voire même impossible), échanger avec le testeur pour être sur de la compréhension. Une fois remis dans le contexte, le bug doit être corrigé, et là encore la recherche des causes du problème peut être beaucoup plus longue. En effet l’anomalie a été identifiée sur un système intégré où les interactions peuvent être nombreuses, la combinatoire des cas possible et infiniment plus grande que dans le cas d'un test unitaire.
• Un bug identifié en production : Dans ce cas, la personne qui identifie le problème n'est plus formée aux tests et à la formalisation des problèmes. Les informations qui arrivent au développeur sont souvent très imprécises  et le développeur n'a que très rarement la possibilité de communiquer directement avec l'utilisateur. Le temps nécessaire pour reproduire le problème et encore plus long et la correction difficile à apporter. A tout ces problèmes s'ajoutent souvent, la nécessité de redéployer un patch en production, et le coût que peut provoquer le dysfonctionnement en production pour l'entreprise.

A cela il faut ajouter qu'il peut arriver que la cause d'une anomalie soit structurelle (problème de conception, mauvaise compréhension de points clés, ...). Dans ce cas, le fait de découvrir des anomalies tard dans le cycle de réalisation peut obliger à revoir une grande partie de l'application, avec tous les problèmes de régression que cela peut impliquer.

Le test dans le cycle en V

Dans un cycle en V, les différentes activités sont censées être réalisées en séquence. Bien que, comme le dit Claude Aubry, le cycle en V n’existe pas en tant que tel, ce type de cycle vise à définir 3 grands types d’activités qui sont plus ou moins réalisés en séquence:

• Les activités de spécification, qui sont réalisées en premier
• La réalisation
• Le test qui est réalisé en fin de processus

Le problème de cette approche est qu’elle présente un effet pervers sur la qualité du produit final. Les tests sont relégués à la toute fin du processus, le moment où les retards et le manque de budget apparaissent réellement. Ceci a pour conséquence que ce sont très souvent les tests qui servent de soupape pour tenter de revenir dans le budget. Ceci est d’autant plus facile, qu’une diminution des tests n’est pas immédiatement visible pour le client, en tout cas moins qu’une fonctionnalité manquante.

Le résultat de cette pratique est qu’on concentre notre effort de test sur la recette (avec un test de recette, on teste toutes les couches en même temps, ce qui peut donner l’impression d’être plus efficace). La réduction des charges de test provoque donc l’apparition de problèmes dans les dernières étapes du projet, voire même en production, et comme nous l’avons vu plus haut, en plus de provoquer une insatisfaction du client, le coût de correction des anomalies est extrêmement élevé. 

Le test Scrum

Scrum est un processus itératif qui concentre dans des itérations courtes (2 à 3 semaines en général) toutes les activités de la production logiciel. Ainsi au cours d’une itération on traite les activités aussi variées que :

• les spécifications
• la conception
• les bases de données
• le codage
• le test unitaire
• le test d’intégration
• le test fonctionnel
• la documentation
• …

Si on se concentre sur les activités des tests, on remarque que tous les types de test sont passés lors de chaque itération. De ce fait, les tests ne sont pas relégués à la toute fin de processus, mais intégrés dans celui-ci. De plus comme le logiciel est livré au product owner à chaque itération il peut (et même doit) tester lui aussi la livraison pour pouvoir faire ses retours le plus rapidement possible.

Quand on dit que l’Agilité permet de réduire l’effet tunnel, on pense souvent au côté fonctionnel, mais l’effet tunnel porte aussi sur le niveau de qualité de la production, et là encore l’Agilité apporte une vraie solution. 

Une autre particularité de Scrum est que les développements sont priorisés par rapport à leur valeur métier, pas par rapport aux priorités techniques. Cette particularité à un impact sur les tests. En effet, cette façon d’ordonner les développements oblige les développeurs à revenir sans cesse sur du code déjà testé pour y rajouter des fonctionnalités. Dans ces conditions il est très important de pouvoir rapidement vérifier que l’on n’introduit pas de régressions. C’est pour cette raison que les processus Agiles mettent l’accent sur les tests unitaires automatisés, et les chaînes d’intégration continues. Les tests unitaires, lorsqu’ils sont réellement unitaires (j’y reviendrais sûrement dans un autre article) sont faciles à maintenir et peuvent être exécuté à chaque compilation. De plus comme ce type de test identifie les problèmes au plus proche de la réalisation les corrections sont peu coûteuses.

Conclusion

En conclusion les différences les plus notables portent sur 2 points :

• En fonction du cycle de développement utilisé, on ne met pas l’accent sur le même type de tests. Les tests de recette pour le cycle en V, les tests unitaires pour Scrum.
• Les livraisons régulières des processus Agiles évitent l’effet tunnel sur la qualité, ce qui permet d’identifier très tôt des problèmes et de rectifier le tir avant qu’il ne soit trop tard.