Kanban et tests : une approche agile et pragmatique

Sommaire

Introduction

Une user story, quelle qu'elle soit, est un ensemble de tâches prédéfinies

Une user story 2 est essentiellement une exigence fonctionnelle ou technique de haut niveau pour votre solution. Elle exprime une capacité souhaitée et la manière dont les utilisateurs ou le système l'utiliseront probablement.

Lorsqu'une équipe de développement traite une story, il existe un ensemble de tâches que le développeur DOIT effectuer :

Comprendre les besoins

Lisez la story, engagez une conversation directe aussi proche que possible de l'utilisateur final, reformulez, dessinez, jusqu'à ce que vous puissiez...

Écrire les tests de logique métier

Concevez vous-même quelques tests pour vérifier la story. Concevez au moins un test positif et un test négatif, mais n'essayez pas de couvrir tous les cas de test. L'objectif ici est de vous assurer que vous comprenez réellement le besoin. Si vous ne parvenez pas à écrire un test utile (automatisé ou manuel), c'est que vous ne comprenez clairement pas le besoin et vous devez revenir à la tâche « Comprendre les besoins ».

Analyser la conception

Réalisez votre analyse d'impact et votre conception. C'est le moment où vous devez vous assurer de savoir quel code, quels fichiers et quels artefacts vous devez extraire, quelles classes, méthodes, vous devez modifier ou créer et régler avec vos pairs les points de désaccord sur le modèle de données, si vous devez l'adapter.

Coder les tests unitaires

C'est le moment où vous créez et/ou adaptez le code, les paramètres de configuration, les artefacts. Vous pouvez ici avoir plusieurs tâches courtes. Vous devez garantir la qualité et la couverture les plus élevées en écrivant et en exécutant des tests unitaires indépendants.

Exécuter les tests de logique métier

Exécutez vos tests fonctionnels ou techniques. Utilisez les tests définis précédemment pour vous assurer que ce que vous avez implémenté fonctionne et répond aux besoins que vous avez compris.

Revue de code

Faites relire votre code par l'un de vos pairs, ne laissez pas passer les « code smells ». Refactorisez en profondeur votre code dès maintenant et revenez à la tâche « Coder les tests unitaires » si nécessaire.

Construire les tests de smoke

Construisez et exécutez vos tests de smoke sur votre environnement de bac à sable. Avant de committer quoi que ce soit, assurez-vous que la build fonctionne et n'a rien cassé de majeur.

Commit

Committez et laissez l'intégration continue s'exécuter.
Surveillez les retours automatisés et prenez des mesures correctives.
Si votre solution bénéficie de tests automatisés et d'analyse de code, vous devriez obtenir un retour rapide, plus facile et plus rapide à corriger tant que vous êtes encore immergé dans la fonctionnalité que vous avez développée.

Démo

Exécutez vos tests exploratoires et faites votre démo.
Si vous avez suffisamment d'expérience, faites-le seul, sinon faites-le en binôme avec un Business Analyst ou un expert métier. Itérez vers toute action corrective nécessaire.

On pourrait dire qu'il s'agit là d'un ensemble de tâches évident que tout développeur professionnel doit accomplir. Probablement... mais pour de nombreuses entreprises, les développeurs professionnels ne sont pas la norme. De nombreux « débutants », tout juste sortis de l'école, doivent être formés avant de devenir productifs, en particulier dans un projet Agile.

Une story est ensuite livrée une tâche à la fois

Le modèle ci-dessus peut être adapté à n'importe quel contexte. Ce qui importe pour un projet agile privilégiant le management visuel, c'est la manière dont vous rendez ensuite la progression et les blocages visibles, pour une résolution rapide.

Vous pouvez alors utiliser un flux piloté par Kanban assez simple, pour chaque tâche :

• En cours
• Bloqué
• Terminé

C'est aussi simple que ça !


Vous pilotez vos tâches pour une story donnée, une à la fois.

• Vous conservez l'avantage de gérer des limites de travail en cours (Work-in-Progress)
• Vous ne pouvez pas avoir plus de tâches « en cours » que vous n'avez de personnes dans l'équipe
• Vous ne pouvez pas prendre une nouvelle tâche sur une user story si la précédente est bloquée
• Toute tâche bloquée est immédiatement rendue visible, et vous pouvez la traiter sans même attendre le stand-up quotidien

La qualité est construite pendant le développement, pas vérifiée après

Comme vous l'avez remarqué, plusieurs tâches de ce micro-processus sont consacrées au test. Rien de nouveau ici. Il s'agit simplement de donner aux « développeurs » l'habitude de les réaliser.

Tout au long de ce processus, XQual est utilisé en permanence.

Lorsqu'une équipe de développement traite une story, il existe un ensemble de tâches que le développeur DOIT effectuer :

Tests de logique métier

Ils sont définis et conçus dans XQual.
Ils peuvent être des tests manuels ou automatisés.
Ils peuvent être partagés avec une équipe QA, afin qu'elle n'ait pas à les refaire.
Ils peuvent être utilisés plus tard comme test de smoke.
Ils peuvent être utilisés par les business analysts ou les experts métier pour s'assurer que vous avez compris les besoins.
Ils peuvent être utilisés pour la démonstration de revue de sprint.

Tests unitaires

Ils peuvent être analysés par XQual et importés automatiquement pour être utilisés dans des campagnes de régression sur l'environnement d'intégration.
XQual facilite grandement la gestion de ces tests unitaires évitant au développeur de décrire chaque test. Les résultats sont extraits du format de sortie standard de tout framework de test compatible xUnit.

Tests de smoke

Les tests de smoke et les campagnes de régression sont facilement définis à partir des tests créés pendant le développement.

Tests exploratoires

Ils permettent de garantir la qualité des nouvelles fonctionnalités pour lesquelles vous n'avez peut-être pas le temps de créer des tests automatisés pendant le développement.
Notez que de nombreux clients préfèrent gérer l'automatisation des tests comme des stories à part entière, en appliquant le processus décrit ci-dessus.
Avec XQual, vous pouvez transformer automatiquement des notes de tests exploratoires en tests manuels scriptés grâce à la syntaxe PDNL de XQual.



XQual est utilisé tout au long de votre processus de développement.
Il permet de construire et de mesurer la qualité au fur et à mesure. Vous pouvez désormais livrer plus facilement sur votre pyramide de tests, et avec efficacité.