Tester pour contruire le bon logiciel: la relève…

Il y a quelques temps déjà que nous croyons aux méthodologies de développement pilotées par les tests. J’en entends déjà pester « encore un truc de geek »…Le pilotage par les tests se résume à ces deux points clés:

  • remplacer le cahier des charges, spécifications manuscrites riches, complexes et par expérience jamais complètes voire fausses du fait de l’ambiguïté du langage courant par des spécifications exécutables c’est à dire vérifiables concrètement et fournissant une réponse sans appel: « vert » ou « rouge ».

  • Piloter non pas sur un « reste à faire » – concept obscur car que met on dans le « reste à faire »? – mais sur du réalisé (ie. nombre de tests passants sur le nombre total de tests prévus) représentant de facto le pourcentage du logiciel réalisé et opérationnel.

Partant de ce principe, il est nécessaire d’avoir un outil permettant aux « fonctionnels » d’écrire simplement – c’est à dire dans leur vocabulaire – les spécifications exécutables et permettant aux « managers » de piloter les développements.


Le seul outil existant jusqu’à ce jour était Fitnesse (http://fitnesse.org/) et se présente sous la forme un wiki (autrement nommé « repository de test ») utilisant un noyau nommé FIT (http://fit.c2.com/) pour exécuter les tests ou « spécifications exécutables » et ainsi réaliser les assertions.

Nos retours d’expérience nous ont montré des limites – non pas de l’approche – mais de l’outil. Alors, nous nous sommes remis en quête de mieux et nous avons découverts des initiatives comme Greenpepper (http://www.greenpeppersoftware.com), initiative qui répond à presque toutes nos douleurs:

  • Problématique d’Edition. Le wiki et la syntaxe proposée apparaît comme un élément essentiel à une émancipation de l’écriture des spécifications exécutables chez les « fonctionnels ». Non seulement parce que le manque d’éditeur WYSIWYG est un frein notable dans la prise en main d’un wiki par des gens peu ou pas habitués à manipuler des langages informatiques mais aussi car la manipulation de tableaux – structure exécutable – complexes devient très vite problématique, même pour des caïds en perl…Alors Greenpepper s’appuie à ce jour sur un Jira mais surtout sur un wiki Confluence dont l’éditeur de page est extrêmement puissant et propose des fonctionnalités comme le copier/coller depuis excel…

  • Problématique de Build et outillage. Une limitation importante est liée au développement des Fixtures – ce code qui réalise la liaison entre le test exprimé dans le wiki et le code a tester – . Comment simplement exécuter la Fixture en cours de développement? la solution actuelle est simple mais peu acceptable: construire le jar correspondant et le positionner dans le classpath de Fitnesse. C’est simple mais dans des infrastructures complètes – faisant intervenir automate de build, repository maven…, la perte de productivité se fait très rapidement sentir. Alors Greenpepper propose un plugin eclipse qui fluidifie énormément le travail de développements des fixtures et le travail collaboratif autour des tests.

  • L’intégration aux usines de développement et notamment avec maven nous semble également apporter un grande valeur ajoutée et à jusqu’à présent donner lieu à quelques développement de plugins pour maven1 ou maven2 (http://mojo.codehaus.org/fitnesse-maven-plugin/index.html). Là encore, Greenpepper propose son plugin pour Maven2 et permet d’intégrer l’exécution des spécifications au build.

  • Concernant l’intégration à l’infrastructure, Greenpepper s’appuie sur des briques standards, connues et reconnues par « l’exploitation »: un war et un tomcat. Cela peut paraître anodin mais peut grandement simplifier le déploiement et l’administration de l’outil au niveau de l’entreprise.

Malgré tout, une autre limite liée au versionning du logiciel subsiste. Le logiciel n’est plus seulement le code: c’est le code, les tests unitaires et les spécifications exécutables. Ainsi, une release du logiciel doit inclure une version (et par extension une release) des spécifications exécutables. Actuellement, cette limitation reste sans réponse et il est nécessaire de gérer « a la mano » les versions des spécifications exécutables ce qui pour des applications conséquentes (plusieurs centaines de tests) peut devenir acrobatique.

Enfin, GreenPepper ne propose encore rien concernant l’aspect reporting, à la fois sur les aspects historiques d’exécution ou pilotage. On peut trouver cela un peu dommage, sauf que tout est déjà présent en base de données.

Alors, nous avons réalisé quelques essais de rapports comme l’historique d’exécution des tests ou bien encore la vélocité.

Ces rapports ont été simplement créés sur la base de plugins Confluence et l’exécution de script Groovy (http://groovy.codehaus.org/) et il y a fort à parier que ce genre de features fera partie des prochaines releases.

GreenPepper semble donc être un nouvel élément du marché proposant pour un coût plus que raisonnable (~$3000 pour 25 utilisateurs) des réponses industrielles aux problématiques de pilotage par les « spécifications exécutables ».

Affaire à suivre…

7 commentaires sur “Tester pour contruire le bon logiciel: la relève…”

  • Bonjour,

    Est ce que Fitnesse possède un bon niveau de reporting ? ou est ce du même niveau que greenpepper ?

    Si le niveau de reporting est un critère important, est ce que cela vous parait justifier de préférer fitnesse à greenpepper ?

    Fitnesse etant open source, contrairement à greenpepper, je me dis que l'on peut developper sur mesure le reporting qui correspond à nos besoin

  • En fait Fitnesse/Greenpper ne fournissent rien concernant le reporting.
    Ce qui a été présenté ci dessus est un dev spécifique pour Greenpepper. L'avantage de greenpepper (il faut que je vérifie si c'est toujours vrai) est qu'il stocke l'historique des exécutions en base. il est donc possible de reconstruire les courbes par ce biais.

    pour le développement de reporting spécifique avec Fitnesse je ne sais pas...sur le principe oui mais il faut prévoir un mécanisme d'historisation car pour moi Fitnesse ne fournit rien

  • a noter ce projet maven mojo.codehaus.org/fitness...

  • Merci pour tes réponses

    Encore une question : comment se positionne silkTest vis a vis de fitnesse/greenpepper ? Est ce que silkTest possède un équivalent au fixture ?

  • personnellement je n'ai jamais expérimenté SilkTest. Le peu que j'en connais me fait dire qu'il se positionne plutôt comme un recorder d'IHM: tu enregistre l'utilisation de tes IHMs et tu rejoues cet enregistrement (ces scripts en fait) sur ton applicaition lors de la recette suivante.

    La limitation de ce type d'outil est que si ton IHM change - ce qui est souvent le cas entre deux recettes... - ton script n'est - a priori - plus valide. formulé autrement, tu ne capitalises absolument pas sur ton harnais de test .

    A l'inverse, des outils comme GreenPepper/Fitnesse se positionne comme un outil de spécification exécutable. Je vois deux différences par rapport à SilkTest
    - ton test est ta spécification. en bref tu capitalises dessus (c'est la connaissance de ton soft), tu fais évoluer tes tests/specs, cela te sert pour ta recette...
    - l'outil n'est pas forcément une fin en soi mais a pour bout de rapprocher MOA/MOE: des dialogues entre les deux équipes devront se mettre en place

  • GreenPepper inclus maintenant des rapports d'exécution ! Voir la nouvelle version !
  • exact. Un screenshot ici http://www.greenpeppersoftware.com/confluence/display/GP/Historic+Macro Merci pour l'info.
    1. Laisser un commentaire

      Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha