Bienvenue sur Développement Agile

Référence sur le développement logiciel Agile. Nous traitons de conception, de programmation, de pratiques de génie logiciel, d'essais et d'autres sujets connexes.

La puissance des scénarios d’acceptation

Publié par David Beaumier le lundi 22 décembre 2014 à 13:08

Source: specflow.org

Récemment, j’avais comme tâche de préparer les scénarios d’essais pour un récit (User Story) que l’équipe devait réaliser. Il faut savoir que l’équipe utilise des scénarios basés sur la syntaxe Gherkin (avec l'outil SpecFlow) pour définir le comportement attendu de l’application. Le récit en question étant très simple (il concernait l’accès une fonctionnalité selon les permissions de l’utilisateur), je vous avoue que je me suis demandé avant de débuter si ça valait la peine d’écrire ces quelques scénarios. Dans le fond, il y a seulement deux cas possibles : l’utilisateur a accès ou non. Simple n'est-ce pas?

Et pourtant, dès que j’ai entamé la rédaction du premier scénario, les questions fonctionnelles se sont mises à surgir… Par exemple, comment réagir si l’utilisateur n’a pas de droit d’accès à la fonctionnalité : désactiver l’écran, le vider ou bien rediriger l’utilisateur vers la page principale du module? Devrait-on arrimer la structure des permissions de ce module avec le nouveau modèle maintenant utilisé dans l’application? Cela a rapidement suscité un échange avec les collègues sur ce qui est facilement faisable, sur les standards dans l’application pour ce type de cas et sur l’expérience utilisateur. Tout ça pour en venir à la meilleure option en fonction des critères d’acceptation du récit.

Évidemment, les discussions n’ont durées que quelques minutes. Comme on le dit en anglais, ce n’était pas du « rocket science »! Par contre, l’écriture de ces scénarios a permis de clarifier en amont plusieurs aspects qu’il aurait fallu éclaircir de toute façon. Nous avons pu le faire en amont, en prenant le temps nécessaire et en impliquant toutes les personnes concernées. L'introduction des scénarios d'acceptation dans le cycle de développement permet d'avoir ce genre de discussions (en général plus poussées, mais vous voyez le genre) et évite les attentes implicites inconnues de l'équipier qui implémente la fonctionnalité.

Et vous, utilisez-vous les scénarios d'acceptation dans votre équipe? Quels sont les principaux bénéfices que vous en retirez? Je vous invite à partager votre expérience avec nos lecteurs en utilisant la section commentaire ci-dessous.

D'autres billets qui pourraient vous intéresser

Pour aller plus loin

Si vous songez à introduire les scénarios d'acceptation dans votre équipe je vous suggère fortement la formation Tests d’acceptation: introduction à ATDD et au BDD. En plus d'introduire les concepts associés aux essais d'acceptation, cette formation vous permettra de prendre conscience des impacts que cette pratique pourrait avoir au sein de votre équipe et de votre organisation.

TDD: Comment partir du bon pied?

Publié par Félix-Antoine Bourbonnais le jeudi 27 juin 2013 à 00:00

Suite à ma présentation sur le TDD Mockiste de la semaine dernière, plusieurs personnes m’ont demandé des références afin de bien débuter en TDD. D’autres m’ont demandé des liens sur le BDD.

Voici donc une série de billets sur le sujet: (1) comment débuter? (2) comment partir votre équipe en TDD? (3) des liens et des pistes pour les plus experts.

Comment débuter

Si votre premier objectif est de voir quelques professionnels à l’oeuvre pour vous donner une meilleure idée de ce que peut être le TDD, je vous recommande les vidéos de cleancoders.com.

Peut-être aurez-vous alors été impressionné par la vitesse et l’aisance avec laquelle il est possible de faire du TDD et vous ou votre équipe désirez faire de même.

La mauvaise nouvelle est que le TDD est une discipline et que les pros du TDD pratiquent depuis des années pour atteindre ce niveau d’aisance. Vous devrez donc, malheureusement, vous aussi pratiquer, pratiquer, vous tromper, perdre du temps, vous décourager, vouloir laisser tomber, changer d’idée, vous ressaisir, puis pratiquer encore, …

Il n’existe pas de chemin linéaire pour devenir un praticien du TDD, il n’y a que la pratique...

Premières lectures en TDD

Pour commencer, vous voudrez probablement avoir une référence vous permettant d’acquérir les bases.

Je vous recommande l’une des options suivantes:

  1. Les vidéos traitant de TDD de Robert C. Martin sur cleancoders.com ;

  2. Le livre Growing Object-Oriented Software Guided by Tests (GOOS) ;

  3. Le livre Test Driven: TDD and Acceptance TDD for Java Developers ;

  4. Le livre Test Driven Development: By Example ;

  5. Une formation TDD .

Pour les plus pressés, les vidéos sur cleancoders.com (1) sont idéaux, car ils présentent des exemples pas à pas, sont concis et permettent d’avoir rapidement l’information provenant de l’un des plus grands maîtres. Le tout, condensé dans des vidéos amusants que vous pouvez regarder dans le confort de votre salon. D’ailleurs, la qualité des derniers épisodes est nettement meilleure et ils peuvent être regardés en HD.

Ceux ou celles qui s’intéressent à l’école de Londres ou qui veulent en même temps améliorer leur architecture ou leurs pratiques OO voudront certainement lire GOOS (2). Un débutant en TDD peut cependant très bien lire cet excellent livre au 1er degré sans s'attarder à la trame de fond de l’école Mockiste. C’est un livre qui a changé ma pratique du TDD et qui est un point tournant pour moi.

Le livre de Lasse Koskela (3) est assez nouveau et présente simplement le TDD. À mon avis, son principal avantage est de parler du TDD au sens large, incluant l’ATDD. Il contient beaucoup de trucs et astuces, des odeurs et des difficultés communes. Les points abordés correspondent aux questions récurrentes lors des mes formations. Il traite à la fois de la base et de sujets avancés.

Finalement, le livre de Kent Beck (4) est un classique et reste toujours pertinent. Très bien écrit, il présente le TDD d’origine.

Malgré toutes ces lectures, vous ressentirez peut-être le besoin de valider votre compréhension ou de vous faire conseiller. Peut-être voulez-vous laisser un expert vous guider? Dans ce cas, il y a toujours nos formations ou notre mentorat virtuel. Oui, je sais que je suis en conflit d’intérêts ici, mais reste que si je donne ces formations, c’est que je crois qu’elles sont bénéfiques pour les participants...

Premières expériences en TDD

Bien. Maintenant que vous avez une vague compréhension du TDD et que vous rêvez de pouvoir coder le jeu de Bowling aussi rapidement que Bob Martin, la question reste: comment y parvenir?

En pratiquant... Mais quoi?

Commencez par des exercices très simples qui vous permettent de vous concentrer sur le TDD et non le problème. Choisissez des problèmes triviaux comme une pile, inverser une chaîne de caractères, etc.

Augmentez graduellement le niveau de difficulté. Par exemple, l’exercice du Jeu de la vie est un bon exercice de deuxième niveau. C’est le type de Kata très versatile que l’on peut faire et refaire toute notre vie et encore apprendre...

Plusieurs Katas sont disponibles et sont spécialement conçus pour pratiquer le TDD. Vous pouvez consulter ce catalogue ou encore celui-ci. D’autres problèmes sont disponibles ici. Une foule de solutions à ces Katas sont disponibles sur Internet (ex.: ce site).

Pourquoi est-ce difficile?

Rien ne sera facile, car vous devrez désapprendre à programmer... En termes plus scientifiques, vous devrez reconstruire un nouveau réseau neuronal...

Cela vous demandera de faire appel à toute la plasticité de votre cerveau pendant un petit moment en attendant que ce nouveau circuit soit le plus fort...

Je n’ai alors qu’un seul conseil: ne lâchez pas!

Un retour au testing exploratoire

Publié par Louis-Philippe Carignan le jeudi 23 mai 2013 à 15:00

Dernièrement, j’ai revisité le testing exploratoire pour aider un collègue. Sur ce sujet, je me réfère souvent aux frères Bach (Jon et James) ainsi que Cem Kaner puisque je crois qu’ils sont les représentants les plus en vue de cette approche. Pour vous initier au testing exploratoire, je vous suggère cette vidéo de 4 minutes pour voir les différentes approches du testing exploratoire du gros bouton rouge « Bureau En Gros ».

 

 

Je considère le testing exploratoire comme un style de test important. Brian Marick, dans sa matrice des tests, leur réserve une place dans l'un des quadrants comme l’explique ce billet sur son blogue.

Testing Matrix

Pour revenir aux frères Bach, ils tiennent plusieurs vidéos à jour leur site satisfice.com. Il y a d’ailleurs quelques outils de tests dont mon préféré est le log watch. Cet utilitaire s'exécute en arrière-plan où il lit un fichier de log généré par le programme à tester. À chaque fois que cet utilitaire identifie une chaîne de caractères recherchée dans le fichier de log, l’utilitaire joue un .wav. On peut donc vaquer à nos occupations et être averti quand le message recherché survient.

J’avais assisté à une conférence de James Bach il y a plusieurs années où il avait démoli un programme par le testing exploratoire. Le programme était un kiosque à l’aéroport où l’on peut naviguer sur Internet en payant avec sa carte de crédit. Le seul programme accessible était le navigateur web. James a montré que l’option pour imprimer la page web courante était encore activée. Bien qu’il n’y avait pas d’imprimantes attachées au kiosque, cette option était toujours présente dans le menu.

Et puisque le système d’exploitation était Windows XP, on pouvait choisir l’imprimante par défaut qui est le XPS Document Writer.

XPSPrinter

Et que ce passe-t-il lorsqu’on appuie sur le bouton OK une fois cette imprimante sélectionnée? Et bien on accède au système de fichiers.

Win XPFile System 

Je vous laisse deviner la suite de sa présentation ;-) 

