La plupart des méthodes de test recommandent l’utilisation d’un document de stratégie de test dès le début d’un projet. Néanmoins, une des valeurs du manifeste agile est « des logiciels opérationnels plus qu’une documentation exhaustive » ce qui pourrait rendre ce document inutile.
Laissez-moi vous expliquer exactement ce qu’est une stratégie du test et comment ce document peut être adapté au Scrum et plus généralement aux méthodes agiles.
Qu’est-ce qu’une stratégie de test ?
Le but d’une stratégie de test est d’optimiser les processus de test. Comme l’exhaustivité des tests est clairement impossible (et essayer de s’en approcher coûterait beaucoup trop cher), il est important d’avoir une vision claire de vos tests.
Pour cela votre stratégie doit répondre aux questions « 6W » par rapport à votre produit :
- Pourquoi (Why) avez-vous besoin de tester votre application ? Normalement c’est parce qu’il y a un risque, le test permet de limiter les risques et il est important de tester plus ce qui représente un risque plus important.
- Quoi (What) devez-vous tester dans votre application ? C’est clairement lié au « Pourquoi » mais dépend aussi de votre organisation (partenaires, …)
- Quand (When) testez-vous ? Le plus tôt est le mieux (encore plus en agile). Le but est de comprendre le planning global du projet ainsi que l’impact que cela peut avoir sur les activités de test.
- Comment (hoW) testez-vous ? Cela inclut les processus, les techniques de conception et les outils de test.
- Qui (Who) teste ? Il est important de définir une équipe avec les compétences requises (principalement pour l’automatisation)
- Où (Where) testez-vous ? Il est très important de s’assurer d’avoir les bons environnements afin de savoir que les tests pourront être exécutés.
Il est très important de penser à toutes ces questions au tout début du projet afin d’optimiser les coûts des tests.
Pour cela vous devez d’abord comprendre qu’il y a un coût optimal pour la qualité d’une application :
Tout tester avec le même effort est clairement très loin d’être optimal.
Le but d’une stratégie de test est d’essayer d’atteindre ce point optimal. Cela commence avec une bonne analyse de risque et d’une bonne compréhension du coût d’un défaut.
Une règle importante du document de stratégie de test est que c’est un document utilisable régulièrement et vivant. Ce n’est pas un document que l’on écrit pour des raisons obscures et qui n’est ensuite pas utilisé.
Vous devez donc le laisser simple et constamment l’adapter au contexte (qui changera car nous sommes dans la vraie vie).
La stratégie de test agile c’est les Definition of Done (DoD)
En regardant la définition précédente, on voit clairement qu’une stratégie de test est nécessaire et qu’elle ne dépend pas de la méthode de développement utilisée. En regardant les pratiques des méthodes agiles on s’aperçoit que les Definition of Done sont en fait une stratégie de test. La stratégie reste donc très importante et discutée en agile même si elle ne porte pas le même nom. En Scrum on doit mettre en place la Definition of Done pendant le sprint 0. Le sprint 0 est évidemment un bon moment pour mettre en place les outils, l’approche d’automatisation des tests, les ressources, les environnements dont l’équipe aura besoin. Si vous ne pensez pas tôt à tout cela vous risquez d’avoir très vite une dette technique colossale.
Néanmoins, rien ne vous oblige à avoir un document formel. Une stratégie de test peut être une simple page wiki tant que cette page wiki est maintenue et utilisée par l’ensemble des membres de l’équipe afin de s’assurer que cette stratégie est bien appliquée.
La stratégie de test à l’heure de la rétrospective
Un point très important et déjà mentionné est que la stratégie doit constamment être adaptée au contexte.
La rétrospective est un bon moment pour parler de cette stratégie et repenser aux « 6W ».
Et n’oubliez pas les principes de test agile
Pour conclure, les cycles de vie agiles (comme Scrum) ont encore besoin de stratégies de test. Ces stratégies sont appelées les Definition of Done. Cela implique donc qu’un testeur doit faire partie de l’équipe dès le sprint 0 afin d’éviter des dettes techniques qui apparaissent trop souvent au début des projets agiles avec des équipes peu expérimentées qui confondent développeur et codeur.
En écrivant cette stratégie de test vous devrez :
- Vous rappeler que l’activité de test n’est pas une phase du projet (ce n’est pas à la fin du sprint que le commence à tester)
- Penser en fonction du quadrant de test (principalement au quadrant 4, qui inclut les tests non fonctionnels)
- Beaucoup automatiser en respectant la pyramide de test
- Faire du test exploratoire
- Adopter des standards de code (pour éviter la dette technique)
Article original en anglais publié sur ce blog : https://testeuragile.blogspot.com/
Traduit par Marc Hage Chahine
4 Responses
Bonjour,
Auriez-vous un exemple de stratégie de test en contexte agile à partager ?
Merci.
Bonjour,
Il y a un exemple de stratégie (ou plan) de test (en anglais) dans la norme ISO/IEC/IEEE 29119-3 en annexe F…
Le voici traduit par mes soins :
*Plan de test pour : Nouveau système d’abonnement (NSA) Version : Itération 3*
*Couvertures* : Itération 3 du NSA, y compris les résultats des itérations précédentes.
*Responsabilités*: Chaque itération est effectuée par l’équipe. Les développeurs se réfèrent finalement au responsable du développement (Ursula) et les testeurs au responsable de l’assurance qualité (Stephan).
Risques : Les risques sont énumérés sur chaque user story. Le risque spécifique à cette itération est l’accès aux données en direct.
*Stratégie de test* : N’oubliez pas de :
– Créer les tests automatisés des stories avant de coder, tester le nouveau code et la régression avant de marquer la story à « Done ».
– Tester la régression de l’ensemble avant la revue de sprint.
– Inclure les coûts des tests dans les estimations, et estimer chaque user story avant de l’ajouter à une itération
– Retourner au backlog tous les points qui ne peuvent être réglés d’ici la fin du sprint, y compris concernant la dette technique
– Utiliser les techniques de conception de test les plus appropriées aux critères d’acceptation, en gardant à l’esprit que les stories risquées nécessitent des tests plus approfondis
– S’assurer et vérifier que les test couvrent plus de 90 % du code
– S’assurer qu’aucun défaut ne reste en suspens afin la fin du sprint
– Définir les test ATDD dans l’itération avec la participation du client/utilisateur
– Avant la revue de sprint, tester l’itération dans l’environnement de présentation
– Couvrir les activités de test lors des stand up quotidiens
– Stocker tous les scripts de test dans l’outil ABC, afin qu’ils soient disponibles pour un nouveau test ou en test de régression
– Rédiger un rapport sommaire de test à la fin de chaque itération et le placer dans le portail du projet
Bonjour,
Quels sont les différences entre « Définition of Done » et « Définition of Ready » comme j’ai pu voir apparaître dans certains projets auxquels j’ai pu participer ?
Cordialement
Bonjour Frédéric,
le Definition of Done c’est le moment à partir duquel on considère que le travail est fini et que l’on peut donc passer à autre chose.
Le Definition of Ready c’est celui à partir duquel on peut commencer à travailler sur un élément (les conditions de départ).
Sur une même chaîne de développement on peut avoir la DoD d’une équipe qui est la DoR de celle intervenue juste avant