Un site, plein d’infos et de news sur le test qui vaut le détour, animé par Rosie Sherry. Vous y trouverez des blogs, un journal dédié aux tests, des communautés et un groupe de french testers: http://www.softwaretestingclub.com/group/frenchtesters N’attendez plus pour vous inscrire …

Autre site pour vous dépanner sur les outils de test :

http://www.sqaforum.com/

Bon surf.

Dominique

Les managers ont eu le retour du terrain et la sentence tombe de suite: la validation n’a pas bien fait son travail sinon nous n’aurions pas eu tant de problèmes rencontrés chez le client. Ces mêmes managers d’ailleurs qui passent leur temps à rogner sur les budgets du test! Nous pourrions rétorquer, et les développeurs alors, ils ont codé les bugs. Facile mais pas très productif.

Comment pallier à ce problème?

Tester de façon exhaustive coûte cher et dure trop longtemps.
Il faut donc résoudre la terrible équation, maintenir le niveau de qualité sans exploser les délais:

• Faire des choix
• Écrire des tests les plus proche du comportement utilisateur

Faire des choix:
Il s’agit de déterminer ce qui est important à tester d’un point de vue utilisateur final, marketing, production … L’effort de test sera ajusté à l’importance de la fonctionnalité.

Écrire des tests les plus proche du comportement utilisateur:
Certains tests sont plus simple à écrire que d’autre, par exemple vérifier qu’un profil utilisateur dans un forum a été correctement mis à jour est facile(il s’agit de concevoir des jeux d’essais avec les cas nominaux, les cas aux limites et les erreurs, et de vérifier en base les valeurs ou les erreurs levées) mais imaginer toutes les séquences qui amènent l’utilisateur à mettre à jour son profil ou les événements (problème internet, accès concurrent) qui peuvent arriver pendant la mise à jour c’est une autre histoire. Ces tests sont difficiles à élaborer seul, pire la combinatoire devient vite infernale, de plus ces tests parfois un peu tordus sont-ils vraiment pertinents?

Comment faire?
La meilleure façon je pense est de travailler avec tous les acteurs du projets: marketing, utilisateur, quelqu’un de la production, des gens du terrain, le chef de projet pour élaborer ce type de scénario moins trivial. La mise en place de relecture de plans de tests est aussi efficace, même si personne n’est vraiment fou de joie à cette idée.

Cette idée est de plus en plus mise en avant: équipe de test intégrée aux services qualités, possibilité de refuser une livraison, les testeurs maîtrisent la spécification et les points de vue utilisateurs et les activités de développement et de test sont séparées.
Pour avoir travailler dans ce type d’organisation, j’ai observé les travers suivants:
– mauvaise qualité des tests unitaires
– le développement ne se préoccupe pas des expériences utilisateurs et celle des autres intervenants d’ailleurs (production, administration …)
– mauvaise communication entre équipe projet et test
– dé-responsabilisation du chef de projet vis à vis de la décision de livrer
etc …

La qualité ne devrait-elle pas être un objectif commun à toute l’équipe?
C’est possible en définissant en amont pour un produit quels sont les objectifs en terme de qualité (utilisabilité, fiabilité, maintenabilité, sécurité …) à atteindre et les partager sur toutes les activités (définition des exigences, conception, développement et test).

En effet comment avoir un produit robuste aux attaques si on a pas pris cette objectif en compte lors de la conception? Comment avoir un produit fiable si les tests unitaires n’ont pas été effectués?

Quelques pratiques peuvent nous aider à améliorer la qualité:

– Définir en amont les objectifs qualité à atteindre.
– Définir avec tous les intervenants en amont les principaux scénarios utilisateurs y compris ceux des administrateurs, opérateurs et production.
– Mettre en place des pratiques de TDD (test driven development)plutôt que de s’acharner sur des conceptions détaillées.
– Former les équipes aux tests, pas uniquement les testeurs.
etc …

Si vous avez calculé votre Retour sur Investissement vous avez certainement pris en compte les paramètres suivants:

– Apprentissage de l’outil (langage utilisé, ergonomie …)

