Ainsi pour l’installation d’un environnement de test la solution consiste souvent à récupérer des données de production. Je ne peux que donner raison à cette pratique qui permet de construire des jeux d’essais à partir de cas réel, de disposer d’un volume conséquent d’informations en un minimum de temps, et de permettre au métier de retrouver ses cas à problèmes.

Pourquoi donc changer cette façon d’opérer qui semble satisfaire tout le monde ?

Deux raisons viennent militer pour une modification :

1. les équipes de développement sont de plus en plus éclatées. Ainsi une partie de l’équipe se situe-t-elle peut-être à l’extérieur, voire à l’étranger, voire chez un sous-traitant d’un sous-traitant. Et ils ont tous besoin des moyens de tester ce qu’ils produisent. La maitrise des individus accédant aux données est donc de plus en plus difficile. D’où la question de mon titre : a-t-on besoin de laisser les clés de la maison à l’artisan venant repeindre la façade ?

2. Les exigences des instances nationales et internationales en termes de protection de la sphère privée ont évoluées, et il n’est plus possible de laisser se balader dans la nature des informations nominatives et/ou sensibles. Il est vrai que jusqu’à présent les cas de divulgation, d’utilisation frauduleuse ou d’espionnage n’étaient pas légion, mais chacun de ces risques est présent. Et probablement beaucoup d’autres.

Il faut donc revoir notre façon de construire des environnements de test. Pour cela je propose une approche simple basé sur deux postulats :

• les meilleures données de test sont les données réelles (ou de production) et il faut chercher à s’en éloigner le moins possible

• le respect de la réglementation est une obligation, celui des standards et des normes est bienvenu

N’étant pas adepte du bazooka pour chasser la souris, il me semble approprié de commencer par identifier les risques, c’est à dire le dommage que pourrait causer la divulgation ou l’exploitation d’une donnée, ainsi que la probabilité que ce dommage survienne (lié notamment à la difficulté et au matériel nécessaire pour réaliser un recoupement d’information).
Ensuite une stratégie d’anonymisation peut être élaborée afin de couvrir ces risques que l’on aura préalablement hiérarchisés.

La mise en place d’un quelconque outil n’intervient qu’en suite, et tout investissement dans ce domaine doit être lié aux dommages possibles, et non pas à un quelconque challende technique.

Pour éviter d’être trop long je propose de présenter prochainement nos vues sur le sujet, avec une démonstration sur un cas d’école, dans le cadre d’un Mardi Gras au mois de septembre.

Hortis a assis son partenariat avec eXo, société bien connue pour sa plateforme couvrant à la fois les besoins de :

• Portail
• Gestion de contenu
• Gestion documentaire

en clôturant un nouveau projet utilisant cette technologie.

Le projet consistait à industrialiser l’ensemble des réalisations autour de la plateforme dans l’atelier de développement d’un de ses clients, c’est à dire en adaptant les repository Maven, en développement des artefacts ou des projets d’exemples.

Après avoir formé ses ressources sur la solution eXo, Hortis montre une nouvelle fois son implication dans des projets innovants et sa volonté de faire vivre ses partenariats.

Souhaitons qu’il y en ait encore beaucoup d’autres …

Conscient qu’ils nécessitent des commentaires et explications, je suis prêt à la rééditée si suffisamment de personnes sont intéressés. Peut-être cette fois en conférence Web et/ou en milieu de journée.

les rapports entre Test et Agilité

Le jeudi 30 avril à 18h

au Geneva Business Center, avenue de Morgines 12, Petit-Lancy 1213

c’est à dire :

• les meilleurs pratiques de test
• leur intégration dans une démarche projet Agile
• la mise en place d’une démarche Agile dans les projets de test

Pour vous inscrire rien de plus simple : ajoutez un commentaire avec +1

Pour les « premiers de la classe » qui veulent réviser la mardi gras sonar, je vous renvoie à ce post de Freddy concernant les rapports Maven sur agile-swiss.org.

Datant d’une époque où Freddy n’avait pas encore de poils au menton (encore moins que maintenant ;o), il s’agit de Maven 1.

Bien que Sonar repose sur Maven 2, les différences liées aux rapports ne sont pas fondamentales.

Donc bonne lecture,

jacques

• Vous développez des applications JEE (et un jour … RoR. Je sais, je me répète mais les rubistes sont des personnes très susceptibles qu’il faut savoir ménager)
• Vous faites de l’intégration continue en vous appuyant sur Maven2 (Si vous ne faites pas d’intégration continue, allez directement en prison et ne passez pas par la case départ)
• Vous êtes soucieux de la qualité des développements
• Vous avez un bon petit paquet de projets Maven2
• Vous travaillez en équipe
• De manière optionnelle vous utilisez une approche agile et ça dépote grave (Y’a des options qui devrait tout de même être livrées en série. Imaginez un instant votre concessionnaire BMW, tentez de vous vendre une série 6 avec en option l’ABS, les lèves vitres électriques et le verrouillage centralisé)

