12.12.2009 par Dominique Mereaux.

 Sur developpez.com j’ai trouvé cette traduction d’un blog de James Carr sur ce qu’il appelle les anti-pattern de tests de unitaires. C’est si drôle que je ne résiste pas à vous le faire partager. Merci à Bruno Orsier pour cette traduction.

anti-pattern de tests unitaires

Posté dans humour | Aucun commentaire »

7.12.2009 par Dominique Mereaux.

Dans Infos Test le lien “Blogs, Sites, Outils sur le test” mène à un portail qui référence des blogs, des outils et des forums liés au test. J’essaie de mettre à jour ce portail au fur et à mesure de mes découvertes. Pour l’instant il s’agit plutôt de lien mais je compte enrichir le site avec des descriptions plus complètes. Si vous connaissez d’autres outils n’hésitez pas à m’en faire part je les rajouterai.

Posté dans automatisation, Généralités, Outil de Test | Aucun commentaire »

4.12.2009 par Dominique Mereaux.

 Bret Pettichord recense un certain nombre de mauvaises pratiques liées à l’automatisation.

• Utiliser uniquement le temps libre pour automatiser n’est pas suffisant.

C’est une pratique tentante, qui exprime l’absence de confiance à réussir une approche de test automatisée. Pourtant les tests automatisés doivent s’inscrire dans une stratégie et être planifier à l’avance. Ils font partie des moyens efficaces pour réaliser nos objectifs à long terme et sont un investissement rentable pour les futures versions. Le test manuel n’est pas toujours suffisant et nous restreint sur le nombre de tests et jeux d’essais et donc limite la confiance de notre livraison.

• Pas d’objectifs clairs.

Automatisation sans objectifs clairs peut générer beaucoup d’efforts pour rien. Il s’agit de bien définir le périmètre de leur contribution afin de les concevoir correctement ainsi que les outils annexes.  Comme pour le développement il faut des spécifications: qu’est ce que nous voulons vérifier et comment allons nous y prendre?

• Pas d’expérience.

Le manque d’expérience peut conduire à des erreurs de conception. L’erreur la plus commune est de négliger la maintenance de ces tests et donc de limiter le ROI  (retour sur un investissement) lié au coût de l’évolution de ces tests à la version suivante. Une autre erreur est de tout automatiser sans se demander si le jeux en vaut la chandelle.

• Face à une situation critique on choisit l’automatisation en dernier recourt.

Un nombre de tests trop important, un délai trop court pour l’exécution et voilà une solution qui parait toute indiquée: l’automatisation. C’est sans compter l’effort initial à amener pour mettre en place un framework de test efficace. L’automatisation n’est pas simple, elle se planifie et a peu de chance d’être mener à terme dans une situation désespérée.

• Préférer de coder les tests automatiques plutôt de réfléchir au test.

C’est le travers fréquent des personnes qui réalisent les tests automatiques. Oubliés les besoins de test, vive le code et le test ne sert plus à rien ou répond partiellement aux objectifs de test comme par exemple ne tester que les cas nominaux et oublier les cas aux limites. Et je le vois tous les jours …

• Se concentrer sur les problèmes techniques de code automatique nous fait oublier si le résultat final correspond à notre problématique de test.

Faisons dans la simplicité, le code de test en sera plus fiable. Pourtant il arrive que pour traiter une problématique de test on déploie des efforts démesurés. Satisfait d’avoir résolu un aspect technique nous avons pris du retard sur des tests plus simples à implémenter et nous nous sommes pas demandés si finalement il n’était pas plus simple de le faire manuellement.

En conclusion ne perdons pas de vu qu’automatiser doit s’inscrire dans une stratégie de test  et être planifier en terme de coût et moyens. C’est un process qui ne supporte pas l’improvisation au risque de courir à l’échec.

Posté dans automatisation | Aucun commentaire »