Joel on Software   Joël à propos de logiciel

D'autres articles de "Joel on Software" en Français

D'autres articles de "Joel on Software" en Anglais

Contacter l'auteur (En Anglais uniquement)

Nous sommes en 1992. James Gleick se bat avec un programme plein de bugs. Une nouvelle version de Microsoft Word pour Windows est sortie et Gleick, rédacteur scientifique de son état, la trouve horrible. Il écrit dans le Sunday New York Times Magazine un long article que l'on pourrait décrire comme une attaque en règle, accusant l'équipe de Word d’indifférence à l’égard des besoins de ses clients et l’épinglant pour avoir délivré un produit bourré de bugs.

Plus tard, en tant que client d'un fournisseur d'accès local à Internet (Panix qui, par hasard, était aussi mon fournisseur d'accès), il chercha un moyen de trier et de filtrer automatiquement son courrier électronique. L'outil UNIX approprié s'appelait procmail. C'était un truc vraiment mystérieux qui avait le genre d'interface utilisateur dont même les groupies les plus convaincus de UNIX admettent qu'elle était pour le moins obscure.

Quoi qu'il en soit, Mr Gleick fit un jour par inadvertance une faute de frappe tout à fait innocente dans procmail et tous ses emails furent effacés. Dans un accès de rage, il décida de créer sa propre société d'accès à Internet. Il engagea un programmeur, Uday Ivatury, et créa Pipeline, un logiciel assez en avance sur son temps : c'était le premier fournisseur commercial d'accès à Internet à proposer une interface graphique. 

Bon, Pipeline avait bien sûr son lot de problèmes. La première version n'utilisait aucun protocole de correction d'erreurs et avait, de ce fait, la fâcheuse tendance à brouiller l'affichage ou à se planter. Comme n'importe quel logiciel, il contenait des bugs. J'ai posé ma candidature pour un emploi chez Pipeline en 1993. Pendant l'entretien, j'ai questionné Mr Gleick à propos de son article : "Maintenant que vous êtes de l'autre côté de la barrière," lui demandai-je, "percevez-vous un peu mieux la difficulté de créer un bon programme ?"

Gleick ne se repentait pas. Il nia que Pipeline eût quelque bug que ce soit. Il nia qu'il fût un tant soit peu aussi mauvais que Word. Il alla jusqu'à me dire : "Un jour, Joël, tu en viendras aussi à détester Microsoft." Cela m’a choqué de voir que son année d'expérience comme créateur de logiciel, et plus seulement comme utilisateur, ne lui avait pas enseigné le moindre soupçon d'appréciation sur la difficulté de créer un programme sans bugs et facile à utiliser. Je déclinai donc son offre et m'encourus.  (Pipeline fut racheté par PSI, le plus étrange de tous les fournisseurs d'accès à Internet de la planète, puis passa aux oubliettes.)

Tout logiciel contient des bugs. Les CPUs sont atrocement méticuleuses. Elles refusent catégoriquement de faire les trucs qu'on ne leur a pas explicitement appris, et elles ont tendance à exprimer ce refus de la plus infantile des manières. Quand mon portable n'est pas à la maison, il se plante souvent parce qu'il ne trouve pas son imprimante réseau habituelle. Quelle gaminerie ! Ce comportement est probablement dû à une simple ligne de code enfouie quelque part qui contient un minuscule insignifiant petit bug.