Lors de sa présentation, James avait mentionné comment un testeur se devait d’avoir un « boneyard » d’outils pour l’aider dans son travail. Pour simplifier vos recherches, je trouve que le site www.opensourcetesting.org contient une panoplie d’outils intéressant dont certains peuvent aider les testeurs à faire du testing exploratoire. Au cours de mon expérience professionnelle, les utilitaires de Mark Russinovich (ProcessExplorer, FileMon, Junction) m’ont été très profitable. Je vous encourage d’ailleurs fortement à lire son blogue une fois par mois ou d’acheter son livre « Windows Internals » si vous avez souvent à travailler "sous la couverte de Windows". Son blogue contient d'ailleurs des articles qui datent jusqu'à mars 2005

Tout ça pour rappeler que le testing exploratoire est un aspect important à considérer en développement logiciel. Malheureusement, je considère qu'il n’est pas assez souvent mentionné au détriment du TDD et du BDD. Bien que ces styles aient fait leur preuve pour identifier et éliminer un certain type de bogues dès leur apparition, le testing exploratoire vise un tout autre ensemble de bogues. Par expérience, je trouve qu’un bon testeur aura la mentalité pour mettre en pratique ce style de tests dans son travail, ce qui rendra la solution logiciel plus fiable aux yeux du client. 

