 L’entreprise  Nos offres  Formations Actualités Références

Dossiers thématiques Jobs Contact

Pourquoi et comment rédiger une

stratégie de test sur un projet Agile ?
Vous découvrirez dans cet article pourquoi nous avons besoin d’une stratégie de test agile
de haut niveau servant de ligne directrice aux équipes agiles. Le document de stratégie de
test dans la méthode agile a pour objectif de répertorier les meilleures pratiques et
représente une forme de structure que les équipes peuvent suivre. Pour rappel, être agile ne
signi e pas être non structuré.

Nous vous donnerons ici un exemple de comment rédiger une stratégie de test dans la
méthode agile et ce qu’il convient d’inclure dans ce document.

1. Du plan de test à la stratégie de test

Dans un environnement agile nous travaillons dans de brefs sprints ou itérations. Chaque
sprint ne se concentre que sur quelques exigences ou « user story ». Il est donc évident que
la documentation ne soit pas très complète. En raison de contraintes de temps il n’est peut-
être pas nécessaire de disposer d’un plan de test exhaustif pour chaque sprint. Pour savoir
comment rédiger un bon plan de test vous pouvez consulter cet article. Cependant, une
stratégie de test est primordiale pour dé nir l’ensemble des niveaux de test et leurs critères.

Généralement, une stratégie de test comporte un énoncé de mission qui pourrait être lié aux
objectifs commerciaux plus larges.

Un énoncé de mission typique pourrait être :

Livrer en permanence un logiciel (application) fonctionnel qui répond aux exigences du

client, en fournissant un feedback rapide et la prévention des défauts, plutôt que la détection
des défauts.
Nous utilisons des cookies pour vous garantir la meilleure expérience sur notre site web. Si vous continuez à
Cette mission pourraitutiliser
être dé nie par ce genre de critères :
ce site, nous supposerons que vous en êtes satisfait.

Ok Politique de confidentialité

 Aucun code ne peut être écrit pour une « user story » jusqu’à ce que nous dé nissions
d’abord ses critères d’acceptation / tests.
Une « user story » peut ne pas être considérée complète tant que tous les tests
d’acceptation ne sont pas validés (voir DoD, dé nition of done)
 L’entreprise  Nos offres  Formations Actualités Références
Dans le document sur la stratégie de test agile, il faudrait mettre également un rappel de
l’assurance qualité à tout le monde.
Dossiers thématiques Jobs Contact

Selon la norme ISO 9000 l’assurance qualité est un ensemble d’activités destinées à
garantir que les produits répondent aux besoins des clients de manière systématique
et able.
Dans la méthode agile SCRUM, le contrôle qualité est la responsabilité de tous, pas
seulement des testeurs. Le contrôle qualité concerne toutes les activités que nous
réalisons pour garantir une qualité correcte lors du développement de nouveaux
produits.

Niveaux de test

Matrice des tests agiles de Brian Marick

Tests unitaires

Quoi :  Tout
Nous nouveau
utilisons code
des cookies + refactorisation
pour du code
vous garantir la meilleure hérité ainsi
expérience quesite
sur notre des tests
web. unitaires
Si vous continuez à
utiliser ce site, nous supposerons que vous en êtes satisfait.
Javascript
Ok Politique de confidentialité
Qui :   Développeurs / Architectes techniques 
Où :  Dev local + CI (Intégration de contenu) – partie de la construction

Quand :  dès que le nouveau code est écrit

 L’entreprise
Comment  Nos
:  outils  de type offres
Automated,  Formations
Junit, Actualités
TestNG, PHPUnit Références

Pourquoi :  Pour s’assurer que le code est développé correctement

Dossiers thématiques Jobs Contact
Test API / Service

Quoi :  Nouveaux services Web, composants, contrôleurs, etc.

Qui :   Développeurs / Architectes technique, voir Test analyst technique

Où :  Dev local + CI (Intégration de contenu) – partie de la construction

Quand :  Dès que la nouvelle API est développée et prête

Comment :  Automated, Soap UI, Rest Client, Soap UI pro …

Pourquoi :  Pour assurer que la communication entre les composants fonctionne

Test d’acceptance

Quoi:  Véri cation des tests d’acceptation sur les récits, véri cation des caractéristiques

Qui:   Développeur / SDET / mais de préférence un Test Analyst Manuel

Où:  CI / Environnement de test

Quand:  Lorsque la fonctionnalité est prête et que l’unité est testée

Comment:  test manuel ou automatisé