C'est pourquoi il vous faut absolument un service de QA (Assurance Qualité). Vous allez avoir besoin d'un testeur pour deux programmeurs (plus si votre programme doit tourner dans un tas de configurations compliquées ou de systèmes d'exploitation différents). Chaque programmeur devrait travailler la main dans la main avec un testeur donné, en l'alimentant avec des builds privés aussi souvent que nécessaire.  

Le service de QA doit être indépendant et puissant, ne pas rapporter hiérarchiquement à l'équipe de développement ; en fait, le patron du service de QA doit avoir un droit de veto sur la sortie d'un programme si celui-ci n'atteint pas le niveau de qualité requis.

C'est chez Microsoft que j'ai décroché mon premier vrai job d'informaticien. Microsoft n'est pas exactement réputée pour la haute qualité de son code, mais emploie malgré tout un grand nombre de testeurs. Donc, quelque part, j'ai supposé que chaque département logiciel avait ses testeurs.

Beaucoup en ont. Mais il y en a vraiment beaucoup qui n'en ont pas. En fait, beaucoup d'équipes de développement ne croient même pas au testing.

On pourrait croire qu'après cette manie de la Qualité dans les années 80, avec toutes les certifications internationales dénuées de sens qui en ont découlé, genre ISO-9000, et les expressions à la mode, genre "Six sigma", les responsables d'aujourd'hui comprendraient qu'avoir des produits de haute qualité est du simple bon sens commercial. En réalité, ils l'ont compris. La plupart ont réussi à se le fourrer dans la tête. Mais ils continuent d’évoquer un tas de raisons pour ne pas avoir de testeurs. Et ce sont toutes de mauvaises raisons.

J'espère pouvoir vous expliquer pourquoi ces idées sont fausses. Mais si vous êtes pressé, faites l'impasse sur le reste de l'article et courez engager un testeur à temps plein par paire de programmeurs que compte votre équipe.

Voici les excuses les plus lamentables que j'aie entendues pour ne pas engager de testeurs:

1. Ce sont les programmeurs paresseux qui font des bugs.

"Si nous engageons des testeurs", dit la légende, "les programmeurs vont se la couler douce et écrire du code bogué. En nous passant de testeurs, nous forçons les programmeurs à écrire le code correctement du premier coup."

Mdr. Celui qui pense cela n'a jamais codé, ou alors c'est vraiment un gros malhonnête. Les bugs, par définition, s’introduisent parce que les programmeurs ne les voient pas dans leur propre code. Bien souvent, il suffit d'une deuxième paire d'yeux pour les détecter.

A l'époque où je programmais chez Juno, j'avais tendance à faire toujours les mêmes manips pour tester mes programmes... avec mes propres habitudes, telles qu'utiliser un maximum la souris. Notre merveilleuse testeuse (d'ailleurs complètement surqualifiée) avait des habitudes légèrement différentes : elle travaillait plus à l'aide du clavier (et testait réellement, et rigoureusement, les interfaces utilisateurs, en essayant toutes les combinaisons possibles). Ce qui mettait rapidement au jour un tombereau de bugs. Il y avait carrément des fois où elle me disait que mes écrans ne fonctionnaient pas du tout, absolument rien ne fonctionne, alors que chez moi, tout se passait très bien. Et quand je la regardais reproduire le bug, c'était bon sang mais c'est bien sûr. Alt! Tu tiens la touche Alt enfoncée! Pourquoi n'avais-je pas pensé à ça?

2. Mon logiciel est sur le Web. Je peux le corriger dans la seconde.

Ha ha ha ha! Bon, d'accord, c'est vrai, la distribution via le web permet de diffuser des corrections de bugs bien plus rapidement qu'au vieux temps des programmes en version boîte. Mais ne sous-estimez jamais le prix de la correction d'un bug, même sur un site web, une fois que le projet est clos. D'abord, vous risquez d'introduire encore plus de bugs que vous n'en corrigez. Mais il y a plus grave : si vous regardez de plus près au processus en place pour publier les nouvelles versions, vous réaliserez que cela coûte finalement plus cher qu'il n'y paraît de diffuser des corrections sur le web. Sans compter la mauvaise impression que cela va faire, ce qui nous mène à :

3. Mes clients testeront le programme pour moi.

Ah, la redoutable "Défense Netscape". Cette malheureuse société a réussi à causer un tort fabuleux à sa réputation à cause de sa méthodologie de "test" :

1. Quand les programmeurs en sont à peu près à la moitié du projet, publier une version du programme sur le Web sans effectuer le moindre test.
2. Quand les programmeurs disent avoir fini, publier une version du programme sur le Web, toujours sans effectuer le moindre test.
3. Répéter six ou sept fois.
4. Appeler une de ces versions la "version finale".
5. Publier une version .01, .02, .03 chaque fois qu'un bug embarrassant est mentionné sur c|net.

Cette société explora la première l'idée des "bêtas élargis". Ce sont carrément des millions de personnes qui ont téléchargé ces versions intermédiaires pleines de bugs. Pendant les premières années, presque tous les utilisateurs de Netscape utilisaient une de ces versions bêta ou pré-release. Le résultat, c'est que tout le monde s'imagine que Netscape est bogué de partout. Même si la version finale fut raisonnablement exempte de bugs, Netscape avait tellement d'utilisateurs de versions boguées que l'opinion générale s'accordait à trouver le logiciel assez nul.

Cela dit, la grande idée derrière ça, c'est de laisser vos clients faire les tests et remonter les bugs, charge à vous de les corriger. Malheureusement, ni Netscape, ni aucune autre société au monde, n'a les moyens humains de parcourir les rapports de bugs en provenance de 2.000.000 clients et d’en extraire les plus importants. Quand j'essayais de rapporter des bugs sur Netscape 2.0, leur site se plantait, m'interdisant de rentrer le moindre rapport (qui de toute façon serait ensuite tombé dans un trou noir). Mais Netscape n’en a guère tiré leçon. Les testeurs de la version "preview" actuelle, 6.0, se sont plaints dans les forums de discussion que le site web de rapports de bugs ne marche toujours pas. Des années plus tard ! Même problème !

De toute façon, parmi ces milliards de rapports de bugs, je parie que la plupart concernent les mêmes 5 ou 10 bugs vraiment évidents. Enfouis dans cette botte de foin, il y aura un ou deux bugs difficiles à trouver, que quelqu'un aura pris la peine de soumettre. Mais de toute façon, personne ne lit ces rapports et ce sera donc en pure perte.

