Dans de nombreuses entreprises les tests logiciels sont réalisés par le métier, certaines fois par des business analyst ou des testeurs dédiés. Et parfois on retrouve deux d’entre eux voire les trois. On va alors dissocier la vérification des business analysts ou des testeurs dédiés sur la base d’user story de la validation des métiers sur la base de leur expérience.

Certaines personnes vont dire que la validation des métiers et la vérification des autres acteurs n’ont absolument rien à voir, en y ajoutant une vision quasi mystique. Nonobstant les niveaux de test, les deux testent le logiciel en réalisant des actes de gestion…

Comparatifs

Revenons donc au fondamentaux, l’objectif des tests est de simuler une future utilisation en vue de s’assurer de son bon fonctionnement.

Quel est donc la valeur d’une phase de validation métier sans se préoccuper de la solution. On verra sans doute des évolutions à y apporter, mais qu’on aurait aussi pu donner en ayant une vision de la solution. Par contre on va surtout éprouver des difficultés à tester et on a tous vu des anomalies qui n’en sont pas (et qui ne sont pas non plus des évolutions) par la méconnaissance par le métier de la solution. Il semble donc important que la validation du métier se base sur leur expérience mais aussi sur la connaissance de la solution.

Quel est donc la valeur d’une phase de vérification sans se préoccuper de l’utilisation qu’on va en faire. On verra sans doute beaucoup d’anomalies, mais certaines correspondront à des comportements qui n’existeront jamais en production (engendrant des surcoûts et des allongements du délai projet). Une bonne vérification s’appuie donc sur la connaissance de la solution mais aussi sur celle de sa future utilisation.

On voit donc que finalement malgré les dissociations que l’on en fait la vérification et la validation devraient être très proches pour être efficientes. L’une devrait se baser sur la connaissance de la solution sans oublier l’expérience terrain et l’autre devrait se baser sur l’expérience terrain sans oublier la connaissance de la solution.

Pourquoi continuer à conserver dans de nombreuses organisations ces deux phases de test non efficientes quand finalement leurs optimisations les rendent très semblables. On pourrait plutôt faire de la « vérifi-dation » ou de la « vali-cation », ou plus simplement de la qualification.

Je ne dis pas qu’il faut enlever le regard métier final sur la solution, mais ne pas le traiter comme une phase de test à proprement parler et tout ce que cela implique (cahier de test…). Faisons une qualification en étroite collaboration avec le métier pour avoir une phase de test efficiente, tenant compte de la réalité terrain, et une prise en main de la solution par le métier pour préparer le changement en production. Cela aurait aussi pour objectif de libérer de la bande passante pour les acteurs métier.

Donc comme pour le précédent article pas de gagnant pour ce combat, mais à la différence pas de match nul non plus, mais une réorganisation des équipes.