Pourquoi:  s’assurer que les attentes du client sont satisfaites

Test du système / Test de régression / UAT

Quoi :  Test de scénario, ux d’utilisateurs et voyages types, tests de performances et de

sécurité

Qui :   SDET / Manuel QA / BA / PO

OùNous
:  environnement de transfert
utilisons des cookies pour vous garantir la meilleure expérience sur notre site web. Si vous continuez à
utiliser ce site, nous supposerons que vous en êtes satisfait.
Quand :  une fois le test d’acceptance
Ok
terminé
Politique de confidentialité

Comment :  Tests manuel  automatisés (outils de type Selenium Webdriver, Agilitest,
Cloudnetcare, Test Complete, UFT …)

Pourquoi :  Pour que tout le système fonctionne, une fois intégré

 L’entreprise  Nos offres  Formations Actualités Références

2. Le Backlog du produit
Dossiers thématiques Jobs Contact
La cause la plus fréquente d’échec du développement logiciel est due à des exigences peu
claires, et à une différence d’interprétation des exigences par les différents membres de
l’équipe.

Les « user story » doivent être simples, concises et sans ambiguïté. En règle générale, il est
préférable de suivre le modèle INVEST pour écrire des « user story ».

Les critères d’une bonne « user story » :

Indépendante (de toutes les autres)

Négotiable (initialement)

Vérticale (valeur)

Estimable (bonne approximation)

Su samment petite (a n de s’insérer dans une itération)

Testable (en principe, même s’il n’y a pas encore de test pour)

Le format suivant doit être utilisé pour écrire des « user story »

As a [role]

I want [feature]

So that [bene t]

Il est important de ne pas oublier la partie « béné ces », car chacun devrait être conscient de
la valeur qu’il ajoute en développant l’histoire.

Critères d’acceptation

Chaque « user story » doit contenir des critères d’acceptance. C’est peut-être l’élément le
plus important
Nous quicookies
utilisons des encourage la communication
pour vous garantir la meilleureavec les différents
expérience membres
sur notre site de l’équipe.
web. Si vous continuez à
utiliser ce site, nous supposerons que vous en êtes satisfait.
Les critères d’acceptance doivent être écrits lors de la création de la « user story » et doivent
Ok Politique de confidentialité
être intégrés au corps de l’histoire. Tous les critères d’acceptance doivent être testables.

Chaque critère d’acceptance doit comporter un certain nombre de tests d’acceptance
présentés sous forme de scénarios rédigés.

Il est possible d’utiliser l’approche BDD et le langage au format Gherkin, pour faciliter la
 L’entreprise
communication  Nos
entre les offres acteurs
différents  Formations
(les 3 amigos :Actualités
PO/DEV/QA). Références

Scenario 1 : Title
Dossiers thématiques Jobs Contact

Given [context]

And [some more context] …

When  [event]

Then  [outcome]

And [another outcome]…

3. Ateliers sur « User Story »  / plani cation

de sprint
Dans chaque atelier de création de story, chaque membre de l’équipe découvre les détails de
ces story, ce qui permet aux développeurs et à l’assurance qualité de connaître la portée du
travail. Tout le monde devrait avoir la même compréhension de l’histoire.

Les développeurs doivent avoir une bonne compréhension des détails techniques impliqués
dans la présentation de l’histoire, et l’assurance qualité doit savoir comment l’histoire (US)
sera testée et s’il existe des obstacles à son exécution.

Prévenir les défauts – Membres de l’équipe

Dans les ateliers des stories, PO, Dev, QA et BA doivent être impliqués.

Les scénarios (valides, non valides et cas particuliers) doivent être pris en compte (le
contrôle qualité peut apporter une énorme valeur ajoutée en ré échissant de manière
abstraite à l’histoire) et consignés dans des chiers de caractéristiques.

C’est pour cela qu’il est important de noter que ce sont les scénarios (plus que toute autre
chose) qui révèlent des défauts lors du test du produit. Plus vous consacrez d’efforts et de
temps à cette activité, plus vous obtiendrez les meilleurs résultats.

Étant
Nousdonné que
utilisons desla majorité
cookies pourdes
vousdéfauts
garantir lasont dus expérience
meilleure à des exigences
sur notrepeu claires
site web. et vagues,
Si vous continuez à
utiliser ce site, nous supposerons que vous en êtes
cette activité contribuera également à empêcher la mise en œuvre de comportements satisfait.

incorrects car tout le monde devrait Ok avoir la même

