Un bug informatique à 193 millions de dollars : c’est ce dont a été victime la NASA pour avoir négligé les tests d’un logiciel informatique. C’est l’équivalent de :
- 2 Airbus A320 de 160 passagers
- 10 rames de TGV de 400 passagers
- 76 Bugatti Veyron, la voiture la plus chère au monde
Impossible ! me direz-vous. C’est pourtant la mésaventure qui a fait perdre 2 ans de travail et 76 Bugatti Veyron à la NASA.
Découvrez les tests qu’il vous faut et devenez meilleurs que la NASA dans la correction des bugs !
La sonde Mars Climate Orbiter promettait de nombreuses découvertes scientifiques sur le climat de la planète rouge.
Lancée en 1999, elle devait atteindre Mars 9 mois plus tard avec une vitesse phénoménale : 19.800 km/h, soit la distance entre le Royaume-Uni et l’Australie en 1 heure. « Devait », car au lieu d’entrer dans l’atmosphère à 226 km d’altitude comme prévu, elle y pénétra à 57 km d’altitude : 4 fois trop bas !
Surchauffée telle une météorite entrant dans l’atmosphère, la sonde fut rapidement réduite à une boule incandescente dont les éléments furent pulvérisés à la surface de la planète telle un moucheron sur le pare-brise d’une voiture.
Impensable ! Quelle erreur saugrenue ont bien pu faire les ingénieurs de la NASA ?
Elle est très simple : la NASA avait confié la construction du moteur de poussée à Lockheed Martin Astronautics, dont le logiciel effectuait tous ses calculs en utilisant l’unité coutumière américaine : la livre-seconde (oui, ce sont les mêmes livres que pour peser le beurre). Alors que le logiciel de calcul de trajectoire réalisé par la NASA attendait des valeurs en unité du Système International, donc en newtons-seconde. Soit un rapport d’environ 3,9…
Satanés développeurs qui créent des bugs !
Qui est responsable ? « Les développeurs de Lockheed Astronautics », me direz-vous. Faux !
Faisons un petit jeu de rôle : imaginons qu’une de vos amies très chères vous demande de choisir sa robe de mariée car vous êtes réputé pour votre incroyable sens de l’esthétique. Vous êtes un homme sans goût qui n’a pas d’amie prête à se marier ? Pas de panique : c’est un jeu de rôle, pour les 3 prochaines minutes, vous avez le droit de tout imaginer (même d’avoir une Bugatti Veyron avant que la NASA ne l’écrase sur Mars si vous le souhaitez).
Frous-frous, dentelles, ceintrée, ample, avec ou sans traîne… les options sont nombreuses pour une robe de mariée. Vous enchaînez les boutiques et affinez petit à petit les options qui feraient plaisir à votre amie. Enfin, le grand jour approche, et à une semaine de la cérémonie, vous lui montrez votre trouvaille… et vous déclenchez une crise de larmes.
Pourquoi ? C’est évident, me direz-vous : parce que vous avez choisi une ceinture hideuse, un tombé mal fagoté ou des fanfreluches disgracieuses. Pas du tout, puisque vous avez un sens de l’esthétique incroyable ! La robe est donc d’une classe à tomber par terre, sa tenue est parfaite, ses accessoires sont assortis à merveille. Dans ce cas, pourquoi votre amie est-elle maintenant absorbée à liquéfier minutieusement son maquillage ?
Car vous avez choisi une robe de mariée blanche. C’est évident, n’est-ce pas ? Le blanc, symbole de pureté et d’innocence. Pourtant, saviez-vous que les mariées portent :
- en Inde, du vermillon, symbole de la fête ?
- en Chine, du rouge, symbole du bonheur et de la longévité ?
- en Mauritanie, du noir, symbole de l’attachement aux coutumes ?
- et que même en France au Moyen-Age, on se mariait en rouge, symbole de joie et de fête ?
D’où diable a bien pu provenir cette erreur :
- de votre amie, à qui il a paru évident qu’elle ne porterait pas de blanc le jour de son mariage ?
- de vous, à qui il a paru évident qu’on se marie en blanc en France ?
Revenons à nos développeurs de Lockheed Astronautics : il leur a également paru évident d’utiliser des livres-secondes. De la même façon qu’il a paru évident aux développeurs de la NASA d’utiliser des newtons-seconde. Il était évident au contrôle qualité que tous les logiciels utilisaient les mêmes unités. De la même façon qu’il était évident au maître d’ouvrage que les logiciels étaient interfacés en utilisant le même langage.
Stop. Voilà le problème. « Evident« .
L’évidence de l’un n’est pas l’évidence d’une autre personne. Pour être certain qu’un logiciel fonctionne, il faut le tester en conditions réelles. Si la NASA n’a pas réussi à prévenir un bug dans un programme qui a coûté 76 Bugatti Veyron à 2,5 millions de dollars / pièce, croyez-vous être à l’abri d’une telle éventualité dans vos logiciels de comptabilité, de paie, de stocks ?
La solution, ce sont les tests.
Les tests, c’est le sérum anti-bugs ?
Attention ! Les tests ne sont pas pour autant la solution miracle pour garantir l’absence totale de bugs. Certes, beaucoup d’anomalies peuvent être corrigées avec un impact raisonnable par rapport au coût et au temps de développement du projet entier.
En revanche, il y a des bugs qu’il sera rigoureusement, implacablement, inéluctablement impossible de corriger.
Lesquels ? Les bugs liés à la conception fonctionnelle du projet. Pourtant, changer une règle de fonctionnement, ça semble enfantin : couper, coller, et ce moteur de recherche qui devait permettre de retrouver des contrats par leur nom permet maintenant de rechercher sur leur contenu, non ?
Non. D’un point de vue technique, modifier une partie structurante du fonctionnement d’un projet, c’est comme dire à un architecte :
« Très bien les 6 premiers étages de bureaux que vous nous avez construits. Maintenant on souhaiterait remplacer le 2e par un parking et le 5e par un jardin intérieur. Merci ! »
Contraint et forcé, que fait le chef de chantier pour répondre à la demande ?
- Il rase le 2e étage au marteau-piqueur, en essayant de ne pas faire s’effondrer les étages supérieurs ni endommager les étages inférieurs.
- Puis il déblaie les décombres du 2e étage.
- Puis il étaie le 1er étage pour supporter les milliers de tonnes des voitures, et les milliers de tonnes de terre du jardin.
- Puis il reconstruit un parking sur le 2e étage en évitant les colonnes d’eau qui auraient dû être placées ailleurs si on avait su que ce serait un parking.
- Puis il reconstruit un jardin sur le 5e étage après avoir imperméabilisé au mieux un étage qui n’était pas conçu pour contenir de la terre et de l’eau.
Fiabilité du projet ? 0%
Risque d’anomalies ultérieures ? 100%
Gardez cette image en tête. C’est ce qui pousse tous les jours de jeunes développeurs prometteurs à fuir vers un pays ne pratiquant pas l’extradition.
Les tests techniques
Admettons-le tout de go : les tests, ce n’est pas très sexy. C’est comme relire sa copie après avoir fini sa rédaction de français au collège : il faudrait le faire, mais qui l’a déjà fait ? Peut-être une personne sur trente, et encore. Si vous avez de la chance, cette personne sur trente est dans votre équipe de développement, et les tests ont été particulièrement bien réalisés (ou du moins, ils ont été réalisés). Mais en général, les développeurs font des tests à la va-vite, et il reste des bugs.
« Les tests techniques, ce n’est pas mon problème »
C’est ce que vous pourriez vous dire naturellement. Pourtant, iriez-vous visiter un immeuble flambant neuf si on venait de vous dire :
- que l’audit de conformité n’a pas été fait
- que la sécurité incendie n’est pas passée
- ha oui, et le service des mines et carrières nous a signalé qu’il y avait probablement une caverne de 30 mètres de haut sous l’immeuble, en raison d’une vieille carrière de gypse (véridique, le sous-sol de Paris en est truffé)
Avouez que vous prendriez quand même un gros risque avec votre vie. Vous pouvez commencer à vérifier que toutes les portes de l’immeuble sont conformes à votre demande, mais avec une carrière de gypse de 30 mètres de haut sous vos pieds, ce n’est pas très sécurisant.
Il en va de même avec les tests techniques : s’ils ne sont pas faits, vous prenez un gros risque avec la vie de votre entreprise. Je ne plaisante pas : si votre ERP se met à bloquer le paiement de vos fournisseurs dans le futur à cause d’une problématique technique, il ne faudra pas longtemps pour que le marché se méfie de votre entreprise et que votre chiffre d’affaires s’effondre.
Votre projet est assis sur une base technique. Vous devez vérifier à la livraison qu’elle est fonctionnelle, et qu’elle le restera pour au moins 2 à 5 ans. Il sera trop tard pour demander des corrections dans 2 ans, lorsque votre site web mettra 30 secondes à se charger et que vous découvrirez que le contrat de maintenance avec votre prestataire a expiré, qu’il a fait faillite ou que l’anomalie concernée ne fait pas partie des cas couverts.
Une première série de tests techniques vérifie le fonctionnement du projet aux limites de son utilisation prévue :
- tests de performance : après chargement de données de test, est-ce que tous les écrans et toutes les pages se chargent à une vitesse acceptable ? Pour comprendre à quoi correspond ce test, chargez la liste des salariés de votre société dans votre tableur Excel : tout va bien. Maintenant chargez l’intégralité des données de recensement de l’INSEE dans votre tableur Excel : votre ordinateur fonctionne-t-il toujours aussi rapidement ? C’est exactement ça, les tests de performance sur un projet logiciel ou un site web.
- tests de charge : en simulant un grand nombre d’utilisateurs sur un court instant, est-ce que le site (ainsi que son serveur, sa connexion réseau, etc.) fonctionne correctement ? C’est pour une erreur de dimensionnement de la charge que le site Géoportail (Google maps à la française), lancé en grande pompe le 23 juin 2006 en présence du président français Jacques Chirac, a été inaccessible pendant une semaine : 600 personnes s’y connectaient chaque seconde, contre 100 attendus ! Incapable de répondre à la demande, le serveur ne sait plus où donner de la tête, exactement comme le serveur d’un restaurant qui est hélé par 6 clients en même temps là où le restaurateur en avait prévu 1 au maximum.
- tests de robustesse : que se passe-t-il si un élément non prévu se produit ? Par exemple, si votre site affiche l’emplacement de vos boutiques sur un fond de carte de Google Maps, et que celui-ci est inaccessible : est-ce que votre site crashe lamentablement (donc perte de clientèle potentielle, donc perte de chiffre d’affaires), ou bien vos boutiques continuent de s’afficher ? Si vous pensez être protégé par le fait que Google fonctionne toujours, c’est faux : il y a parfois des bugs, mais également des limitations (censure, etc.) dans certains pays. A vous de faire en sorte que votre site marche quoi qu’il arrive, sans dépendre d’un « ça devrait marcher ».
- tests de vulnérabilité : votre site est-il sécurisé face aux multiples menaces des pirates qui rodent dans les océans du grand Internet ? Vous pensez être immunisé ? Vous ne l’êtes pas du tout, lisez cet article sur la cybercriminalité qui fait froid dans le dos.
Bref, on passe le site au bazooka, et on voit s’il reste une page vivante à la fin de l’exercice.
La seconde série de tests techniques est la recette usine, qui vérifie le fonctionnement du site en utilisation normale :
- des tests unitaires : chaque fonction est testée individuellement. Pour faire un parallèle avec le bâtiment, c’est comme vérifier que les deux battants de la fenêtre PVC qu’on vient d’assembler s’ouvrent correctement.
- des tests d’intégration : le programme est testé après installation dans son écosystème, c’est-à-dire au sein des autres composants du système d’information (annuaire des salariés, centres de coûts, pièces de stock…). C’est comme installer sa fenêtre PVC sur le mur, puis vérifier qu’elle s’ouvre toujours et qu’il n’y a pas de fuite d’eau dans l’entourage au contact du mur.
- des tests d’homologation : les écrans et fonctionnalités principales sont vérifiés pour s’assurer qu’il n’y a pas d’erreur flagrante (page blanche, données incohérentes…). Cela revient à faire un tour dans la maison une fois terminée, et vérifier qu’il ne reste pas d’ouverture sans fenêtre, ou de mur dont les parpaings sont restés apparents.
Pour vous assurer que tous ces tests techniques ont bien été faits, votre équipe technique doit normalement vous remettre un cahiers des tests qu’elle a effectués. Pour chacun de ces tests, le résultat doit être satisfaisant.
Les tests d’acceptation ou UAT (ou user acceptance testing)
Assommant. Barbant. Casse-pieds. Fastidieux. Pesant.
Après quelques heures de tests, vous verrez, vous connaîtrez vous aussi tous les synonymes de « ennuyeux ». C’est d’ailleurs parce qu’ils sont ennuyeux que les développeurs les font en général à la va-vite. Il faut pourtant en passer par là pour éviter des crashes à 193 millions de dollars. Rappelez-vous. 76 Bugatti Veyron.
Pour faciliter les tests, il y a néanmoins des stratégies de tests faciles à mettre en oeuvre.
La première phase commence avec les tests les plus simples :
- charger chaque page ou écran sans autre action, et vérifier s’il y a une page blanche ou une erreur
- valider ensuite tous les formulaires en ne saisissant aucune valeur (valeurs vides)
- valider ensuite tous les formulaires en testant les limites de chaque champ, par exemple pour un âge testez -1 et 999999.
- valider ensuite tous les formulaires en saisissant des données d’un type autre que celles attendues, par exemple « Zorro » pour l’âge de l’utilisateur ou « 42 » pour une date de naissance.
Même avec des développeurs irréprochables, il est rare de ne pas avoir déjà trouvé des anomalies à cette étape. Notez que cette partie peut largement être automatisée.
La seconde phase doit concerner les scénarios de tests fonctionnels. Le cahier des charges détaille normalement les scénarios suivis par les utilisateurs dans le projet. Un exemple tiré de la comptabilité :
- je pré-saisis une facture future d’après un bon de commande
- puis je la reçois du fournisseur
- puis je la prends en compte
- puis je la fais valider
- puis je déclenche le paiement
Simple, non ? Oui, mais… imaginons que vous ayez recruté un nouveau comptable, qui pré-saisit la facture puis déclenche le paiement (sans réception ni validation de la facture). L’application le permet-elle ? Si c’est le cas, alors il y a une anomalie.
Ces scénarios de tests (ou « use cases » en anglais) peuvent être réalisés dès la phase de formalisation des besoins et la création du cahier des charges, puisqu’ils correspondent normalement aux processus métier. Il n’est pas trop tard pour les écrire si ce n’est pas encore fait : ils serviront pour chaque nouvelle modification du projet !
N’oubliez pas d’inclure dans ces scénarios de tests les différents profils et droits qui existent dans votre projet. L’erreur la plus courante est de tester un projet dans un profil qui donne tous les droits, par facilité. Mais si une personne doit avoir des droits plus restreints, il faut vérifier que ces restrictions sont bien mises en place. Sinon, cela revient à donner les clés de votre bureau à tout l’immeuble, y compris le stagiaire et le livreur de pizzas qui passe occasionnellement.
La troisième phase, c’est quartier libre : laissez-vous guider par votre imagination pour essayer de deviner quels cheminements dévoyés suivront vos utilisateurs. Des exemples issus de la vraie vie :
- si votre application permet une délégation de droits d’un utilisateur à un autre : essayez de déléguer vos droits à vous-même
- essayez de supprimer votre propre compte utilisateur
- etc.
Mauvaise nouvelle ! Les tests sont un processus itératif. Ce qui signifie que le processus que je viens de vous décrire va se reproduire :
- les anomalies sont débusquées par les testeurs
- puis elles sont corrigées par les développeurs
- puis les testeurs doivent confirmer leur bonne correction, et que de nouvelles anomalies n’ont pas été introduites au cours des corrections
- puis les anomalies sont corrigées par les développeurs
- etc.
Comptez au moins 3 cycles de recette avant de parvenir à une solution relativement fiable. Plus vous testez, plus l’application sera fiable, plus le logiciel coûtera cher… donc gardez en tête le principe de Pareto : éliminer 80% des bugs coûtera 20% du budget, éliminer les 20% restants coûtera 80% de plus. Il restera toujours des bugs qu’il n’est pas économique de résoudre, mais si ces bugs ne surviennent jamais (car aucun utilisateur ne suit le scénario qui permet de les générer), à quoi bon les corriger ?
Gagnez du temps avec des bugs parlants
Comparez les deux rapports ci-dessous concernant une malfaçon dans un bâtiment qui vient d’être livré :
- La porte du bureau ne marche pas !
- Dans le bâtiment B, au 7e étage, couloir de gauche, bureau du comptable adjoint : la porte est posée trop bas et ne peut pas pivoter sur ses gonds.
Quel rapport vous paraît le plus efficace, et permettra l’intervention rapide d’un menuisier ?
Adoptez la même approche dans vos tests d’une solution informatique. Au lieu de dire :
Le moteur de recherche ne marche pas !
Dites :
Dans le moteur de recherche de l’outil de gestion des factures (menu Finance > Gestion des factures > Recherche) : lorsqu’on recherche des pièces de type BK, devise EURO, des pièces d’autres devises (GBP, USD) sont également remontées. En pièce jointe une capture d’écran du problème. Il se produit uniquement dans le profil « Comptable ».
Les développeurs du monde entier se cotiseront alors pour vous offrir une peluche Bugs Bunny. Faux ? Pas totalement : les rapports de bugs lacunaires sont une cause majeure de tensions entre développeurs et métiers. Aidez-vous en aidant les développeurs : votre campagne de tests ne s’en portera que mieux.
Idéalement, mentionnez donc dans vos rapports de bugs (faits via un gestionnaire de tickets ou à défaut, un tableur):
- le numéro du bug (utile dans une conversation téléphonique)
- son statut : ouvert / en cours / résolu / rejeté / clôturé
- son auteur
- sa priorité : basse / moyenne / haute / urgente
- l’écran et fonctionnalité affectée
- le scénario pour reproduire le bug : « j’ai chargé la page, puis j’ai cliqué sur le 3e bouton, puis j’ai fait défiler la seconde liste, puis j’ai cliqué sur… »
- le comportement attendu (référençant idéalement une règle du cahier des charges)
- le comportement obtenu (le bug, donc)
- une capture d’écran pour être plus parlant
Ajoutez à cela deux autres éléments indispensables à votre campagne de tests :
- un cahier des charges, et même idéalement les spécifications fonctionnelles : car si on n’a pas les plans d’un immeuble, comment savoir s’il est normal ou non qu’il y ait par exemple une serre aux papillons dans le bureau de la directrice ? a-t-elle été demandée ou bien s’agit-il d’une erreur, pouvez-vous me le dire ?
- un environnement de qualification dédié : il doit s’agit d’un site web ou serveur totalement séparé de votre environnement de production. Pourquoi ? Car si vous voulez jeter un bâton de dynamite dans votre immeuble pour tester sa résilience, mieux vaut le faire sur un bâtiment de test, plutôt que celui où travaillent actuellement les 300 personnes occupées à générer votre chiffre d’affaires, n’est-ce pas ? C’est pareil en informatique.
- un procès-verbal de recette, qui permet de valider la livraison du projet et délivre le prestataire de ses obligations. Exactement comme pour un procès-verbal de police, il faut notifier toutes ses réserves (par exemple : la montée en charge n’a pas pu être validée et le sera dans 3 mois).
Que retenir ?
Soyez conscients d’une vérité absolue : les bugs sont inévitables.
Il faut simplement limiter le risque en réduisant l’impact possible des anomalies. Comment ?
- en formalisant les exigences et les objectifs du projet dès le début
- en vérifiant que les tests techniques ont été correctement réalisés
- en réalisant des tests de fonctionnement minutieux
Ce sont les trois clés pour éviter des coûts supplémentaires astronomiques en raison d’anomalies !