L'effet le plus redoutable de cette forme de test est l'image foncièrement mauvaise qu’elle donne de la société. Quand Userland a publié la première version pour Windows de Frontier, son produit phare, je l'ai téléchargé et j'ai commencé à travailler à l'aide du tutoriel. Malheureusement, Frontier s'est planté plusieurs fois. Je suivais pas à pas les instructions telles qu'elles étaient décrites dans le manuel, et le programme n’a jamais mis plus de 2 minutes à se planter. J'avais l'impression que personne chez Userland n'avait pris la peine de faire un minimum de tests, histoire de s'assurer que le tutoriel fonctionne. Cette impression de mauvaise qualité m'a tenu éloigné de Frontier pendant un sacré bon bout de temps. 

4. Un bon testeur ne veut pas être testeur.

Celle-là est pénible. Il est réellement difficile de trouver des bons testeurs. 

Chez les testeurs, c'est comme chez les programmeurs, les meilleurs dépassent la moyenne d'au moins une tête. Chez Juno, nous avions une testeuse, Jill McFarlane, qui trouvait à elle seule trois fois plus de bugs que les quatre autres testeurs tous ensemble. Et je n'exagère pas, je l'ai réellement mesuré. Elle était plus de douze fois plus productive que le testeur moyen. Quand elle s'en alla, j'ai envoyé un e-mail au directeur général en disant que "je préfère avoir Jill seulement les lundis et mardis que le reste de l'équipe de test à temps plein".

Malheureusement, la plupart des ces personnes si intelligentes ont vite tendance à s'ennuyer à faire des tests à longueur de journée ; de ce fait,  les meilleurs testeurs ne restent généralement que 3 ou 4 mois et puis s'en vont.

La seule chose à faire avec ce problème, c'est admettre qu'il existe, et vivre avec. Voici quelques suggestions :

• Utiliser le testing comme une perspective d’évolution pour les employés du support technique. Tester est fastidieux, mais cela l’est certainement moins qu'avoir affaire à des clients furieux au téléphone. Cela peut également permettre d'enrayer les départs côté support technique.
• Donner aux testeurs l’accès à des cours de programmation, et encourager les meilleurs d'entre eux à développer des procédures de tests automatisées en utilisant des outils de programmation ou des langages de scripts ; ce qui est infiniment plus intéressant que tester la même boîte de dialogue encore et toujours.
• Admettre que vous allez avoir beaucoup de rotations parmi vos meilleurs testeurs. Adopter une politique de recrutement agressive pour ne pas tomber à court de personnel. Continuer d’embaucher même si l'effectif est complet, parce que dites vous bien que l'âge d'or ne durera pas.
• Chercher des employés "alternatifs" : adolescents débrouillards, étudiants, pensionnés/retraités, qui travailleraient à temps partiel. On peut se créer une équipe du tonnerre avec deux ou trois super testeurs à temps plein et une armée de gosses de Bronx Science (Un collège new-yorkais très bien coté) travaillant l'été pour se payer leurs études.
• Engager des intérimaires. Si vous engagez une dizaine d'intérimaires pour venir taper sur votre logiciel pendant quelques jours, vous mettrez au jour un nombre incroyable de bugs. Parmi eux, deux ou trois auront de bonnes dispositions pour le testing, auquel cas cela vaut la peine de négocier leur engagement à temps plein. Préparez vous à l'idée que certains d'entre eux seront totalement inutiles en tant que testeurs ; renvoyez-les chez eux et continuez votre boulot. C'est à ça que servent les agences d'intérim.

Voici maintenant ce qu'il ne faut pas faire :

• Ne même pas envisager d’attirer des jeunes diplômés en informatique "mais chacun ici doit faire un passage au département QA avant de commencer à développer". J'ai vu ça souvent. Mais les programmeurs ne font pas de bons testeurs, et vous risquez de passer à côté d'un bon développeur, ce qui est beaucoup plus difficile à remplacer.

Et pour finir. La raison la plus stupide pour ne pas engager de testeurs :

5. Je ne peux pas me payer des testeurs !

Celle-ci est la plus stupide, et la plus facile à démonter.

Quelle que soit la difficulté pour trouver des testeurs, ils restent toujours moins chers que les programmeurs. Beaucoup moins chers. Et si vous n'engagez pas de testeurs, ce seront vos programmeurs qui feront les tests. Et si vous l'avez mauvaise de voir le roulement parmi vos testeurs, attendez de voir ce que ça vous coûte de remplacer ce super programmeur au salaire de star lassé qu’on lui demande de « faire quelques semaines de tests avant la prochaine release » quand il se sera envolé vers une société plus professionnelle. Vous auriez pu vous payer un testeur pendant un an rien qu'avec la commission du recruteur chargé de remplacer ce développeur.

Traiter le problème des testeurs à la va-vite constitue un si mauvais calcul que je reste abasourdi de constater que si peu de monde le reconnaisse.