Que devons-nous tester ?

Que devons-nous tester ?

Cette question qui semble élémentaire se trouve être une des plus complexes dans le monde de la qualité et du test… tout en étant peut être la plus importante car, mais est-il nécessaire de le rappeler ?, les tests exhaustifs sont impossible. Vous l’aurez reconnu, on parle ici du périmètre de test, un élément essentiel des plans de test et un sujet qui fait déjà l’objet d’un bel article d’Arnaud Verin.

Afin de réduire le périmètre de cet article je vais me limiter aux tests dans un environnement Agile. Je vais donc commencer par un rappel rapide sur le développement d’un produit en Agile.

Rappels rapides sur l’Agile et ses impacts sur le test

Un produit développé en Agile est un logiciel développé de manière incrémentale comme ceci:

Cela engendre de nombreuses contraintes comme:

• Avoir un produit potentiellement utilisable (conçu, développé et testé!) à chaque incrément
• Livrer de la valeur à chaque incrément
• Livrer de la qualité à chaque incrément
• Avoir une équipe capable de réaliser l’ensemble de ces tâches

En Scrum, les incréments ont une durée allant en général de 2 à 4 semaines. Ce temps, si on le compare au temps long que l’on avait pour tester un logiciel dans sa globalité avec des cycles plus traditionnels comme le cycle en V est court voir très court… D’autant plus qu’il est possible d’avoir des incréments beaucoup plus courts que 2 semaines.

Les méthodes agiles engendrent donc au moins ces 3 types de challenges pour le test:

• Des challenges de fréquence d’exécution (on teste souvent)
• Des challenges de temps (il faut tester dans le temps restreint imparti)
• Des challenges de qualité (il faut atteindre un niveau de qualité suffisant pour avoir un produit potentiellement utilisable)

Le périmètre se retrouve donc au centre des problématiques. Que tester et jusqu’à quel point pour atteindre le juste niveau de qualité tout en respectant les contraintes de temps et de fréquence d’exécution ?

C’est l’objet de de la suite de cet article!

Quels sont les éléments de son produit à tester en Agile ?

Tester les nouveautés

Chaque nouvel incrément de son produit ajoute des fonctionnalités à travers des User Stories il est important de tester ces nouvelles fonctionnalités en profondeur afin de s’assurer qu’elles répondent bien à l’attendu.

Toute la problématique revient maintenant à définir le « en profondeur » et « l’attendu ».

Pour l’attendu il faut prendre en compte:

• La valeur que doit apporter la fonctionnalité. Cette dernière doit être testée que tant au niveau de son intérêt qu’au niveau de la réponse. Le BDD est une pratique assez efficace pour traiter cet élément.
• La capacité à répondre aux exigences fonctionnelles et non-fonctionnelles énoncées: cela peut être couvert en partie avec des tests scriptés boites noires, des tests à automatiser (car ils seront ré-exécutés) ou encore des tests exploratoires
• La capacité à répondre aux exigences fonctionnelles et non-fonctionnelles non exprimées: c’est peut être un des éléments les plus complexes. Cela demande une compréhension fine du contexte. Ces éléments peuvent être couverts en partie par des tests exploratoires qui peuvent, par exemple, repérer des problèmes d’ergonomie, de performances, de cohérence…
• La qualité du code qui doit être maintenable, stable, propre: cela se fait notamment avec des outils d’analyse de code comme SonarQube, des revues de code et des tests unitaires (qui peuvent être écrits en TDD)
• La qualité de la documentation. Cela peut se fait par des revues et dépend fortement du type de documentation éditée pour le produit
• …

Les éléments à tester sont nombreux il faut maintenant savoir jusqu’à quel point il est nécessaire de les tester pour aller suffisamment « en profondeur » mais aussi respecter les contraintes de temps: on ne peut pas passer tout un sprint de 2 semaines ou plus à valider le comportement d’une unique nouvelle fonctionnalité!

C’est là qu’il devient crucial de bien choisir ce que l’on teste et comment on le teste. Pour cela la certification ISTQB testeur technique Agile propose une méthode intéressante dont il est possible de s’inspirer… pour les tests d’intégration, tests systèmes et potentiellement tests d’acceptation.

Elle est basée sur les risques et la criticité de la fonctionnalité. En fonction de ces 2 éléments la certification propose un mélange spécifique entre les tests automatisés, les tests exploratoires et les tests « boites noires » (scriptés en amont et manuels):

