Mon application va mal. Que puis-je faire ?
La mise en place d’outils de test sur les navigateurs, combinés à une méthode de développement dirigée par les comportements, accélère la gestion des anomalies, et permet de les anticiper en amont de la phase de mise en production. Voici un comparatif des différentes solutions du marché.
La frustration de l’utilisateur de devoir annuler une action, ou
reporter une saisie parce que l’application ne répond plus à ses
besoins, engendre des exclamations et des interrogations.
Bon nombre de chefs de projets sont ainsi amenés à répondre aux propos
suivant « Le site ne marche plus ! », « Pourquoi ça ne marche plus ? ».
Pourtant tout démarrait correctement, des fonctionnalités séduisantes,
fiables et réactives. Mais voilà, d’autres ont dû naitre et participer à
la croissance de notre application, et ceci avec son lot de
complications et de régressions.
Lors de l’Agile France 2012 qui a eu lieu le 24 et 25 mai dernier, ces problématiques ont été le sujet de conférences.
Il y a été présenté des pratiques, qui couplées aux bons outils,
permettent de se prémunir des désagréments que nous avons évoqués plus
tôt. Chacune d’entre elle intervenant à différents niveaux dans la phase
de construction du projet.
En nous focalisant sur le comportement global des fonctionnalités de
notre application, nous trouvons une pratique et une famille d’outils
dont l’objectif est de tester le comportement de ces dernières :
- Le BDD (Behavior Driven Development), permet de définir le
comportement d’une fonctionnalité et de l’intégrer au développement, en
tant que contrat, à l’image d’une spécification.
- Les outils de navigation automatique qui vont permettre d’enregistrer
des scénarios de test depuis une application web et de les rejouer
automatiquement sur cette même application.
Le BDD
Le
BDD se base sur un langage simple, GHERKIN. Les termes Given / When / Then / And en
sont les composantes majeures. A l’image d’un besoin, son émetteur (MOA /
Métier / Product Owner) transcrit sa demande littéralement.
Exemple d’une
application gérant des contacts (CRM):
Given I am on my contact page
When I select a country
And I select a zip code
Then list of streets are displayed
En bref, ces quelques lignes nous montrent que lorsque nous sommes sur la page d’un contact de notre site, si nous sélectionnons un pays ainsi qu’un code postal, alors une fonction de recherche de rues répondant à ces deux critères est activée.
Le comportement de nos fonctionnalités métiers peut être écrit de la sorte. Finalement, c’est l’expérience utilisateur souhaitée qui est définie.
Derrière ce langage et cette pratique, il existe des outils permettant d’interpréter l’histoire décrite.
Nous
noterons, pour les plus connus :
Cucumber (Java, Ruby, C#, …)
JBehave (Java)
RSpec (Ruby)
Testez avant de développer
Le rôle
de l’équipe de développement sera de mettre en place les fonctionnalités permettant
de répondre à ces scénarios.
Ces derniers
seront rejoués lors de l’ajout d’une nouvelle fonctionnalité afin de s’assurer
de la continuité de service de notre site. Ainsi le retour du test, valide ou
pas, nous indiquera les potentielles anomalies introduites.
Simplifiez votre process de
développement
La
mise en place du BDD implique que le process de construction du besoin
soit simplifié. C’est à dire que le scénario
décrit le fonctionnement mais qualifie également les développements effectués. La
phase de qualification est ainsi intégrée à celle de spécification. Le travail
de l’émetteur du besoin devient plus impactant pour les équipes de
développement.
Nota :
Chacun des outils précédemment mentionnés, autorise l’écriture de scénarios
dans une langue autre que l’anglais et ainsi permettre une meilleure
compréhension du besoin exprimé.
Les
outils de navigation automatique
Pour
rappel, le test fonctionnel est la validation du comportement d’une application.
Dans le cadre d’une application web, s’appuyant sur un cahier de recette, les
membres d’une équipe de validation sont amenés à naviguer sur l’application à
la recherche d’anomalies, et ceci, de manière systématique entre deux versions
de l’applicatif. Pour ne pas répéter inlassablement ce travail, il existe
différents outils permettant de soulager les validateurs.
Nous
noterons, Selenium, Watir (prononcer Water), déjàClick, iMacros parmi les
plus connus. Ceux-ci sont basés sur la validation des interfaces d’un site web
avec l’enregistrement de scénarios de tests fourni par ces outils ainsi que
leur exécution. Une émulation des actions menées et enregistrées par l’utilisateur
est alors rejouée sur notre application.
Assurez la qualité de votre projet
Ces
outils offrent la possibilité de lancer fréquemment, des scénarios et ainsi de
s’assurer du bon fonctionnement de l’application tout au long du cycle de
développement d’une fonctionnalité.
Comparatif des différentes solutions du
marché
Ci-dessous
un tableau comparatif entre les solutions précédemment citées.
Conclusion
La
mise en place de pratiques tel le BDD ou / et d’outils de tests sur navigateurs
permet d’assurer une continuité dans le fonctionnement d’un existant lorsque
l’application est amenée à s’enrichir fonctionnellement. Une anomalie ne sera
plus identifiée par un utilisateur final, mais bien plus tôt, en phase de
développement laissant ainsi les équipes se focaliser sur les nouveautés à
apporter.
Nous
constatons également que les pratiques tendent à faire travailler les équipes de
validation/métier et celles de développement plus étroitement afin de partager
la même vision de la qualité d’un projet (BDD).
Le
travail avec des outils comme Selenium permettent de rapidement border la
qualité des fonctionnalités déjà en place. Par l’exécution fréquente des scénarios de
tests, nous sommes capables d’identifier les régressions au plus tôt dans la
chaine de développement. L’expérience utilisateur final s’en trouvera ainsi
améliorée.
Crédit de l'image : HaywireMedia - Fotolia.com