janvier
2010
Quel testeur n’a pas eu droit à cette remarque … perfide?
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.