La première application que j’ai écrite pour quelqu’un d’autre, dans le cadre de mon premier stage, a lamentablement échoué sur un test tout simple ! Je vais vous expliquer pourquoi et comment il faut tester votre application afin de vous éviter cette expérience désagréable.

Pourquoi tester ?

Un exemple vaut mieux qu’un long discours, je vais donc vous raconter le…

Crash de ma première application “pro”

Lors de mon premier stage, j’ai développé un site web en Perl/HTML permettant de mettre à jour les champs de descriptions des sites web hébergés dans la société W@W, qui a malheureusement disparu depuis. Nous étions en 1998, il n’existait pas encore de solution simple pour éditer un site web, pas de CMS (Content Management System, ou gestionnaire de contenu). Tout se faisait à la main, en HTML. Le but était de permettre à un utilisateur n’ayant aucune connaissance de HTML de pouvoir modifier les méta descriptions afin d’améliorer le référencement du site hébergé. J’ai donc créé des formulaires HTML et des scripts Perl pour implémenter cette fonctionnalité. J’ai bien sûr testé un grand nombre de fois avant de prévenir mon maitre de stage. Lui n’a fait qu’un test : il a mis n’importe quoi dans les champs de saisies, y compris des caractères complexes comme @ * $ / etc. Cela a tout simplement fait échouer violemment mon script Perl ! Il n’a pas fait cela au hasard, il savait qu’un script écrit par un débutant serait particulièrement sensible à ce genre de test. Il savait également que j’avais probablement réalisé des tests, mais uniquement d’un seul type, le test des cas nominaux ! Personnellement, j’étais très déçu. Mon code ne résistait pas à un utilisateur un peu averti.

Les apprentissages de cette expérience

Cette expérience m’a appris que les tests sont très importants. Ce sont eux qui vous permettent d’être sûr que votre code fonctionne comme vous l’avez imaginé. Car oui, nous codons tous du code qui est censé fonctionner. Mais êtes-vous bien sûr qu’il fonctionne ? Qu’il supporte tous les cas de figure ? Qu’il supporte même les utilisateurs mal intentionnés ? Car oui, les hackers utilisent ce genre de technique pour pénétrer un site. J’ai appris plus tard que je n’étais pas le seul à me laisser avoir par ce genre de saisie. Malheureusement, parfois il s’agit d’un site gouvernemental ou d’un grand groupe ☹.

Instinctivement, tester un site web ou une application semble facile. Bien tester est beaucoup plus dur et demande de l’organisation et de la rigueur. Tout comme le développement logiciel en général d’ailleurs.

Les tests manuels

Maintenant que nous avons vu pourquoi tester, regardons comment faire des tests manuellement. Nous pourrons ensuite étudier comment et pourquoi les automatiser. Les tests les plus simples auxquels nous pensons sont généralement ce que l’on appelle les cas nominaux. C’est-à-dire les cas normaux du fonctionnement de l’application.

Les cas nominaux

Ces tests couvrent l’usage normal de l’application. Ce sont les tests les plus simples à trouver. Veillez tout de même à bien tester toutes les combinaisons possibles. Il faut vérifier toutes les branches de vos expressions conditionnelles et tous les cas de vos boucles, la sortie standard, les sorties anticipées, les risques de dépassements. Par exemple, un ou deux tests nominaux suffisent à vérifier qu’une addition fonctionne. Par contre, si vous avez une calculatrice qui prend en charge plusieurs opérations en laissant le choix à l’utilisateur entre addition, multiplication, soustraction et division… Il faut tester chacun de ces cas de manière spécifiques.

Les cas aux limites

Tout est limité en informatique, il faut donc vérifier que notre code se comporte bien dans ces cas-là. Nous restons tout de même dans le cadre d’un usage normal, mais aux valeurs très grandes ou très petites. Par exemple, vous acceptez des entiers. Il faut savoir qu’un entier en informatique est limité, ce n’est pas comme en mathématique où les entiers sont infinis. L’informatique fonctionne avec des objets bien réels, des processeurs, de la mémoire vive, des disques durs. Il n’est pas possible de stocker des entiers ayant une infinité de valeurs possibles. Pas avec les entiers simples que nous manipulons dans les langages de programmation (il existe des librairies dédiées aux calculs nécessitant des entiers très grands, mais ce n’est pas le sujet). Une chaîne de caractère est également limitée. Toujours pour les mêmes raisons, elle aura une taille maximale.

Prenez ces valeurs limites, et testez votre application. Prenez même des valeurs ayant dépassé la limite, est-ce que l’application affiche un message d’erreur correct ? Dans le cas de la calculatrice, est-ce que celle-ci réagis bien si je mets un signe % au lieu du * ? Ou un point au lieu d’une virgule ? Un utilisateur peut très bien saisir cela par erreur, ou en cherchant une fonctionnalité non documentée.