– Mise en place de l’outil (intégration avec d’autre outils, codage d’un framework …)

– Maintenance (mise à jour des scripts pour l’itération suivante).

Par exemple selenium (libre) permet de coder des scripts dans différents langague (java, python …) très largement utilisés, QTP (HP) utilise uniquement VB script.

QTP offre de nombreuse facilités pour coder rapidement des scripts de test (drag and drop d’objets graphiques, complétion …), avec Sélénium tout est à faire manuellement.

D’autres paramètres sont à prendre en compte:

– Quel est le niveau technique des utilisateurs de l’outil?

– Y-a-t-il une communauté conséquente et active qui utilise l’outil (forum, formation …)?

– L’outil est-il maintenu?

– L’outil s’intégre-t-il facilement avec d’autres outils utilisés par votre société?

– Répond-il à vos objectifs d’automatisation? Supporte-t-il les technologies que vous utilisez?

– Le prix mais est-ce vraiment un critère (un outil cher mais qui se déploie et s’utilise facilement n’est pas plus rentable qu’un outil du libre qui peut coûter cher à mettre en place)

Avec ces premières questions vous aurez réduit votre choix à deux ou trois outils.

Avant de vous engager le mieux est de mettre en place une évaluation comparative des outils avec des critères de type:

– techniques (capacité à résoudre vos principales difficultés techniques)

– facilité d’utilisation (va-t-il être adopté facilement par votre organisation?)

– facilité d’intégration avec des outils déjà existants.

Phase 0: Il n’y a pas de différences entre le test et le debug. L’objectif premier du test est le support du debug.

Phase 1: L’objectif du test est de démontrer que le logiciel fonctionne.

Phase 2: L’objectif du test est de démontrer que le logiciel ne fonctionne pas.

Phase 3: L’objectif du test n’est pas de démontrer quoi que ce soit mais de réduire le risque ressenti d’un logiciel ne fonctionnant pas jusqu’à un niveau acceptable.

Phase 4: Tester n’est pas un acte. C’est une discipline mentale qui produit un logiciel avec un risque bas d’anomalies grâce à peu d’effort de test.

Je vous laisse méditer !!!

Les points positifs:

* Économie de moyen, pas de process lourd
* Créativité de par la méthode et l’absence de cadre
* Retour rapide, nombre d’anomalies important
* Vision utilisateur
* Adaptabilité
* Test basé sur l’expérience et l’intuition

Les points négatifs:

* Nécessite des testeurs expérimentés.
* Le processus de test débute trop tard, pas de prévention.
* Pas de couverture d’exigence, certains points peuvent être alors négligés.
* La pertinence des tests dépend de l’expérience des testeurs.

Dans quels cas utiliser cette méthode:

* Absence de processus et de structuration, néanmoins il faut une aide en ligne ou un manuel utilisateur à jour.
* Moyen de retour rapide qui pourrait être utiliser comme “smoke test” avant de débuter un processus de test structuré.
* En beta test amélioré avant déploiement sur le terrain pour détecter des problèmes non vus par les équipes de développement.
* Pour des prototypes ou pilotes qui ne nécessitent pas un investissement en test couteux.

Basé sur l’expérience, la créativité de testeurs confirmés, ce type de test permet de découvrir des anomalies qui échappent à des techniques structurées. En effet les processus de test classiques n’encouragent pas à “sortir des sentiers battus” et imaginer lors des phases d’exécution de nouveaux tests autres que ceux planifiés (pression des plannings, exécutants non expérimentés …). Il m’a souvent été reproché de passer des tests non prévus, mais comment avec toute la meilleure volonté du monde écrire un plan de test exhaustif à partir de spécifications surtout quand sont abordées les exigences de type non fonctionnelles telles que la robustesse.

Ne faire que du test exploratoire me parait également non suffisant. Le risque est de ne pas tester certaines parties. Tout dépend de la motivation et l’expérience du testeur. S’il quitte la société?

Par contre combiné à d’autre stratégie de type méthodique il est un complément intéressant, puissant,peu couteux et peut s’intégrer à part entière dans le processus de test.