Défense vs Exploration (4)
— Ah ! Cette fois-ci on a à la fois les concepteurs, et les chasseurs de bugs.
— Oui. Appellons-les les “défenseurs” et les “explorateurs”.
— À lire cette carte on dirait que dans leurs activités respectives ils sont parfaitement isolés les uns des autres.
— C’est l’impression que donne ce pentagone bleu, mais c’est le contraire qui est vrai : les explorateurs fournissent sans cesse aux défenseurs des informations cruciales à propos du système, et réciproquement.
— Mais qui est responsable de sa qualité, au final ?
— Les deux acteurs sont responsables, et contributeurs.
— Il y a donc une phase de “build” et une phase de “test” ?
— Il y a plutôt deux activités menées parallèlement et en complément l’une de l’autre : les défenseurs conçoivent, spécifient, implémentent et vérifient les comportements de l’application. Les explorateurs, eux, recherchent activement des problèmes possibles avec l’application, dont les défenseurs n’auraient pas encore conscience.
— Je vois. Les défenseurs construisent des défenses. Les explorateurs vont au delà des défenses et cherchent les menaces qui ont échappé à la sagacité des défenseurs.
— Voilà.
— Pourquoi deux rôles ? Pourquoi les défenseurs ne deviendraient-ils pas des explorateurs à l’occasion ?
— Individuellement, c’est parfaitement possible, il suffit que l’organisation l’encourage.
— Je veux dire : la plupart des personnes que je connais et qui savent concevoir et coder un logiciel, seraient également capables, je pense, de tester ce logiciel de manière exploratoire.
— Peut-être. Mais mets-toi un moment à la place de l’organisation, du management. Comment tu établis que des développeurs ont bien fait leur travail ?
— S’ils ont livré dans les délais, un logiciel fiable, répondant au besoin, et du code facile à maintenir.
— Et comment est-ce que tu établis que des testeurs ont bien fait leur travail ?
— Je dirais : s’ils ont trouvé et signalé rapidement les problèmes les plus critiques ?
— Voilà. Le management peut exercer une pression, ou une incitation, qui encouragerait à la fois la tenue des délais et la ténacité à rechercher les menaces à la valeur. Sur une équipe, c’est assez simple. Sur un individu, c’est problématique.
— Donc, en résumé, qu’est-ce que tu préconises, comme stratégie de tests ?
— En bref :
1️⃣ Si tu veux créer et faire grandir un logiciel, tu dois à la fois défendre et explorer. Il te faut de bons concepteurs et de bon testeurs.
2️⃣ Les personnes qui conçoivent et construisent le système sont les mieux à même de le défendre: en écrivant des tests.
3️⃣ Les explorateurs/testeurs ne peuvent travailler efficacement que si le système a des défenses.
— Deux rôles pour assurer la qualité ça complique quand même un peu les choses, tu ne crois pas ?
— Ça les complique, mais pas autant que des nuées de bugs en production.