Les cas inattendus

Ici, nous sortons du cadre d’un usage normal. C’est exactement l’exemple que je donnais en introduction. Vous cherchez tout simplement à faire échouer votre code. Vous n’êtes plus dans le cadre d’un utilisateur honnête qui se trompe. Ce test permet de vérifier que même un utilisateur mal intentionné, ou très désorienté, ne pourra pas planter votre application. Vous vérifiez, du coup, qu’il ne pourra pas s’en servir pour pénétrer dans le système d’information et voler des données, ou faire pire. N’est-ce pas utile de faire ce genre de test ?

Écrire et suivre un cahier de tests

Surtout, ne faites pas cela à la volée, vous allez oublier de nombreux cas, voire même tester un périmètre différent d’un test sur l’autre. Vous pourriez vous dire que ce dernier point n’est pas trop grave tant que vous trouvez des bugs et que vous les corrigez, c’est en partie vrai. Mais qu’en est-il de la dernière séance de test ? Comment serez-vous sûr d’avoir tout testé ?

Pour être sûr, il faut lister tous les tests à faire dans un cahier de test. Vous pouvez utiliser un logiciel dédié comme HP Quality Center ALM, IBM Rational Quality Manager ou Microsoft Test Manager. Je connais mal ces logiciels, sauf peut-être Quality Center pour m’y être frotté sur des gros projets.

Il existe une solution du “pauvre” qui fonctionne très bien, je m’en suis servi à plusieurs reprises. J’ai même eu des félicitations à ce sujet. Cette solution toute simple et qui impressionne facilement, c’est : un tableur ! Prenez celui que vous voulez, Microsoft Excel, Calc d’Open Office, ou tout simplement Google Sheets, tous feront l’affaire.

Vos cas de tests dans un tableur

Il vous suffit de lister tous les cas de tests, un cas par ligne, avec une colonne « identifiant », une colonne « description » et une colonne « étapes à suivre ». Petite astuce, si un cas de test est trop long, c’est probablement qu’il faut en faire plusieurs ! Vous pouvez préciser ici les données à utiliser pour les tests. Parfois il faut obligatoirement faire le test avec un utilisateur précis, ou un groupe d’utilisateurs, ou en utilisant tel objet de l’application, précisez-le ! Si ce n’est pas important, je l’indique aussi, cela laisse toute liberté au testeur de changer d’une fois sur l’autre et donc d’élargir les cas testés, on peut avoir d’heureuses surprises.

Ensuite vous créez autant de feuilles que d’exécution de votre suite de test. Dans la première colonne vous indiquez la référence vers le cas de test que vous être en train de suivre, puis le statut, OK ou KO. Attention, pas d’état intermédiaire, c’est soit réussi, soit échoué. Nous verrons ci-dessous comment catégoriser les problèmes rencontrés. Ajouter ensuite des colonnes « commentaires », « documents annexes » contenant des liens HTTP vers un fichier détaillé ou des copies d’écran.

Vous pouvez enrichir de toutes les infos que vous jugerez utiles ! Personnellement, je n’ai pas fait un seul cahier de test qui ressemblait exactement à l’autre. Adaptez à vos besoins !

Caractérisez vos bugs

Dans une autre feuille vous pourrez lister les bugs découverts. Bien sûr, ajouter une référence sur la ligne de test qui a permis de le découvrir, cela vous aidera sûrement. Ensuite je vous propose de caractériser les bugs selon trois axes :

• La sévérité : triviale, mineure, majeure, critique, bloquante. Adaptez cette liste selon vos besoins ou utilisez la liste existante dans votre équipe.
• L’impact : % approximatif d’utilisateurs touchés par ce bug. Parfois, un écran est restreint à seulement 5% des utilisateurs. C’est intéressant de l’avoir en tête.
• La priorité : haute, moyenne, basse. La priorité est utile pour clarifier des situations complexes. Par exemple un bug bloquant, qui gêne un seul utilisateur, donc avec un faible impact, mais sur une action quotidienne critique. La priorité sera haute. Comme précédemment, ce ne sont que des suggestions basées sur ce qui a fonctionné pour moi, adaptez à vos besoins !

Les tests automatiques

Tester, c’est bien. Mais bien tester, c’est long. Du coup nous le faisons plus rarement, voire pire, nous ne faisons qu’une partie de notre plan de test.

De plus, avec le temps, la suite de test va forcément augmenter. Imaginez que vous deviez implémenter 3 nouvelles fonctionnalités dans la semaine et que vous ne faites que des tests manuels :

