Équipe de développement : User Stories, quand les tester ?
A quel moment l’équipe de développeurs doit-elle tester ses développements ? Découvrez dans quelles conditions et à quel moment les développeurs testent leur travail lors d’un sprint de développement.
Dans le cadre d’une méthode agile et plus particulièrement la méthode Scrum, à quel moment est-il le plus pertinent de réaliser les tests fonctionnels de l’application en cours de développement ?
Pour commencer nous allons détailler ce qu’il faut éviter de faire lors des phases de tests effectués par les développeurs.
Faire un « freeze time » juste avant avant le Sprint Review
Le premier point de vigilance est d’éviter le « freeze time ». Le freeze time intervient juste après le sprint de développement c’est-à-dire quand l’équipe de développeurs a traité toutes les users stories contenues dans le sprint backlog. Le freeze time est le fait que l’équipe de développement va aller tester les user stories développées pendant un temps donné, une journée par exemple. Puis à l’issue de cette période de freeze time, l’équipe Scrum va présenter les fonctionnalités terminées et testées aux parties prenantes du projet.
Le problème qui est très souvent rencontré lors d’une freeze time est que les développeurs se rendent compte, durant cette période alloué à leurs tests, qu’un ensemble de choses ne vont pas et qu’elles doivent être modifiées. Malheureusement l’équipe de développement n’aura pas le temps de modifier l’ensemble des erreurs repérées avant la réunion de Sprint Review (ou revue de sprint en français). L’équipe va alors présenter quelque chose de non terminé.
Cette situation est d’autant plus déstabilisante que les développeurs vont vouloir modifier directement les erreurs sur le produits durant la freeze time et générer encore d’autres erreurs.
Ce qui aurait pour conséquence que le produit fonctionne encore moins bien à la fin de la freeze time qu’au début, car modifications ont été appliquées au logiciel dans l’urgence.
Gérer les tests en temps réel : le juste à temps
La meilleure gestion des tests est de tester en temps réel les fonctionnalités développées. L’équipe de développeurs développent puis un membre de l’équipe de développement qui a des compétences en test va aller tester directement après. Il faut à tout prix éviter d’attendre que toutes les fonctionnalités du Sprint Backlog soient finalisées pour tester. Faire ceci revient à faire de la gestion de projet en cascade (Waterfall) et non plus en agile. Sous le méthode Scrum le processus à suivre est donc le suivant :
- Etape 1 : l’équipe de développement sélectionne la user sotry qu’elle veut développer dans le sprint backlog,
- Etape 2 : les développeurs réalisent la user story,
- Etape 3 : une personne de l’équipe de développeurs qui a des compétences en test va tester la user story,
- Etape 4 : les développeurs traitent les corrections remontées lors du test,
- Etape 5 : la user story est re-testée par le testeur puis elle est validée quand tout est OK,
- Etape 6 : les développeurs choisissent une nouvelle user story à traiter.
Ce cycle se répète ensuite jusqu’à ce que toutes les user stories soient validées par le testeur. Il s’agit donc bien ici de tester les développements au fur et à mesure pour les corriger au fur et à mesure. Et non pas l’ensemble en une fois à la fin.
Plus on attend pour tester un ensemble de fonctionnalités, plus les retours seront nombreux et plus le temps de correction de l’ensemble de ces retours sera long.
Il est important également que ce soit une personne de l’équipe de développeur qui a des compétences en test qui va aller tester l’application et non pas une personne extérieure à l’équipe, qu’il va falloir appeler et attendre pour qu’elle vienne tester, et encore moins faire au appel Product Owner à ce moment là. Les tests ne se font donc pas à la toute fin du sprint mais en temps réel.
Découvrez comment Bocasay applique la méthode Scrum au sein de ses projets.
Source : agiliste.fr, laminuteagile.com