Mots-Clés :

Que tester lorsqu'on débute avec BDD?

Publié par Pascal Roy le mardi 5 mars 2013 à 15:27

Tout récemment on me demandait conseil sur la façon de mettre en oeuvre des essais de type BDD ou Behavior-Driven Development dans une équipe de développement. En gros, la personne voulait savoir comment partir du bon pied et quels étaient les pièges à éviter. Voici un extrait de son message:

Pour le BDD, j'aimerais connaître votre opinion et votre vécu. Par exemple:

  • On passe par l'interface?
  • On passe au niveau des contrôleurs (ou couche juste en bas de l'interface si vous préférez)?
  • On passe par les services directement?

J'ai pensé partager ma réponse sous forme d'un billet puisque je trouve que la question est pertinente pour la majorité des équipes qui souhaitent débuter avec le BDD. Voici donc...

Il fut un temps ou le message était de ne pas passer par l'interface utilisateur parce que c'était excessivement coûteux et vraiment difficile à faire. Il y a beaucoup de choses qu'on ne connaissait pas à l'époque et les outils étaient somme toute pas mal misérables... Il y a eu beaucoup d'améliorations des outils mais il y a également eu beaucoup d'avancement au niveau de notre compréhension pour faire face à la complexité accrue de passer par l'interface utilisateur. Pour l'avoir fait dans quelques projets, je peux dire qu'il y a moyen de gérer cette complexité, et de ne pas rendre cela significativement plus complexe que de passer par un API de plus bas niveau.

Soyons clair: si on ne passe pas par l'interface usager, on ne peut être certain à 100% qu'un User Story est "Done Done". Peu importe que l'erreur soit banale parce que la couche UI est très mince et simple (ce qui par ailleurs est plutôt rare dans la vrai vie). Une erreur banale dans cette couche peut être quand même suffisante pour faire en sorte que le user story n'est tout simplement pas fonctionnel. Cela peut être aussi bête qu'un champ qui n'est pas lié au bon contrôle. Du point de vue du client, peu importe la profondeur de l'anomalie, le user story n'est pas fonctionnel et la valeur est nulle…

La décision de ne pas faire d'essais au niveau de la couche graphique est donc laissée à l'appréciation de l'équipe selon le retour sur l'investissement anticipé. De ma propre expérience, je crois qu'il y a moyen de faire ça pour que ce ne soit pas énormément plus coûteux que de passer sous la couche UI. Voici tout de même quelques trucs à garder en tête.

Utiliser le langage d'affaires

Premièrement, les tests doivent être écrits en langage d'affaires et non pas au niveau du l'interface utilisateur. Le langage doit en être un d'intention et ne pas tomber dans le détail d'implémentation. Le détail d'un user story peut changer, mais l'intention reste généralement la même, ce qui fait que la définition des tests eux-mêmes reste assez stable. Ce qui peut changer, ce sont les fixtures (ce qui lie le texte BDD et manipule l'application sous test). Celles-ci devront tenir compte des changements dans les détails de l'application (au niveau de l'interface entre autre).

Voici un cas typique fourni par mon collègue Louis-Philippe Carignan et qui illustre très bien ce que je veux dire.

Mauvais exemple
Étant donné que je suis sur la page de création d'un nouveau projet
Et que ma liste de projets existante est vide
Quand je tape le nom du projet dans le textbox "Nom"
Alors j'appuie sur le bouton "Créer"
Et j'ai une confirmation à la page suivante

Bon exemple
Étant donné que je veux créer un nouveau projet
Et que mon portefeuille de projets est vide
Quand je crée un projet avec le nom "Nouveau projet"
Alors je peux entrer les détails de ce projet

Utiliser un langage de programmation connu de votre équipe

Idéalement, le langage des fixtures devrait être le langage de programmation de l'application. C'est une erreur d'introduire "Yet Another Language" (par exemple Ruby). Oui, les gens peuvent apprendre l'autre langage, mais de façon réaliste, ils en ont déjà bien assez de se garder à jour avec les complexités du domaine, du langage de l'application, de l'OO, des design patterns, etc...  Ajoutons aussi, et c'est beaucoup plus important que ce que les gens croient habituellement, qu'utiliser le langage de l'application permet de se servir des mêmes outils de réingénierie (refactoring) pour maintenir les fixtures, ce qui est essentiel pour que ce code soit aussi facilement modifiable que le code de l'application.

Penser globalement, agir localement

La plus grosse erreur que les gens font, c'est de penser que tous les tests d'acceptation doivent absolument passer par l'interface utilisateur lorsque la décision est prise de procéder de cette façon. C'est tout simplement faux. Par exemple, pour tester un user story qui calculerait un montant selon plusieurs paramètres avec une règle d'affaires complexe, nul besoin de faire tous les cas de tests par le UI. On peut avoir un test qui valide l'interface, comme la mise à jour des champs après avoir lancé le calcul par exemple. Mais tous les cas de tests possibles spécifiés par le client qui concerne la règle d'affaires soujacente pourraient être testés directement au niveau de la classe qui implémente la règle elle-même. Ces tests, qui sont parfois aussi des tests unitaires, peuvent tout simplement être rendus disponibles dans la batterie de tests d'acceptation. Après tout, si le client a pris la peine de spécifier ces cas de tests, il va s'attendre à les voir dans les résultats des tests d'acceptation. Dans la mesure où on a un ou plusieurs tests qui assurent que l'interface permet l'exécution des cas d'utilisation, il est inutile de passer tous les cas de tests par elle si ils peuvent être testés autrement.

Il y a donc lieu, en créant chaque test, de se demander à quel niveau il devrait être implémenté. Il ne s'agit pas de couper les coins ronds, mais bien d'éliminer des charges indirectes inutiles.

Organisation des fixtures

Une des choses qu'une équipe réalisera avec le temps est que l'organisation des fixtures est très importante. Il faut que les développeurs sachent instinctivement où regarder quand il y a une nouvelle fonctionnalité à tester. Plus le projet est gros, plus cela a de l'importance. Une approche par écran (ou contexte d'interaction) est  plus facile qu'une approche par cas d'utilisation car elle permet de créer des fixtures qui sont des abstractions d'écran. C'est un peu la même philosophie qu'on retrouve au niveau du pattern MVP (Model View Presenter) ou le Presenter représente une abstraction de plus haut niveau de l'interface. 

Par exemple, si on a un user story qui modifie l'écran de login, on ne doit pas se poser la question sur l'endroit où se trouve la fixture à mettre à jour. En créant une LoginFixture, on évite que les développeurs répartissent du code de contrôle de l'interface un peu partout parce qu'ils ne savent pas que ça existe ailleurs (un problème qu'on a vécu lors de projets chez certains clients). J'ai déjà parlé de cette approche en plus de détail dans une présentation sur l'ATDD (disponible ici) que j'ai faite pour Agile Québec et Agile Montréal en compagnie de Nicolas Desjardins.

Isoler la complexité des fixtures

N'ayez pas peur d'ajouter une couche d'aide qui cache la complexité d'accéder à l'interface afin de faciliter la vie aux développeurs qui doivent modifier les fixtures. Un exemple serait de la création d'un utilitaire qui facilite l'écriture des fixtures pour contrôler des opérations qui sont asynchrones. On peut aussi isoler les choses qui changent souvent dans l'application pour limiter les endroits où il faudra les changer dans les fixtures.

Quand ç'est bien fait, ça rend le code de tests beaucoup plus stable au point où le changement n'est pas vraiment si pénible que ça. Enfin, pas plus que pour l'application elle-même...

Conclusion

En résumé, pour répondre à la question du départ:

  • Les services peuvent être entièrement testés sans passer par l'interface utilisateur.
  • Si un user story utilise un service, ne testez pas ce dernier par l'interface (il devrait déjà avoir été testé). Assurez-vous plutôt que la couche graphique est capable de le manipuler correctement (entrée/sortie) au niveau de l'interface. Cela limite beaucoup la quantité des tests qui doivent passer par l'interface.
  • Passer par l'interface utilisateur est vraiment la seule façon d'être certain que le user story fonctionne ("Done Done" plutôt que "Most likeky done"). Vous pouvez décider de ne pas le faire, mais faites le en connaissance de cause et ne sous-estimez pas ce que vous perdez à ne pas le faire.
  • L'important est que tous les cas de tests spécifiés par le client soient inclus la suite de tests d'acceptation, mais les tests peuvent être à différents niveaux, quitte à réutiliser certains tests unitaires pour valider certains cas comme les règles d'affaires par exemple.
  • Si un user story utilise plusieurs services, ne validez pas les services eux-mêmes, mais bien que l'interface les pilotent correctement. S'il y a une interaction entre les services, il vaut probablement mieux encapsuler cette interaction dans un service composé de plus haut niveau et tester celui-ci directement.

Comme toujours, il faut être pragmatique. Il n'y a pas qu'une seule "bonne" approche. Ça dépend encore beaucoup du contexte, des technologies utilisées et des compétences de l'équipe. Il y a peut-être encore des environnements qui rendent les tests par l'interface utilisateur excessivement dispendieux. Plusieurs IDE, qui ont un objectif fort louable de rendre le développement d'interface utilisateur plus facile et rapide pour tous, imposent toutefois une architecture qui rend les tests beaucoup plus difficiles à implémenter et maintenir dans une approche BDD.

Les essais et le développement Agile

Publié par David Beaumier le vendredi 18 novembre 2011 à 07:38

Il ne faut en général que quelques itérations aux équipes qui font du développement itératif et incrémental pour réaliser à quel point avoir une stratégie d'essais est importante. Le livre Agile Testing: A Practical Guide for Testers and Agile Teams de Janet Gregory et Lisa Crispin est une vraie mine d'informations pour en savoir plus sur les bonnes pratiques en matières d'essais. Le livre fait vraiment le tour d'une foule d'aspects, tel que: les différents niveaux et types d'essais, les rôles en assurance qualité, le rythme des itérations et l'arrimage avec l'équipe et l'organisation. Le chapitre Cultural Challenges est disponible en téléchargement depuis le site de l'éditeur.

Livre Agile Testing

Une grande partie du livre se consacre aux essais du point de vue de l'équipe TI et aborde les aspect technologiques associés. Par contre, un chapitre complet est dédié aux essais orientés "affaires" et présente des approches pour valider que le produit développé réponde bien aux besoins d'affaires auxquels il doit répondre.

Aucun livre traitant d'essais dans un contexte de développement Agile ne serait complet sans une section sur l'automatisation. Cette section est très bien faite et présente des approches pragmatiques aux problèmes communément rencontrés par les équipes. Les auteurs font le tour de la question et font bien ressortir le fait que l'automatisation c'est bien plus qu'une question d'outillage.

Outils

Si la lecture du livre vous donne envie d'explorer différents outils d'automatisation des essais, le site http://www.softwareQAtest.com propose un répertoire d'outils. Évidemment, aucun de ces outils n'est parfait et une évaluation des besoins de l'équipe est primordial. Il est en général préférable d'utiliser une approche empirique dans la mise en place d'un tel outil en débutant avec un outil simple et en réévaluant vos besoins après une certaine période de rodage.

Voici quand même quelques conseils pour orienter vos choix:

  • Impliquez toute l'équipe de développement dans les essais. La qualité est l'affaire de tous, et l'apport des développeurs est essentiel.
  • Si possible, débutez par des tests au niveau de l'API. Ils sont souvent plus simples à mettre en place que des tests sur la couche graphique et requièrent moins de maintenance à long terme. Votre plateforme de développement offre peut-être même déjà les outils nécessaires.
  • Les essais intégrés sont probablement ceux qui peuvent offrir le meilleur retour sur l'investissement à long terme. Ils permettent généralement de bonnes discussions sur les exigences à rencontrer et favorisent une collaboration entre les développeurs, les gens de contrôle qualité et les utilisateurs.
  • Débutez simplement et ayez des attentes réalistes au départ. Donnez-vous du temps pour expérimenter et apprendre.
  • Mesurez votre progression (nombre de cas, taux de succès, fréquence d'exécution, couverture fonctionnelle, etc).
  • Plus récents
  • 1
  • Plus anciens

Archive