Tester (1) : la stratégie de test

Tester, c'est bien ! Encore faut-il le faire intelligemment. C'est un très vaste sujet et je le traiterai donc en plusieurs articles. Voici pour commencer une présentation des grandes lignes de notre stratégie de test.

Tests manuels, tests automatisés

Nos applications sont testées manuellement à deux reprises : une première série de tests manuels est réalisée en interne puis, l'application est livrée en préproduction et une seconde série de tests est cette fois réalisée par le client. C'est seulement quand l'ensemble de ces tests sont validés que l'application peut être livrée en production.

Ces tests manuels ont l'avantage de s'approcher au mieux du comportement des utilisateurs finaux. Ils ont cependant quelques inconvénients :

• Ils valident le fonctionnement de l'application seulement à un moment précis.
• Un unique test peut échouer pour de multiples raisons.
• Ils sont chronophages.

Ces difficultés peuvent être en grande partie résolues par des tests automatisés.

Pourquoi écrire des tests automatisés ?

1 - Valider le fonctionnement d'un programme

Normalement un développeur doit livrer chaque fragment de programme accompagné d'une série de tests automatisés. Ces tests tiennent lieu de preuve que le programme réalise bien ce qu'on attend de lui.

• Dans un premier temps, cela permet au développeur d'assumer le programme qu'il a écrit.
• Le projet garde une trace de l'objectif visé au moment de l'écriture du programme.
• Dans le cadre d'une intégration continue, on peut rejouer ces tests automatiquement à chaque modification du programme pour s'assurer qu'aucun bug n'a été introduit (non-régression).

En mettant comme condition au déploiement la réussite de tous les tests automatisés, on s'assure que l'application fonctionne "correctement" sans aucune vérification manuelle.

Bien sûr, "correctement" ne veux pas forcément dire "parfaitement". Le niveau de fonctionnement dépend de la quantité et de la qualité des tests...

2 - Assurer l'élimination définitive d'un bug

Les tests couvrent le cas nominal et les cas limites attendus mais des cas non prévus peuvent survenir et éventuellement provoquer des bugs qui ne sont détectés que lors des tests manuels ou lors de l'utilisation de l'application en production. Dans ce cas, le programme doit être corrigé et le correctif livré sera accompagné d'une série de tests automatisés. Ces tests seront ajoutés aux tests existants dans l'intégration continue afin que le bug soit définitivement éliminé.

Grâce à ces nouveaux tests, le projet garde la mémoire de ses erreurs pour ne pas les reproduire par la suite.

3 - Documenter le programme

Ce n'est pas le but principal des tests automatisés mais cela reste un bénéfice : un test est toujours plus facile à lire que le code qu'il teste. En effet, un test consiste le plus souvent en une succession d'actions simples tandis le code peut contenir des boucles, des conditions, des formules de calcul qui le rendent plus difficile à comprendre.

Nous pratiquons une revue de code systématique, c'est à dire que le code écrit par un développeur est toujours relu par un collègue. Dans ce cadre, les tests permettent au relecteur d'aborder un peu plus facilement le code qu'il doit relire.

La couverture de test : Pourquoi arrêter d'écrire des tests ?

Si je veux m'assurer qu'une application fonctionne tout le temps sans aucun bug, il faut que je teste tous les cas d'usage possibles. Non seulement c'est impossible (il faudrait par exemple tester chaque formulaire avec toutes les valeurs possibles des différents champs) mais certains de ces tests seraient presque totalement inutiles. De plus, le temps passé à écrire des tests est du temps qu'on ne passe pas à ajouter des fonctionnalités à l'application.

Tout est donc une question d'équilibre entre le temps nécessaire à l'écriture des tests et le gain de robustesse que ceux-ci apportent à l'application.

Comment évaluer le gain de robustesse ? Deux éléments principaux sont à prendre en compte :

• Les fonctionnalités critiques qui ne doivent jamais provoquer d'erreur. (par exemple celles mettant en jeu des données personnelles sensibles, des transactions financières...). Il faut tester de façon intensive les calculs et les autorisations d'accès.
• Les fonctionnalités les plus utilisées : en testant prioritairement celles-ci, on minimise les occurrences de bugs en production. Comme disait ma grand-mère : Il vaut mieux 10 bugs sur une fonctionnalité utilisée une fois par mois qu'un seul bug sur une fonctionnalité utilisée 100 fois par jour...

Tester en pratique

Dans un prochain article, je vous expliquerai comment nous mettons en œuvre ces principes : Quels types de tests nous écrivons, quelle couverture de test nous appliquons aux différentes parties de nos applications. Je vous présenterai aussi Behat, la bibliothèque PHP avec laquelle nous écrivons une grande partie de nos tests.