Article plus récent et plus complet (mais beaucoup plus long) disponible ici.
Les méthodes agiles et particulièrement la méthode Scrum sont de plus en plus utilisées dans les projets.
Quelle est la place du testeur dans ce type d’organisation?
Petit rappel :
La méthode Scrum est une méthode de travail avec des cycles courts (« sprints ») de 2 à 4 semaines, et une construction incrémentale du logiciel, avec, à la fin de chaque cycle, un logiciel « utilisable ».
Le but est d’éviter l’effet tunnel des projets en cycle en V, de s’adapter plus facilement à des changements dans les besoins, avoir une amélioration continue de l’efficacité de l’équipe, et pouvoir montrer l’état du logiciel plus fréquemment au client afin de s’assurer que le logiciel développé est bien celui voulu par le client (ou utilisateur final).
Cette méthode de travail à plusieurs particularités dont voici les principales par rapport à un cycle en V classique :
1. Le logiciel est défini par de grandes fonctionnalités, les Epics, elles-mêmes subdivisées en User Stories qui sont les entités sur lesquelles l’équipe travaille
2. Une équipe est constituée de 5 à 9 personnes (à partir de 10 on peut en faire 2 !) regroupant toutes les compétences dont le projet a besoin.
3. L’équipe est un tout et est responsable en tant qu’équipe. Elle fonctionne avec ses règles mais est garante de la qualité du logiciel (on ne pointe pas la responsabilité d’une personne en particulier !)
4. Le but est d’être le plus efficace possible (avoir la meilleure vélocité) au sein de l’équipe. Pour cela, tout membre de l’équipe peut être amené à aider sur un aspect du projet, qui, à priori n’est pas sa spécialité (on parle de compétences en T, c’est-à-dire spécialiste sur un domaine mais connait également d’autres compétences de façon plus basique)
5. La méthode Scrum encourage très fortement la communication entre les membres de l’équipe.
Revenons à notre métier de testeur et à sa place dans cette méthodologie.
Comme énoncé précédemment l’équipe est responsable, pas une personne en particulier. Le testeur n’est donc pas le seul responsable des tests dans l’équipe (et heureusement car sinon le projet ne pourrait pas avancer s’il est absent !).
Scrum vs Cycle en V :
Selon ISTQB la principale différence entre le cycle en V et les méthodes agiles c’est l’automatisation des tests. Je ne suis pas tout à fait d’accord avec cette vision. Certes les méthodes agiles (en fait, les méthodes incrémentales) sont plus sujettes à l’automatisation des tests (par exemple les tests de régressions) que le cycle en V mais l’automatisation existe aussi avec les cycles en V. De plus il y a d’autres différences que je juge plus importantes dans le métier du test entre le cycle en V et la méthode Scrum. La première est que la stratégie de test, les tests à effectuer, la qualité du logiciel sont le fruit de discussions de toute l’équipe. Le testeur est présent pour inculquer la philosophie de la qualité, pour apporter son expertise mais les décisions sont les décisions l’équipe (elles peuvent donc différer de ce que le testeur pensait faire initialement). La seconde est que le testeur n’est pas voué à ne travailler que sur les tests fonctionnels (il peut par exemple aider sur les spécifications) et inversement il n’est pas nécessairement le seul à s’occuper des cas de tests fonctionnels (un développeur peut travailler sur l’automatisation de cas de tests).
Dans la méthode Scrum, encore plus que dans le cycle en V la communication est un élément clé du métier de testeur. Il faut savoir convaincre, se rendre disponible, aider les membres de son équipe mais aussi écouter. Avec la méthode Scrum, on a la chance de travailler avec des personnes dont le métier est différent du nôtre, on peut donc discuter avec eux, voir leurs contraintes et mieux les comprendre. Cette méthode pousse donc encore plus le testeur à bien communiquer, à trouver les bons compromis afin que tout membre de l’équipe se sente impliqué dans la qualité du logiciel en développement.
Les tests de régressions :
Un autre point très important qui diffère du cycle en V dans cette méthode est le travail sur les tests de régressions. C’est d’ailleurs pour cela que l’ISTQB parle beaucoup d’automatisation des tests. La méthode Scrum est une méthode incrémentale. A chaque fin de sprint on a un produit qui est le produit que l’on avait au début du Sprint enrichi de nouvelles fonctionnalités ajoutées avec les User Stories effectués durant le sprint. Il faut donc s’assurer que le développement des nouvelles fonctionnalités n’a pas cassé les anciennes. Pour cela on utilise des tests de régression, et, comme vous pouvez vous en douter, il y en a de plus en plus au fur et à mesure que le projet avance et ils sont également très régulièrement exécutés. Le temps d’exécution peut alors être particulièrement long c’est pour cela qu’on automatise les cas. Il faut faire très attention avec l’automatisation des tests. Le but n’est pas d’automatiser (ou de faire passer en test de régression) tous les tests qui ont servis à valider une User Story (on appelle ces tests les tests de validation). La raison est simple, les tests automatisés ont un coût. Le coût principal est le coût de maintenance, cela coûte moins de temps (et donc d’argent) de mettre à jour 10 tests que 100 (si on ne fait pas attention on peut se retrouver avec des milliers de tests dont le quart ne passent pas mais qui sont impossible à mettre à jour faute de temps). Le temps d’analyse des cas en échec ne doit pas non plus être négligé. Là encore analyser 5 cas en échec prends moins de temps qu’en analyser 50 (même si 1 bug peut impacter plusieurs cas). Là encore, dans cette sélection des tests de régression l’expertise du testeur est très importante pour l’équipe. Pour reprendre l’exemple de mon post précédent avec la connexion à l’application mail, en test de validation on doit tester les 20 erreurs (si elles sont dans les spécifications), par contre en test de régression cela n’est pas forcément nécessaire, tester que 1 ou 2 erreurs (la ou les 2 plus fréquentes) peut suffire.
Conclusion :
Le testeur en Scrum est plus garant d’un état d’esprit et d’une philosophie de qualité que quelqu’un qui s’occupe uniquement des cas de tests fonctionnels. La partie communication du métier est beaucoup plus importante qu’en cycle en V. D’un autre côté, le testeur doit se rappeler qu’il est au service de l’équipe et que se faisant, il peut être amené, pour le bien de l’équipe à faire autre chose que du test. De la même manière il peut en recevoir pour le test fonctionnel. Dans une équipe Scrum la solidarité est une valeur primordiale.
Plus d’informations sur la méthode scrum : http://www.agiliste.fr/guide-de-demarrage-scrum/
N’hésitez pas à rejoindre le groupe Le métier du test
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles.
3 Responses
Bonjour,
Article très pertinent!
Le guide de démarrage Scrum est également un très bon article pour démarrer avec la méthode Scrum.
Un petit pouce bleu, merci !