Dans Scrum chaque Sprint crée un incrément qui est un produit partiel potentiellement livrable à la production.
Pour qu’il puisse être déployé en production, l’incrément doit répondre à tous les critères d’acceptation et subir toutes les vérifications nécessaires.
Chaque Sprint doit donc inclure toutes les activités de tests permettant d’obtenir un incrément exploitable que l’on peut livrer à la production.
Ce post introduit l'acronyme PURIFF comme concept pour regrouper l’ensemble des activités de tests à mener durant le Sprint. Chaque élément de l'acronyme correspond à une catégorie de tests :
P : pour les tests de Performances
U : représente les tests Unitaires
R : désigne les tests de non Régression
I : couvre les tests d’Intégration
F : pour les tests Fonctionnels
F : représente les tests (Non) Fonctionnels
Description du périmètre des tests PURIFF
Le périmètre PURIFF inclut les tests suivants :
Performance : Les tests de performance permettent de s’assurer que les temps de réponse du système sont acceptables. Ils consistent à mesurer les temps de réactions de l’application, soumise à une charge d’utilisation donnée. Il existe plusieurs solutions open source et commerciales pour tester les performances. Parmi les plus connus on peut citer : HP Load Runner, IBM Rational Performance Tester, JMeter, etc.
Unitaire : Les tests unitaires sont écrits par les développeurs pour tester les classes de façon unitaire. Ils s’inscrivent en général dans une a stratégie de développement dirigé par les tests ou TDD. Il existe plusieurs solutions que l’équipe Scrum peut utiliser pour écrire et exécuter les tests unitaires : JUnit, NUnit en sont des exemples.
non Régression : L’objectif des tests de non régression est de garantir que des défauts n’ont pas été introduits suite à la modification de l’application. En effet, chaque modification du code est susceptible d’introduire de la régression. Il faut donc retester des fonctionnalités déjà testés. Les tests de non régression constituent une activité fastidieuse notamment dans un contexte Agile, caractérisé par des modifications et des livraisons fréquentes. Ils sont très consommateurs de ressources lorsqu’ils sont exécutés manuellement. Je recommande donc fortement d’automatiser ces tests. L’automatisation peut représenter un coût au départ. Mais ce coût sera rentabilisé par une qualité accru du produit. Fitness, Selenium, la suite Microsoft Test Manager, HP ALM, etc. sont des outils qui peuvent être utilisés pour automatiser les tests de non régression.
Intégration : Les tests d’intégration est le niveau qui se situe juste au-dessus des tests unitaires. Ils consistent à vérifier que les différents modules fonctionnent bien une fois mis ensemble. Ils sont en général exécutés sur un environnement d’intégration continue de façon automatique.
Fonctionnels : Les tests fonctionnels sont écrits et mis en place afin de vérifier que les fonctionnalités de l'incrément répondent aux spécifications définies dans le Backlog du produit. Ils correspondent aux tests d’acceptations des éléments du Backlog (user stories). Ces tests peuvent être déroulés manuellement ou de façon automatisée.
non Fonctionnels : Les tests non fonctionnels permettent de vérifier les aspects non fonctionnels de l’application. Ces aspects sont souvent définis comme étant des exigences non fonctionnelles (user stories techniques). Par exemple : les tests de montée en charge, les tests de robustesse, les tests de sécurité, les tests de portabilité, les tests de stress, etc.
Conclusion
Dans cet article j’ai introduit l’acronyme PURIFF comme concept destiné à regrouper l’ensemble des activités de tests à considérer dans un Sprint (Itération).
Même si tous les incréments ne sont pas destinés à une mise en production, l’équipe Scrum peut utiliser le concept PURIFF comme une check-list pour déterminer les catégories de tests pertinentes à son itération.
Aucun commentaire:
Enregistrer un commentaire