Politique compréhension de l’histoire.
de confidentialité

De même, lors des réunions de plani cation de sprints, les estimations fournies pour une
story doivent inclure l’essai de test ainsi que l’effort de codage. Un contrôle qualité (manuel
et automatisé) doit également être présent dans les réunions de plani cation du sprint pour
fournir une estimation permettant de tester le récit.
 L’entreprise  Nos offres  Formations Actualités Références

Développement

Dossiers thématiques Jobs Contact

Pyramide de test

Lorsque le développement commence, le nouveau code de production et / ou la

refactorisation du code existant doivent être complétés par des tests unitaires écrits par les
développeurs et revus par des pairs par un autre développeur ou un SDET quali é.

Toute validation dans le référentiel de code doit déclencher une exécution des tests unitaires
à partir du serveur CI. Cela fournit un mécanisme de retour rapide à l’équipe de
développement.

Les tests unitaires garantissent que le système fonctionne au niveau technique et qu’il n’y a
pas d’erreur dans la logique.

Lors de l’automatisation des tests, il est également important de respecter cette pyramide et
donc de commencer par automatiser les tests unitaires, puis les tests de service /
composant / intégration.

Nous utilisons des cookies pour vous garantir la meilleure expérience sur notre site web. Si vous continuez à
Le volume de tests automatisés doit être plus important en bas de pyramide car ces tests
utiliser ce site, nous supposerons que vous en êtes satisfait.
sont plus rapides et moins coûteux.
Ok Politique de confidentialité

 Test développeur

En tant que développeur, agissez comme si vous n’aviez aucune assurance qualité dans
l’équipe ou l’organisation. Il
 L’entreprise  Nos estoffres
vrai que les QA ont des mentalités
 Formations différentes,
Actualités mais vous
Références
devriez tester au mieux de vos capacités.

Vous pensezthématiques
Dossiers gagner du tempsJobs
en passant rapidement à la story suivante, mais en réalité,
Contact
lorsqu’un défaut est détecté et signalé, il faut plus de temps pour le résoudre que de passer
quelques minutes à s’assurer du bon fonctionnement de la fonctionnalité.

Tout nouveau code et / ou refactorisation du code existant doit comporter des tests
unitaires appropriés qui feront partie du test de régression unitaire.

Tests d’acceptance automatisés et tests non

fonctionnels

Les tests d’acceptance automatisés comprennent des tests d’intégration, des tests de
service et des tests d’interface utilisateur visant à prouver que le logiciel fonctionne et
qu’il est conforme aux exigences et aux spéci cations de l’utilisateur. Les tests
d’acceptation automatisés sont généralement écrits en langage Gherkin et exécutés à
l’aide d’un outil BDD tel que le Cucumber. Pour aller plus loin vous pouvez consulter
notre article sur  « Comment utiliser la méthode BDD dans les projets agiles ? »
Les tests non fonctionnels (performances et sécurité) sont aussi importants que les
tests fonctionnels. Ils doivent donc être exécutés à chaque déploiement.
Les tests de performance doivent véri er les métriques de performance sur chaque
déploiement pour ne pas dégrader les performances.
Les tests de sécurité doivent véri er les vulnérabilités de sécurité de base dérivées
d’ OWASP. Des outils comme Kiuwan ou Sonar peuvent vous aider à réaliser des tests
de ce type.

Il est essentiel que ce processus soit entièrement automatisé et qui nécessite très peu de
maintenance pour tirer le meilleur parti des déploiements automatisés. Cela signi e qu’il ne
devrait y avoir aucun échec de test intermittent, problème de script de test ou
d’environnement défectueux.

Les échecs doivent uniquement être dus à des défauts de code authentiques plutôt qu’à des
problèmes de script. Par conséquent, tout test ayant échoué qui n’est pas dû à de véritables
échecs doit être corrigé immédiatement ou supprimé du pack d’automatisation a n d’obtenir
des résultats cohérents.
Nous utilisons des cookies pour vous garantir la meilleure expérience sur notre site web. Si vous continuez à
utiliser ce site, nous supposerons que vous en êtes satisfait.
Les tests de régression
Ok Politique de confidentialité

Il ne faut pas s’attendre à trouver beaucoup de défauts. Leur objectif est uniquement de
fournir des informations selon lesquelles nous n’avons pas des fonctionnalités majeures qui
ne fonctionnement plus d’une version à une autre. Il devrait y avoir très peu de tests de
régression manuels.
 L’entreprise  Nos offres  Formations Actualités Références

Pack de 15 min :

Dossiers thématiques Jobs Contact

Ce pack contient uniquement des fonctionnalités de haut niveau permettant de s’assurer
que l’application est su samment stable pour permettre un développement ou des tests
supplémentaires.

Par exemple, pour un site Web de commerce électronique, les tests inclus dans ce pack
pourraient être:

Recherche de produit
Évaluation du produit
Item d’achat
Création de compte / Connexion au compte

Pack de régression complet – ne devrait pas durer plus d’une heure

Ce pack contient la suite complète des tests de régression et contient tout ce qui n’est pas
inclus dans le pack de 15 minutes.

Ici, l’objectif est d’obtenir un retour rapide avec un plus grand nombre de tests. Si le retour
d’informations prend plus d’une heure, ce n’est pas rapide. La solution serait de soit réduire
le nombre de tests en utilisant la méthode de test par paires, créer des packs de tests basés
sur le risque ou exécuter les tests en parallèle.

Les tests de validation utilisateur (UAT) et tests

exploratoires

Il n’y a aucune raison pour que l’UAT et les tests exploratoires ne puissent pas s’exécuter
en parallèle avec les tests d’acceptance automatisés. Après tout, ce sont des activités
différentes et visent à trouver des problèmes différents. Le but d’UAT est de s’assurer que les
fonctionnalités développées ont du sens sur le plan commercial et sont utiles aux clients.

Le responsable de produit (Product Owner) doit exécuter des tests d’acceptation

utilisateur ou des tests d’acceptance commerciale pour con rmer que le produit construit
correspond aux attentes et qu’il correspond aux attentes de l’utilisateur.
Nous utilisons des cookies pour vous garantir la meilleure expérience sur notre site web. Si vous continuez à
Les tests exploratoires doivent
utiliser se nous
ce site, concentrer sur que
supposerons les scénarios
vous en êtesd’utilisateur
satisfait. et rechercher les
bugs non trouvés par l’automatisation. Les
Ok
tests exploratoires ne doivent pas détecter des
Politique de confidentialité
bugs triviaux, mais plutôt des anomalies plus subtiles. 
 Le critère « DONE »

Une fois que toutes les activités ci-dessus sont terminées et qu’aucun problème n’a été
trouvé, la « user story »est terminée
 L’entreprise Nos offres !  Formations Actualités Références

Pour conclure, nous espérons que toutes ces indications vous aideront à rédiger votre
document dethématiques
Dossiers stratégie de testJobs
agile. Évidemment,
Contact cela doit être adapté aux besoins de votre
organisation.

Pour aller plus loin, vous pouvez consulter notre article sur le thème « Comment mesurer la
qualité logicielle ? »

Il peut aussi parfois être utile d’avoir une vision externe pour challenger sa stratégie de test,
aider à accompagner le changement ou choisir des outils de test par ex. C’est dans cette
optique que nous avons mis en place une offre AUDIT avec des équipes de consultants aux
pro ls complémentaires (Craftman, Test Manager, formateur BDD, Spécialiste en
Automatisation de test …) ainsi que des formations sur la QA.

Vous souhaitez suivre nos articles ? Abonnez-vous à notre newsletter mensuelle via nos
dossiers thématiques !

Vous avez aimé cet article ? Partagez-le avec vos amis chasseurs de bugs, DEV, PO   😊

Par All4Test | novembre 20th, 2019 | Dossiers thématiques

Share This Article       

Articles similaires

Nous utilisons des cookies pour vous garantir la meilleure expérience sur notre site web. Si vous continuez à
utiliser ce site, nous supposerons que vous en êtes satisfait.

Ok Politique de confidentialité

 

 L’entreprise  Nos offres  Formations Actualités Références

Dossiers thématiques Jobs Contact

Inscrivez-vous à notre
ISTQB : passez le test !
newsletter
  
Partageons le Meet Up
© Copyright 2017
Nous recrutons des
All4Test
testeurs

Contactez-nous J'accepte que mon

adresse email soit
Mentions légales
utilisée a n de recevoir la
newsletter d'All4Test.

S'INSCRIRE

Could not connect to the reCAPTCHA service. Please check your internet connection and reload to
get a reCAPTCHA challenge.

Nous utilisons des cookies pour vous garantir la meilleure expérience sur notre site web. Si vous continuez à
utiliser ce site, nous supposerons que vous en êtes satisfait.

Ok Politique de confidentialité
