Si l'assurance qualité des logiciels commençait par un nombre spécifique de bogues, il serait peut-être plus facile de trouver tous les problèmes. Par exemple, de nombreux livres de puzzle vous montrent un dessin et vous demandent de trouver un nombre exact d'objets cachés. Ou bien, ils vous montrent une paire de dessins et vous demandent de repérer un certain nombre de différences entre eux.
Dans le développement de logiciels, le nombre cible de différences - ou de bogues - n'est pas toujours aussi précis. Combien plus facile serait l'assurance qualité des logiciels si quelqu'un pouvait nous chuchoter à l'oreille combien de bogues il y a à trouver ? En réalité, nous ne le savons jamais. Nous ne connaissons qu'un minimum : si nous avons trouvé 37 bogues, nous savons qu'il y a au moins 37 bogues. Peut-être qu'il y en a encore un à trouver, ou peut-être qu'il y en a des centaines - nous ne pouvons pas en être sûrs.
Il serait utile d'avoir une idée approximative du nombre de bogues restants, afin que nous puissions utiliser au mieux nos ressources de test. Si nous supposons toujours qu'il reste des centaines de bogues à trouver, nous risquons de surtester un produit au détriment des autres. Si nous avons des raisons de penser que nous avons trouvé tous les bugs, ou presque tous, nous pouvons redistribuer nos ressources pour utiliser au mieux leur temps et leurs efforts.
Estimations approximatives
Rien ne peut vous dire combien de bogues subsistent lors de l'AQ des logiciels, mais un peu de mathématiques peut vous donner une estimation. Supposons que vous ayez un testeur qui a trouvé un certain nombre de bogues. Si vous connaissiez non seulement son efficacité à trouver des bugs, mais aussi la probabilité qu'elle trouve chaque bug pendant une période donnée, vous pourriez estimer le nombre de bugs à trouver. Mais vous ne pouvez pas savoir quelle proportion de bugs elle a trouvée sans savoir combien il y en a à trouver.
Supposons maintenant que vous avez un autre testeur, et qu'il a également trouvé un certain nombre de bogues. Vous ne savez pas non plus quelle proportion de bugs il a trouvée. Mais en combinant les comptes de bogues des deux testeurs, vous pouvez estimer le nombre de bogues.
Cela peut sembler trop beau pour être vrai, mais ce n'est pas le cas - la clé est de considérer combien de bogues les deux testeurs ont trouvé. Supposons que le premier testeur ait trouvé 20 bogues et que le second ait trouvé 30, mais qu'il n'y ait qu'un seul bogue que les deux aient trouvé. Vous pourriez vous douter qu'il y a beaucoup de bogues à trouver, puisque les deux ont pu en trouver autant en ne se chevauchant pratiquement pas. D'un autre côté, si 18 des bogues de la première liste se trouvent sur la deuxième liste, vous pouvez penser que vos testeurs ont probablement trouvé la plupart d'entre eux.
L'index Lincoln
Vous pouvez quantifier une estimation avec un outil connu sous le nom d'"indice de Lincoln". Si le premier testeur a trouvé des bogues A, le second des bogues B et qu'ils ont en commun des bogues C, le nombre total estimé de bogues serait AB/C. Dans le premier exemple ci-dessus, A = 20, B = 30, et C = 1. Dans ce cas, il y aurait un total estimé de 600 bugs à trouver. Mais dans le deuxième exemple ci-dessus, A = 20, B = 30, et C = 18. Dans ce cas, il y aurait environ 33 1/3 bogues.
Comment trouver 1/3 d'un insecte ? Vous pouvez trouver 1/3 d'un bug dans votre soupe, mais vous ne trouverez pas 1/3 d'une erreur logicielle. L'indice de Lincoln est un simple modèle mathématique, il ne peut donc pas vous dire exactement combien il y a de bogues. Il fait quelques hypothèses simplificatrices, à savoir que les testeurs trouvent les bogues de manière aléatoire et indépendante. Ce ne sera pas tout à fait vrai dans la pratique, ce qui signifie que nous devrions être sceptiques quant au chiffre qu'il génère. Néanmoins, l'indice de Lincoln nous donne une estimation sur laquelle nous pouvons nous baser, ce qui est bien mieux que de dire : "Je n'ai aucune idée du nombre de bogues".
Voici les mathématiques derrière l'indice de Lincoln : Supposons qu'il y ait N bugs au total, et que le premier testeur ait une probabilité p de trouver chaque bug. Elle trouverait alors environ A = Np bogues. Si le second testeur a une probabilité q de trouver chaque bogue, il trouvera environ B = Nq. Et s'ils trouvent des bogues indépendamment, ils trouveraient environ C = Npq bogues en commun. Alors AB/C devrait être autour de (Np)(Nq)/(Npq) = N, le nombre de bogues. Les probabilités que chaque testeur trouve un bogue s'annulent mutuellement.
Conclusion
Bien que le processus d'assurance qualité des logiciels ne sera jamais aussi simple qu'un puzzle "repérez les différences", pour certains types de développement de logiciels, il existe des outils simples pour aider à estimer ce nombre insaisissable de bogues totaux. Grâce à l'indice de Lincoln, nous pouvons déterminer le niveau de chevauchement entre nos ressources de test, ce qui correspond généralement à la proportion de bogues qu'il reste à découvrir. Grâce à cette estimation approximative, nous pouvons prendre des décisions fondées sur des données quant à la meilleure façon d'allouer nos ressources.
![Un plan de gestion du travail collaboratif mondial [Vidéo] (en anglais)](https://blog.planview.com/wp-content/uploads/2019/07/A-Global-Collaborative-Work-management-blueprint.png)