Plus le risque est élevé plus les tests boîte noire et automatisés sont à utiliser. De même ce mélange dépend aussi de la criticité de la fonctionnalité pour le système. Vous noterez que les tests exploratoires sont les seuls tests qui sont toujours recommandés.

Une démarche comme celle-ci peut aider à faire des choix afin de tester suffisamment rapidement.

Tester les nouveautés c’est bien, mais une nouvelle version d’un produit ce n’est pas uniquement les nouvelles fonctionnalités. Il est nécessaire de s’assurer que ces nouvelles fonctionnalités n’ont pas introduit des anomalies majeures et que les anciennes fonctionnalités continuent à fonctionner correctement en testant l’ensemble du produit.

Tester le produit dans son ensemble

Vous l’aurez compris, on parle ici principalement de régression. Il existe d’ailleurs déjà un article spécifique sur ce sujet, vous pouvez le consulter si vous souhaitez aller plus en profondeur sur le sujet.

Il est impossible de garder une cadence correcte si à chaque nouvelle fonctionnalité l’ensemble des fonctionnalités précédentes doivent faire l’objet d’une validation aussi poussée que lors de son implémentation. Une campagne de régression doit assurer un filet de sécurité mais ne peut avoir vocation à valider totalement le produit. Il est nécessaire d’accepter le risque d’introduction de régression mineures… il est par contre obligatoire de limiter au maximum l’apparition de régression majeures car les utilisateurs sont particulièrement frustrés lorsque cela arrive!

L’objectif affiché se doit donc d’être de repérer les régressions majeures et critiques. Les régressions mineures peuvent être détectées même si ce n’est pas l’objectif premier. D’ailleurs, ces dernières sont régulièrement repérées lors des sessions de tests exploratoires validant les nouvelles fonctionnalités.

Afin de repérer principalement les régressions majeures il est intéressant de coupler 2 approches complémentaires:

• La première, celle qui représente le plus de volume, est celle des usages. Les tests de la campagne de régression doivent correspondre aux usages actuels du produit. Cette nécessité de correspondre aux usages actuels est important car une régression sur une utilisation obsolète du logiciel n’est plus forcément majeure alors qu’une régression équivalente sur un nouvel usage ou une utilisation démocratisée du produit est particulièrement handicapante. Cette notion d’usage actuel, prépondérante, est assez complexe à mettre en place et engendre une mise à jour régulière de la régression. Afin de l’implémenter correctement il est souvent important de connaitre les usages en production. Il y a plusieurs manières d’identifier ces usages. Une manière simple et efficace est une analyse de logs qui peuvent alors repérer des comportements comme le fait Gravity
• La seconde, qui représente un volume beaucoup plus faible mais dont l’impact est tout aussi important, est celle des comportements « anormaux » ou des « événements exceptionnels ». Ces derniers touchent principalement des usages dont on souhaite se protéger (ex: un moyen détourné pour ne pas payer mais cependant avoir sa commande grâce à un TimeOut) ou des éléments non-fonctionnels comme l’accessibilité ou la sécurité.

Lorsque l’on a conscience de ces 2 éléments il faut alors ajuster le volume de ses tests à la capacité de l’équipe en terme d’exécution, d’analyse et de maintenance. Là encore, l’outil Gravity peut permettre de gagner beaucoup de temps en proposant la partie sur les usages « à la volée ». La certification ISTQB testeur technique agile met en avant 5 approches pouvant aider à réduire le temps d’exécution:

• Prioriser les tests pour être sûr d’exécuter les tests les plus importants
• Avoir des configurations différentes en fonction de l’environnement sur lequel on livre
• Diminuer le nombre de tests IHM et augmenter les tests API et tests unitaires
• Exécuter les tests en fonction des lignes de code impactées
• Paralléliser les tests

On pourrait également parler de shift right et de test en production avec du canary release ou toute autre méthode.

Conclusion

Bref, comme vous le voyez, il n’y a pas de réponse toute faites à la question qui parait pourtant simple: « Que devons-nous tester? »… Et ce même si l’on se restreint aux méthodologies agiles.

Il y a cependant, au-delà de tout contexte, des éléments à prendre en considération et à garder en tête. La suite reste et restera un savant mélange demandant l’expertise de testeurs pour tenter de s’approcher du meilleur compromis délais/coûts/qualité du produit à travers le choix d’un périmètre en constante évolution.

Pour ceux qui le souhaitent cet article est disponible en anglais sur le blog de Gravity.

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.