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.

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

Premier webinar de cette série: Présentation de jDiffChaser, une aide à la non-régression des rendus d’interfaces.

Durant cette présentation d’une heure environ, j’aborderai la problématique de régression de rendus d’interfaces que nous avions au sein de notre équipe de développement (interface de contrôle aérien). Nous parlerons ensuite de l’approche qui a été choisie pour avoir une aide automatisée puis détaillerons les possibilités de jDiffChaser, produit développé en interne et devenu Open Source.

Je vous invite donc à vous connecter le vendredi 17 avril à partir de 14h (heure locale Genève), à l’adresse suivante: http://conferences.hortis.ch/dimdim/

La room s’appellera jdiffchaser et le nombre de places sera limitée à 20 personnes.

Il vous faudra saisir une clé qui vous sera fournie le jour même par mail. C’est pourquoi je vous invite à vous inscrire ici.

• l’Agile Testing regrouperait l’ensemble des pratiques de test appliquées à une démarche de projet Agile, c’est à dire l’implémentation et l’automatisation de tests unitaires, l’intégration continue, le Test Driven Development, etc …

• Le Testing Agile serait la mise en oeuvre d’une démarche Agile dans les processus de test, de quelque nature ou de quelque niveau qu’ils soient.  Et pourquoi pas dans une démarche projet globale en cascade.

On voit bien alors qu’il ne s’agit plus de la même chose.
J’ai suivi le cursus de Scrum Master, toutefois la place du test au sein de la démarche n’a été que survolée. J’ai donc pris la liberté de réfléchir sur le sujet, à défaut de trouver beaucoup de littérature.
Ainsi si beaucoup de choses ont été dites et écrites sur le premier point, il en reste encore beaucoup à dire sur le second.

Je vais donc programmer un  Mardi Gras sur mai ou juin (mars : Intégration continue, avril : présentation ITIL), afin de présenter mes idées sur le sujet et obtenir vos remarques et retours d’expériences.

Avis aux amateurs !

Il est un point que je désirais aborder depuis longtemps sur ce blog: la place que l’on veut bien donner à l’ergonomie au sein des projets informatiques actuels et surtout le bien fondé de l’intégration de la notion d’ergonomie dans des équipes de développements agiles. Par ergonomie, je veux parler de l’expérience que l’utilisateur aura lors de ses interactions avec le logiciel. Il s’agit là d’un facteur de qualité trop souvent sous-estimé et qui, pourtant, influencera grandement le ressenti de l’utilisateur.

Combien de fois des projets se sont vu commencer à développer la première version utilisable du logiciel sans avoir simulé son utilisation avec des utilisateurs. Pourtant, beaucoup gagneraient à “faire un brouillon” de ces interactions en amont avec des utilisateurs, peu importe la méthode de réalisation: maquettes logicielles ou bricolages faits de papier, de trombones, de coups de crayons et d’attaches parisiennes. C’est d’ailleurs cette dernière méthode qui, de mon point de vue, a le meilleur ratio coût/efficacité et se trouve pourtant la plus évitée parce que “pas assez hype” ou, je cite, “ridicule”.

Durant mon expérience, j’ai pu constater que l’ergonomie, quant elle avait été citée, avait souvent été vue comme un “mieux” à la priorité très faible… puis les mois passant, certains projets, s’ils arrivaient à atteindre leurs objectifs fonctionnels, se trouvaient affublés d’une mauvaise réputation auprès des utilisateurs. Ceux-ci trouvant l’usage du logiciel trop difficile, tortueux, illogique: bref, ce qu’on appelle une mauvaise expérience.

Après avoir lu, entre autres, des publications de Bill Buxton, Dan Saffer, Bill Moogridge ou Jon Maeda ces dernières années, après avoir soulevé la question à l’Agile Open France 08 et en discutant de tout ceci avec des chercheurs de l’Université de Genève spécialistes en ergonomie, je prêche désormais pour l’intérêt d’intégrer dans des équipes de développement agiles la notion d’ergonomie, tant les deux mondes accordent l’importance qu’il se doit à l’avis de l’utilisateur. Sous la forme de l’intégration d’un profil d’ergonome ou d’une équipe sensibilisée à l’ergonomie, selon le contexte. Une chose est sûre: si l’on y gagne à itérer de manière incrémentale sur les fonctionnalités avec un utilisateur disponible, on y gagne tout autant à itérer sur l’ergonomie avec lui durant ces phases.

Devant la complexité des applications d’aujourd’hui, le besoin de donner à l’utilisateur l’occasion d’aller à l’essentiel est encore plus nécessaire et je me rassure en voyant ces réflexions de plus en plus présentes sur les blogs s’intéressant à l’agilité ou/et au designing d’intéractions…

Ajout de dernière minute: chose amusante, une illustration toute récente de ceci, certes concernant le grand public mais tout aussi valable pour l’informatique d’entreprise, m’a été indiquée, alors que je rédigeais ce texte, par un collègue me parlant d’ un post sur l’application Things, une application iPhone au succès dépassant les espérances de ses créateurs, l’ergonomie y étant pour quelque chose. Sur le post cité, les images de sketchs réalisés au crayon correspondent à ce qui a été cité plus haut. Alors, à vos crayons!…

En effet nous utilisons un produit annexe comme date picker depuis quelques années et il semblerait que son rendu diffère entre les deux versions. Certes l’allure diffère, mais la locale semble prise en compte de manière différente. Alors, mauvais usage de notre part ou comportement différent du composant sous java 1.6? Peu importe, le principal était de détecter le plus rapidement possible ce soucis avant la prochaine mise en production D’autant plus que nous ne l’avions pas remarqué auparavant en “jouant” avec l’application (avant de choisir de lancer nos tests jDiffChaser sous 2 jdks différents)… Comme quoi…

Cela fait maintenant deux petites semaines que la dernière version est lancée sur sourceforge, la 0.8 donc, que l’on utilise régulièrement depuis un mois. Au programme de cet opus:

• La gestion des redémarrages des applications remote a été revue,
• La compatibilité MacOS (demandée par certains utilisateurs)
• Les screenshots full-screen
• Délais possibles avant les screenshots (pour pouvoir enregistrer, par exemple, des éléments visuels présents uniquement si le pointeur est à un certain endroit)
• La transparence de la télécommande d’enregistrement (pour voir l’interface lorsque l’on enregistre une application full screen)
• L’enregistrement des mouvements des dialog boxes
• Une amélioration dans la navigation du rapport résultant de l’exécution des comparaisons

Pour rappel, jDiffChaser permet d’automatiser la comparaison visuelle de deux versions d’une application Swing (généralement la dernière en production et celle en développement) selon une liste de scénarios temps réel enregistrés par les testeurs. On détecte ainsi les effets de bords d’un composant visuel modifié et utilisé dans plusieurs écrans de l’application. Il arrive que certains de ces écrans aient été oubliés d’être checkés manuellement par le team de développement après modification du composant, l’automatisation via jDiffChaser palie à ces failles. Les zones que l’on ne veut pas comparer peuvent être définies comme “à ignorer” d’une action de souris, lors de l’enregistrement du scénario.

Libre à vous de choisir d’utiliser cet outil soit pour chasser les régressions visuelles soit pour visualiser et lister les changements entre versions.
Un exemple ci-dessous de comparaison hardue à l’oeil nu:

-

-

-

-