Les bétas fonctionnent-elles ?

Vous avez probablement entendu parler du mémo interne de Microsoft affirmant qu’il
y avait 63.000 bugs dans Windows 2000. En fait, si Windows 2000 avait vraiment
été lancé avec seulement 63.000 bugs, Microsoft aurait de quoi se réjouir. Compte
tenu de la taille de Windows 2000 et des standards traditionnels du marché en
matière de qualité, Microsoft pourrait avoir sorti un OS avec 10 fois plus de
bugs et marcher la tête haute. L’industrie du logiciel admet comme normale une
quinzaine de bugs par millier de lignes de code.
Si l’on croit la rumeur prétendant que Windows 2000 comprendrait 40 millions de
lignes de code, un simple calcul permet de dire qu’on pourrait s’attendre à  600.000
bugs si Microsoft avait développé Windows 2000 selon les normes admises.

Les éditeurs tentent d’améliorer la qualité de leurs logiciels à  travers des campagnes
de tests. Certains tests font appel à  des scripts de tests automatiques qui utilisent
des versions temporaires des programmes en développement sur une variété de plates-formes
hardware. Autre type de tests, les béta tests consistent en un envoi, par les
éditeurs, de pré-versions de leurs logiciels avant leur mise sur le marché. Mais
la plupart des sociétés de logiciels affirment que les campagnes de béta tests
ne remontent que peu de bugs. Selon un de mes interlocuteurs chez Microsoft, au
cours de la campagne de tests de Windows NT 4.0, seuls 10 % des bugs trouvés l’ont
été par les béta testeurs extérieurs.

Je soupçonne que le principal intérêt des campagnes de béta test soit le marketing.
Le test de béta implique l’utilisateur dans le processus de développement. Le
client se sent plus impliqué dans le développement du produit.
Durant cette phase, l’éditeur est plus sensible à  ses commentaires et suggestions.
Certaines de ces suggestions font évoluer le produit dans un sens plus favorable.
Peut-être devrait-on changer l’appellation de  » béta test  » et parler d' » évaluation
en avant-première « .
Pourquoi ce pinaillage ?
Parce que de nombreux experts de la qualité logicielle pensent que, la seule façon
d’empêcher la diffusion de logiciels truffés de bugs, est de cesser d’utiliser
les tests par les utilisateurs comme principale méthode d’amélioration de la qualité.
Contrairement à  toutes les autres industries basées sur les progrès technologiques,
l’informatique exclusivement sur les tests pour supprimer les défauts. On sait
depuis plus de 20 ans que les tests sont chers et inefficaces pour éliminer les
défauts des produits, fussent-ils des logiciels.
Mais si l’on n’utilise pas les tests, que faire ?
Les concepteurs de logiciels ont créé de nombreuses approches au fil des ans et
on ne peut décrire toutes les alternatives ici. Mais la plupart des alternatives
s’appuient sur plus de 50 ans d’expérience dans l’amélioration des processus industriels.
Considérons le problème autrement : que se passerait-il si Airbus adoptait une
approche de chef de projet informatique pour concevoir ses nouveaux avions. ( »
Alors, Michel, on peut livrer le nouvel A3XX ? « ,  » Pas de problème Jean-Louis,
on ne m’a signalé aucun crash au cours des derniers mois « ).
Au lieu de cela, les constructeurs d’avions utilisent un processus de développement
qui privilégie la conception aux tests. Ainsi, on évite de produire de nombreux
avions béta qui ne fonctionnent pas. Les éditeurs de logiciels devraient s’inspirer
de cette approche en privilégiant la conception de leur code et moins son écriture
et sa diffusion afin de voir s’il fonctionne.

Cette approche pourrait-telle fonctionner ?
Motorola a utilisé un process de contrôle de qualité lors de la conception du
logiciel de ses téléphones cellulaires StarTAC. Le résultat ?
Dans 2 Mo de code, pas moins de 24 défauts recensés. A qui se fier ?