• À la première fonctionnalité, vous avez besoin de 2 minutes de tests manuels. Là, je suis assez optimiste avec 2 minutes, car si vous suivez tout dans votre cahier de tests en même temps, cela vous prendre un peu plus. Mais admettons, cela ne fait que 2 minutes !
• Lorsque vous livrez la deuxième fonctionnalité, vous avez aussi 2 minutes de tests manuels + les 2 minutes des tests précédents. Eh, oui. Qui vous dit ou vous garantit que la nouvelle fonctionnalité n’a pas impacté la première ? Vous auriez tort de croire que tout est isolé et indépendant. Au contraire, le code ressemble plus à un gigantesque plat de spaghettis. Pour être sûr de ne pas avoir de régression, la seule méthode est de toujours tout tester.
• Lorsque vous livrez votre troisième fonctionnalité, vous en avez pour 6 minutes de tests !

Imaginons un peu comment cela peut évoluer sur la durée :
6 minutes de tests au bout d’une semaine,
12 min en 2 semaines,
24 min en un mois,
48 min en deux mois !

Vous pouvez imaginer la suite tout seul, et rappelez-vous bien que nous étions optimistes. Notez bien également que ces calculs sont valables si vous travaillez seul. S’il y a d’autres développeurs, il faut multiplier le temps de test par le nombre de développeurs car l’implémentation des fonctionnalités avance plus vite !

Comment faire pour tout tester ? Et tester le plus fréquemment possible ?

Automatiser !

 

Qu’est-ce qu’un test automatique ?

Test manuel : test réalisé à la main en utilisant l’application d’une certaine manière pour vérifier qu’elle donne le résultat attendu.

Test automatique : morceau de code écrit pour faire comme un test manuel, à savoir demander quelque chose à l’application et vérifier le résultat obtenu. Vu qu’il s’agit d’un code, nous avons quelques avantages :

• L’exécution du test est beaucoup plus rapide (un utilisateur humain est généralement plus lent qu’un bout de code)
• Il est possible de réexécuter le test à l’identique autant de fois que nécessaire, ce qui est un énorme avantage.
• Il est possible de tester une toute petite partie de l’application même s’il n’y a pas d’interface utilisateur, ce qu’un test manuel ne peut pas faire. Cela permet d’aller infiniment plus vite (je n’exagère pas du tout sur le infiniment) et de tester vraiment toutes les conditions.

 

Sur le papier, les tests automatiques semblent vraiment plus intéressants. Pourtant, un certain nombre de développeurs hésite encore à y passer. En fait, ils ont tout de même un gros défaut : il faut écrire et maintenir le code de test. En gros, vous avez le code de l’application à écrire + le code de test de l’application. Cela signifie que vous écrivez 2 fois plus de code ! Pour certains, c’est beaucoup trop. En plus, parfois, vous avez des bugs dans le code de votre test. Eh oui, cela reste du code, écrit par un être humain, donc peut-être buggé .

C’est malgré tout vital, et surtout, je ne connais pas un développeur qui soit revenu en arrière. Attention, je vous vois venir, parmi ceux ayant appris à coder des tests automatiques correctement, je n’en connais aucun qui ait abandonné.

Cet article est fait pour tous les langages, je vous laisse donc voir comment écrire des tests automatisés dans votre langage. Sachez que j’en parle dans les articles d’initiation :

• Débuter en VBA sous Excel
• Et débuter la programmation en Java.

 

TDD / BDD: Test Driven Development / Behavior Driven Development

Un petit aparté rapide pour vous parler de TDD. C’est une manière de programmer qui permet vraiment d’augmenter votre efficacité. Cela ne consiste pas juste à faire les tests en premier comme je l’entends trop souvent. Non, c’est vraiment beaucoup trop réducteur. Il s’agit de piloter votre développement par les tests. Cela nécessiterait un article entier, je vous laisse donc découvrir par vous-même. Je vous recommande de vous formez-vous à TDD et/ou BDD, puis de vous forcer à l’appliquer correctement pendant 1 mois au moins. Je suis sûr que vous allez continuer .

 

Et après cet article ?

Nous avons seulement abordé les tests permettant de vérifier si l’application répondait au besoin. Vous pouvez les appeler tests fonctionnels ou tests d’acceptation. Il existe d’autres types de tests intéressants que je n’ai pas traité ici, notamment les tests de charges et les tests de compatibilité.

Que faire pour profiter de cet article au maximum ?

Je vous propose déjà, si ce n’est déjà fait, de mettre en pratique le cahier de test. Même si ce n’est que sur une petite fonctionnalité, vous devriez rapidement voir des gains en termes de qualité. De plus, sachez qu’au plus vite nous trouvons un bug au plus il est facile de le corriger. Et, du coup, il coûte moins cher.

Ensuite, passez aux tests automatisés. Mettez-les en pratique sur une durée suffisamment longue, 1 mois minimum, pour dépasser les premiers obstacles. Je parie que vous ne reviendrez pas en arrière !

 

Crédits photo

• Photo by Darius Bashar on Unsplash
• Photo by Nicolas Thomas on Unsplash
• UFREE / freestocks-org-73101-unsplash /