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