Et voilà, après quelques heures de transpiration euh d’enthousiasme ininterrompu, vous avez un projet qui fonctionne. Vous avez probablement dû, même si ça vous a fendu le coeur, laisser quelques petites choses de côté, mais votre projet se tient, et il tourne !
C’est fini alors ? 
En fait non, pas tout à fait. Si votre projet tourne, c’est que vous avez fait une bonne partie du boulot, et corrigé les bugs trouvés sur votre chemin. Seulement votre projet est interactif, la personne qui va l’utiliser ne va pas forcément le faire comme vous. Il va donc falloir essayer de débusquer les utilisations non prévues qui pourraient faire bugger votre programme / objet numérique.
Votre programme se comporte-t-il comme prévu ?
Super, mon robot se balade dans le labyrinthe, mais si je réduis la largeur des couloirs, ou leur longueur ça marche toujours ? On peut choisir la vitesse du personnage dans mon programme, mais si quelqu’un demande une vitesse de 100, est-ce que ça fait tout planter ou pas ?
D’abord il faut définir ce qui doit marcher ou pas. Par exemple si le couloir est moins large que le robot, forcément ça ne va pas marcher (mais votre robot ne doit pas ni s'abîmer ni tout casser non plus). Et il est utile de consulter ce qu’on a dit dans la fiche de conception, voire de l’enrichir avec de nouvelles informations. Pour la vitesse par exemple, il faut d’abord dire à l’utilisatrice les valeurs acceptables, et puis décider ce qu’on fait si elle ne respecte pas ce qui est demandé (on arrête le jeu et elle a perdu ? on met la vitesse à la valeur max autorisée ? on lui demande d’entrer une autre valeur jusqu’à ce qu’elle soit convenable ?).
On va donc reprendre la fiche de conception et essayer de voir si, quels que soient les choix qu’on fait en tant qu’utilisateur, le programme se comporte comme prévu. Si un personnage doit attraper une clé et une pièce dans l’ordre qu’il veut, il faut tester les deux cas : la pièce en premier ou la clé en premier. Si on peut répondre oui ou non à une question, pareil on va tester les deux cas. De manière générale, on va essayer de tester/couvrir le maximum de comportements possibles, afin d’augmenter d’autant ses chances de trouver un bug caché. On parle de “taux de couverture” pour une série de tests, pour évaluer le pourcentage de comportements qui ont été pris en compte dans les tests.
De même il ne faut pas qu’en faisant n’importe quoi l’utilisateur réussisse à contourner le jeu. Si par exemple on choisit une vitesse négative du personnage et qu’il gagne en franchissant une ligne d’arrivée en marche arrière, ce n’est pas ce que l’on voulait, et il faut le tester.
Testez les cas de bords
Comme on n’a évidemment pas le temps de “couvrir” tous les cas, il va falloir bien choisir ceux qu’on teste, de préférence ceux qui ont le plus de “chances” de planter. Pour ça nous avons des candidats de choix : ce qu’on appelle les “cas de bord”.
Imaginez que mon programme Scratch imite un ascenseur qui va de y = -100 (rez-de-chaussée) à y = 100 (premier étage) dans lequel l’utilisateur a deux boutons : monter et descendre. Quand on appuie sur monter, le lutin monte de 10 en 10 pixels jusqu’à la position 100. Quand on appuie sur descendre il le fait de 10 en 10 jusqu’à la position -100
.
Eh oui, le problème arrive quand on demande de descendre et qu’on est en bas (ou on demande de monter et on est en haut). Il commence par descendre (et donc perforer le sol au fond de la cage d’ascenseur) puis il teste s’il est arrivé, ce qui est trop tard car il a déjà creusé son trou jusqu’à presque sortir de l’écran.
L’idée est que quand on a une variable qui peut prendre des valeurs dans un ensemble fini, les valeurs extrêmes ont plus de chances de provoquer un bug que les autres.
Imaginons que je réalise un programme Scratch pour faire une pile de maximum 4 chats avec deux boutons :
le bouton “Ajouter” ajoute un chat sur la tête du précédent
le bouton “Enlever” fait disparaître le chat le plus haut
Dans ce programme, je vais vouloir tester en particulier ce qu’il se passe quand j’ajoute le premier chat (il n’y a pas de chat précédent pour le mettre sur sa tête), quand je clique sur “Ajouter” et qu’il y a déjà 4 chats, ou encore quand je clique sur Enlever et qu’il n’y a pas de chat à l’écran.
Faire et défaire, est-ce bien nécessaire ?
C’est bien beau, je corrige mes bugs au fur et à mesure que je les trouve, mais comment savoir si je n’en crée pas de nouveaux… ou si je ne retombe pas sur les anciens ?
Une solution pour s’en protéger est de noter les bugs qu’on a déjà vus et les tests qui permettent de les détecter, pour vérifier de temps en temps qu’ils ne sont pas revenus. Pour des logiciels importants, quand la sécurité des utilisateurs ou d’autres enjeux économiques sont dans la balance, les équipes de développement mettent en place des “tests de régression”, qui sont lancés régulièrement après chaque modification (ajout de fonctionnalité, correction de bug) pour vérifier qu’on n’a rien cassé en modifiant quelque chose. Qu’on n’a pas fait marche arrière en quelque sorte.
Et si je veux tester le niveau 12, je dois vraiment re-gagner les niveaux 1 à 11 ?
Heureusement que non, sinon il serait impossible de réaliser des jeux difficiles qu’on ne pourrait pas tester jusqu’au bout. Et pour ça il y a une solution utilisée par les développeurs pros : introduire dans son programme des “cheat codes”, ou codes de triche, qui permettent d’obtenir immédiatement un avantage non négligeable, comme récupérer des vies supplémentaires, ou passer au niveau suivant, ou même directement à un niveau plus difficile. C’est très utile pour tester un programme en zappant un bout, ou pour réussir à passer une étape difficile. Libre à vous de les enlever une fois les tests terminés, ou de les laisser pour les joueurs malins qui les trouveraient (mais bon dans un code Scratch les choses ne sont pas bien cachées, alors pas forcément besoin d‘être très malin pour les trouver).
Pour un robot, l’équivalent du cheat code est souvent manuel : on met sa main devant le robot pour qu’il la détecte, ou on l’attrape pour le reposer un peu plus loin, ou encore on enlève un obstacle un instant pour le laisser passer. Mais l’idée est la même : si le robot met 5 minutes pour arriver au bout du labyrinthe et si vous avez juste changé la fin, vous n’avez pas forcément envie de patienter 5 minutes à chaque test.
Échangez vos projets
Un très bon moyen de tester efficacement son projet, c’est de le faire faire par quelqu’un d’autre, d’avoir un regard extérieur. Quand on a le nez dans le guidon, c’est difficile de voir les choses objectivement et d’avoir un oeil critique. Je vous invite donc, une fois que votre projet est finalisé, ou même quand vous avez une version intermédiaire un peu stable, de passer la main à quelqu’un d’autre. Il va peut-être tester les choses autrement que vous et tomber sur un bug qui vous avait échappé. Il va même vous apporter bien plus que ça…
Un oeil extérieur peut vous dire qu’il ne comprend pas les consignes, qu’appuyer en même temps sur les touches A, B et X pour faire monter la fusée ce n’est pas super pratique, ou que c’est dommage de ne pas pouvoir annuler une étape de construction tant qu’on n’a pas validé. En bref il peut vous permettre d’enrichir votre projet, ou faire naître en vous de nouvelles idées. Vous avez tout à y gagner.
Et une fois les modifications faites, n’hésitez pas à retourner vers celle ou celui qui vous a aidé, pour savoir si les consignes sont plus compréhensibles, la combinaison de touches plus pratique ou la fonction d’annulation conforme à ce qu’elle/il attendait.
Le bénéfice n’est pas uniquement dans un seul sens. Vous allez y gagner vous aussi. Le thème n’a rien à voir ? Vous faites un simulateur météo et lui un jeu vidéo où l’on répare les fuites dans un toît ? Peu importe : la façon de programmer, d'interagir avec l’utilisateur, de réaliser le fond d’écran, tout peut être source d’inspiration.
Alors échangez et enrichissez-vous des retours et des projets des autres, invitez les jeunes que vous accompagnez à faire de même, car tant que les remarques sont constructives et faites avec bienveillance, tout le monde y gagne.
Et voilà, votre projet est terminé. Bravo ! Je vous invite maintenant à regarder tout le chemin parcouru et ce que vous avez appris en cours de route. Quand vous aurez repris votre souffle, allez découvrir dans le prochain chapitre une manière originale, dite “agile”, de gérer un projet.