Si ces postulats sont vrais dans votre contexte vous devez certainement vous dire qu’il vous manque un truc … un truc capable … de centraliser toutes ces informations qualitatives, d’identifier les applications en risque, de comparer l’évolution des indicateurs qualitatifs entre deux versions d’un même produit, d’historiser l’évolution de ces indicateurs, … et tout ça en Open Source (les rêves font vivre, j’en suis convaincu).
Si ce truc vous taquine, Hortis ne devrait pas tarder à exhausser vos rêves.

A suivre …

GreenPepper est un produit de gestion des exigences à destination des équipes agiles. Je vous invite a aller faire un tour sur le site web pour en savoir un peu plus.

La présentation aura lieu dans les locaux d’Hortis lundi 2 avril de 18h30 à 19h30.

Merci d’ajouter un petit commentaire si vous souhaitez participer.

Avec la nouvelle année, que je vous souhaite la meilleure possible, arrive son lot de bonnes résolutions…

Comme vous le savez peut-être, un des principes sur lesquels repose Hortis est la Communauté de Pratiques. Il s’agit d’un regroupement de personnes sur un pôle de compétences donné, qui ont en charge de faire progresser la société (tant Hortis que ses collaborateurs, nous !) dans ce domaine (capitaliser, diffuser, étoffer l’offre commerciale…)…

Pour plus de détails sur les CP, je vous renvoie au post de Freddy sur le fonctionnement de la Communauté de Pratique Agile…

Concrètement, nous avions jusqu’ici une seule CP, relative à l’Agilité dans son ensemble. Mais Hortis grandissant, et ses compétences s’élargissant, cette CP a été scindée en trois : la CP Agile (encore et toujours), la CP ALM (pour outiller les agilistes) et la CP RoR (il faut bien que l’on trouve quelque chose à faire pour Simon ;o).

Pour préciser la CP ALM, il s’agit de réfléchir sur (et d’élaborer) une offre logiciel de Gestion du Cycle de vie des Applications (ou Application Lifecycle Management en polonais).

Dans le principe, ces communautés de pratiques sont ouvertes à tout Horticien qui souhaite s’impliquer dans le domaine en question.

J’en viens donc au sujet de ce post.

Si vous souhaitez participer activement à l’une des 3 CP citées ci-dessus, je vous invite vivement à contacter un de ses membres :

• Freddy pour la CP-Agile,
  
• Joel pour la CP-ALM et
  
• Simon pour la CP-RoR.

Voire, si vous vous sentez la force de faire émerger votre propre CP, contactez Christophe.

C’est pas de bol : on nous donne l’occasion de participer à l’évolution d’Hortis… Donc à notre futur ;o)

A très bientôt.

Jacques

Les tests unitaires ont été à l’honneur ces dernières années. Pour preuve JUnit est intégré directement dans maven et dans les IDE (pas encore dans le JDK, mais qu’attend Sun ?). Encore mieux l’interpréteur ruby embarque le gem test/unit. Le Test Driven Development d’XP place même les tests unitaires comme pièce centrale du cycle de développement.

Cet engouement n’a pas été aussi significatif pour les tests fonctionnels, autre principe de base de l’eXtreme Programming (“acceptance tests”). Et pourtant ce n’est pas le besoin qui manque. Ils permettent entre autres de valider le bon développement d’une fonctionnalité et la non régression d’une nouvelle release. Ils peuvent aussi pour certains servir de calcul de la vélocité d’un projet. Ron Jeffries les considèrent même comme l’ultime métrique d’un projet agile (Running Tested Features).

Dans le domaine des applications web Java, des outils comme HttpUnit ou Cactus sont assez limités et lourds à utiliser. Mais une nouvelle génération d’outils a fait son apparition. Plus simples et plus fonctionnels, FIT, FITnesse, Watir, Sahi et Selenium sont les outils de tests fonctionnels à suivre de près dans un avenir proche. C’est ce dernier qui m’a bluffé récemment. Entièrement écrit en Javascript et HTML, il s’exécute directement dans les navigateurs. Il permet de tester simplement n’importe quelle application web (HTML/XML sur HTTP mais pas Flash).

Pour ceux qui désirent en savoir un peu plus, selenium fera l’objet d’un mardi gras le 16 janvier. Merci de me tenir informé de votre venue par mail à simon.brandhof AT hortis.ch (le message “+1″ me suffit).