Point Clés
Cet article explorera les distinctions entre les tests classiques et agiles, en examinant le concept de test continu à travers l’explication du quadrant de Brian Marick. Nous aborderons également les responsabilités de chaque acteur, notamment celles du responsable qualité. En conclusion, des recommandations seront fournies.
POURQUOI UNE PRATIQUE DE TEST AGILE
L’approche du test que nous vous présentons a des finalités différentes des méthodes classiques, c’est pour cela que nous les nommons tests agiles.
Définition
Notre définition du test agile: Le test agile vise à partager les responsabilités du test en automatisant au maximum une spécification collaborative écrite sous forme d’exemples afin de livrer un produit satisfaisant pour l’équipe de développement mais surtout pour nos utilisateurs.
COMMENT METTRE EN PLACE DU TEST AGILE
LES NOUVEAUX DEFIS DU TEST LOGICIEL : VERS UN NOUVEAU MONDE
Démarche classique
- Tester pour trouver des anomalies
- Planifier des campagnes de test
- Spécialiser les métiers du test
Démarche Agile
- Tester pour spécifier
- Tester en continu
- Partager les responsabilités des tests
PYRAMIDE DU TEST CLASSIQUE VS PYRAMIDE DU TEST AGILE
TESTER EN CONTINU
Notre objectif est de donner un maximum de visibilité sur la progression du produit et pouvoir affiner et/ou faire évoluer les besoins des utilisateurs au plus vite.
Nous devons donc avoir des éléments Done le plus rapidement possible, les tests font partie de notre définition du Done.
Stratégie de test et analyse des risques : quadrants de Brian Marick
Cadran n°1:
- Le premier quadrant représente le développement piloté par les tests (Test Driven Development, TDD)
- Le processus de l’écriture des tests avant le code aide les développeurs à bien concevoir leur code. Les tests unitaires et des composants sont automatisés et écrits dans le même langage de programmation que l’application.
- → Qualité interne
Cadran n°2:
- Les tests dans le quadrant 2 soutiennent également le travail de l’équipe de développement.
- Avec le développement agile, ces tests sont dérivés à partir d’exemples et ils décrivent le détail de chaque User Story.
- Les Key Users utilisent ces tests pour définir la qualité externe du produit et participent généralement à leurs rédactions.
- → Qualité externe
Cadran n°3:
- Lors du processus de développement plusieurs cas de figures peuvent se présenter :
- Un des exemples utilisés est erroné.
- Le Key User a oublié une fonctionnalité
- Ou une règle de gestion;
- Un des exemples fournis par le client est mal compris par l’équipe;
- Etc.
- Les tests du quadrant 3 entrent en jeu pour répondre aux problèmes ci-dessus. Le principe est d’imiter la façon avec laquelle un utilisateur réel travaille avec l’application ; il s’agit bien de tests 100% manuels.
Cadran n°4:
- Le code de l’application doit prendre en considération certaines exigences non fonctionnelles comme la performance, la sécurité ou encore l’interaction avec d’autres systèmes
- Les tests techniques et qui critiquent le produit doivent être considérés à chaque étape du cycle de développement et surtout ne pas attendre la fin d’une release.
- Dans de nombreux cas, ces tests devraient même être faits avant les tests fonctionnels.
LES TESTS, RESPONSABILITÉ PARTAGÉE
L’approche classique favorise la séparation entre les activités de test et de développement.
Au contraire, les méthodes agiles favorisent une approche “équipe étendue”
Le testeur fait partie de la Dev Team
Le partage de responsabilité implique deux conditions :
- Une vision commune, connue et partagée (implication dès le début)
- La connaissance des utilisateurs finaux (en complément/continuité des pratiques UX)
A-T-ON ENCORE BESOIN DES TESTEURS
Les activités du testeur changent avec les mutations que subissent et initient l’IT.
Nous avons besoin de compétences spécifiques autour du test : rôle de Quality Analyst
RECOMMANDATIONS
- Intégrer les tests dès la conception.
- Responsabiliser les Stakeholders aux tests.
- Considérer le test comme une activité collaborative
- Et pourquoi pas utiliser les tests pour produire des spécifications et du code utile ?
0 commentaires