Les tests : un processus coûteux mais essentiel

Les tests sont essentiels dans tous les domaines : les voitures, le jeu vidéo, le cinéma, etc. On teste presque tout pour s’assurer que le résultat est conforme à l’envie de départ. Le résultat du test peut être différent de l’attendu de départ à cause de simples erreurs, mais aussi parce que l’on découvre une utilisation totalement non prévue.

Chez Vigicorp, quand nous construisons un site web, une application métier ou une appli mobile, nous testons le produit « dans tous les sens ». D’ailleurs, on vous parlera de notre testeur dans un billet à venir.

Quels sont les différents processus de tests ? 

Il existe deux manières de conduire des tests.

Tests manuels et tests automatiques 

Pour tester une application, il y a deux solutions possibles : les tests manuels et les tests automatiques. Les premiers prennent nécessairement plus de temps, car nous simulons manuellement les interactions entre une fonctionnalité et un utilisateur. Pour faire simple, on clique partout. Ça peut paraître rapide à faire, mais il faut vous imaginer que, ces tests, vous devrez les refaire à chaque modification du code pour vous assurer de ne rien avoir cassé.

Pour éviter de perdre trop de temps, on a mis au point des tests automatisés, écrits à partir du code source, qui permettent de tester rapidement un site web entier. Cependant, même si ces tests sont rapides à exécuter, les écrire prend du temps, car il faut envisager l’intégralité des scénarios pour que les tests soient pertinents. De plus, il faut les faire évoluer au même titre que le code d’une application pour qu’ils restent efficaces.

Les tests en boîte noire et les tests en boîte blanche 

Les tests peuvent être réalisés sous deux approches : une utilisateur et l’autre développeur.

L’approche utilisateur 

Sans se préoccuper de comment ça fonctionne, cette approche consiste à se poser la question : est-ce que ça marche ? Pour cela, nous simulons plusieurs parcours utilisateur et nous nous assurons que les requêtes envoyées au logiciel renvoient les bonnes réponses. Par exemple, si je mets un filtre sur Amazon, est-ce que j’ai les bons résultats ? Il n’y a pas besoin d’avoir des connaissances poussées en programmation, il suffit juste de savoir utiliser une souris et un clavier.

Cependant cette approche ne permet pas de savoir ce qui est à l’origine du problème, c’est pourquoi on les appelle les tests en « boîte noire ».

L’approche développeur 

Cette fois, nous voulons savoir comment l’application web fonctionne lorsqu’une requête est envoyée. L’objectif est d’identifier les potentielles erreurs, mais aussi les points d’optimisation possibles. En effet, même si quelque chose marche, est-ce que ça ne pourrait pas mieux marcher ? Vous l’aurez compris, pour effectuer ces tests, il faut des compétences poussées en programmation. Comme le testeur a une vue et une compréhension claire sur le code, on appelle cette méthode les tests en « boîte blanche ».

Le code coverage : faut-il tout tester ? 

Le code coverage, c’est le pourcentage de code source utilisé lorsqu’une suite de tests est lancée. Pour faire simple, c’est le pourcentage de chemins possibles qui ont été simulés. Par exemple, si, à la requête A le logiciel peut répondre B, C et D, mais que mon test ne simule que C et D, mon code coverage sera de 66%. En principe, plus ce pourcentage est élevé, moins le logiciel a de chances de contenir des bugs non détectés. Mais faut-il pour autant tout tester ? C’est la grande question.

Un gros investissement 

Si tester son application web ou mobile apparaît comme une obligation, c’est un processus long qui comporte plusieurs contraintes pour les entreprises. Pour commencer, le temps. Dans une agence web, tout est question de temps. Le développement d’un site web est un processus long soumis à de nombreux aléas. Si on veut tester le code, il faut prévoir un temps pour ça dans le contrat, ce qui implique une hausse du prix de vente difficile à déterminer et à justifier car il est compliqué d’évaluer avec précision le retour sur investissement des tests.

Et en vérité, il n’existe pas de lien réel entre « couverture du code » et « qualité du logiciel », car la couverture du code n’offre qu’une vision quantitative du test.

La qualité du test 

Imaginez que pour que votre voiture soit considérée comme une voiture de qualité vous deviez tester 50% de tout ce qui constitue la voiture. L’important pour une voiture, c’est qu’elle roule pourtant, je peux atteindre ces 50% sans même avoir vérifié cette fonctionnalité.

C’est grossier mais ça montre les limites d’une vision quantitative des tests. Voilà pourquoi il faut trouver un arbitrage dans les tests. S’ils prennent du temps et donc de l’argent, il faut tester intelligemment. Ne pas forcément viser une haute couverture de code, mais tester les éléments les plus importants de l’application : la sécurité, les fonctionnalités principales. Dans le cas d’une voiture :

• roule-t-elle ? ?
• la ceinture est-elle homologuée ?
• les airbags fonctionnent-ils ?
• etc

Mieux coder, en pensant test 

Pour tester une application avec des tests automatisés, il faut que le code soit bien structuré. De ce fait, penser à la phase de test durant le développement (méthode TDD : Test Driven Development) permet d’améliorer la structure du code. C’est comme à l’école, une fois que vous avez compris que vos dissertations ont pour objectif d’être lues, vous améliorez directement votre rédaction pour faciliter la lecture. Vous passez d’une démarche où l’objectif était de dire ce que vous avez à dire à une démarche dans laquelle vous devez faire comprendre ce que vous avez à dire. Alors vous écrivez mieux, vous séparez bien vos parties, vous mettez en valeur vos titres, etc.

Dans le développement, c’est la même chose, développer en pensant test, c’est développer pour être lu et surtout gagner du temps, car si vous n’arrivez pas à écrire votre test parce qu’un code est mal structuré, alors vous devrez le refaire comme l’a dit un grand homme :