Vous connaissez surement la fameuse pyramide des tests définie par Mike Cohn, l’un des fondateurs de la Scrum Alliance. Cette pyramide a été utilisée et commentée à de nombreuses reprises. C’est maintenant à mon tour de compléter la pyramide !
La pyramide des tests
Pour ceux qui ne seraient pas familiers avec la pyramide des tests (ou ceux dont la mémoire doit être rafraichie !), le principe est le suivant :
Mike Cohn testing pyramid
Le premier tiers, la base de la pyramide, représente la partie la plus facilement automatisable. C’est celle qui donne le meilleur ROI dans la mesure où les tests unitaires peuvent être facilement écrits par les développeurs et donnent un résultat immédiat. Plus les tests unitaires seront nombreux, plus la base de la pyramide sera solide.
Le deuxième tiers, celui du milieu, est plus difficile à automatiser. A ce niveau, les tests seront plus orientés métier. Ces tests fonctionnels vont répondre à la question « est-ce que l’on construit la bonne chose ? ». Ils vont permettre de confirmer que les fonctionnalités correspondent bien aux exigences.
Enfin, le dernier tiers, au somment de la pyramide, comporte généralement peu de tests automatisés. A ce niveau, on trouve principalement des tests IHM, plus couteux à écrire et à maintenir. Ils nécessitent souvent un contrôle humain (sur des éléments visuels par exemple).
Ce qu’il manque à la pyramide
Je trouve cette pyramide très utile, et les équipes de test gagnent à en appliquer les principes ou à s’en inspirer. Cependant, quelque chose manque…
Les tests, dans l’ensemble du cycle de vie d’une version, sont exécutés par des personnes différentes, et tous ces tests sont de nature différente (unitaire/intégration/fonctionnel/.., manuel/automatique). Cela amène une difficulté importante: il n’y a pas de vision agrégée de tous ces tests. Par exemple, il est difficile d’obtenir une vision de la complémentarité des tests unitaires et des tests fonctionnels.
Cela génère des trous de test dans l’application : des portions de l’application qui ne sont couvertes par aucun test. Plus ennuyeux, il devient très probable que des bugs ne soient pas repérés dans ces portions non couvertes.
Couverture des tests inconnue
Évidemment, il est généralement impossible d’atteindre une couverture de 100% de l’application par les tests. Comment évaluer les risques liés à ces « trous de test » afin de décider si des tests supplémentaires doivent être exécutés ?
Je suggère deux manières d’évaluer ces risques pour correctement cibler les tests à ajouter.
1. Cibler les risques de régression
L’important est de comparer la version actuelle de l’application à tester avec la version précédente. Cette comparaison va permettre d’identifier les changements où les risques de régression sont les plus élevés.
En associant la couverture des tests à cette information, on obtient une vision claire des risques de régression non couverts par des tests.
Un bon dessin valant mieux qu’un long discours, voici une illustration de ce principe :
Evaluation de la couverture des tests
2. Ajouter une perspective métier
Cependant, même en se concentrant sur les changements non testés, cela peut être un chantier trop vaste lorsque vous n’avez qu’une petite proportion de tests automatisés. Aussi, je propose d’ajouter une perspective métier : on regarde les changements non testés selon les fonctionnalités et les modules fonctionnels de l’application concernée. De cette manière, il devient possible de cibler les nouveaux tests là où les bugs doivent être impérativement évités.
Functional view
Que faire lorsqu’il y a peu de tests automatisés ?
Revenons au sommet de la pyramide, là où vous avez très certainement une majorité de tests manuels. Dans cette situation, vous n’aurez pas suffisamment de temps pour exécuter tous les tests manuels à chaque fois. Il va donc falloir sélectionner les tests les plus pertinents, et les exécuter en fonction de leur criticité, et éventuellement de ce qui n’a pas été testé par les autres types de test.
En combinant les changements, la couverture des tests et la vue métier, non seulement vous allez optimiser le temps passé pour ces tests en équilibrant la quantité de tests automatiques et manuels, mais vous allez également vous concentrer sur les tests les plus appropriés (et ainsi éviter de perdre du temps avec les tests inutiles) et assurer une couverture optimale des risques de l’application.
L’empreinte des tests
Durant les tests, Kalistick enregistre l’empreinte de chaque test ; c’est-à-dire tous les chemins d’exécution dans l’application lorsqu’un test est réalisé. Il ne s’agit pas d’enregistrer pour rejouer, mais d’établir la relation entre chaque test et chaque élément du code. Ainsi, dès lors que notre système identifie un changement dans une version ou un build, il le relie à l’empreinte du test qui couvre précisément ce changement et son risque de régression.
Au fil des jours cette solution est de plus en plus efficace : chaque exécution d’un nouveau test enrichit sa base de connaissance de manière automatique. Plus vous exécutez de tests, plus notre technologie sera à même de de vous aider à concevoir des stratégies de test efficaces.
L’objectif de cette approche est double :
- Optimiser l’efficacité des tests en sélectionnant les plus adaptés pour une campagne de test donnée (et ainsi éviter les pertes de temps avec des tests inutiles, qui couvrent des modules inchangés)
- S’assurer que tous les risques sont couverts, même les risques indirects liés aux régressions provoquées par certains changements.
Conclusion
Dans votre recherche du bon équilibre entre les tests automatisés et manuels pour chaque niveau de la pyramide, cette approche va vous aider à améliorer votre efficacité de test.
