Introduction:
Généralement pour toute application déjà en production il existe une campagne de tests de régressions. Ces tests visent à s’assurer que s’il y a des régressions sur le produit (malheureusement il est impossible d’assurer une absence totale de régression !) elles sont minimes (car non couvertes par les tests).
Sur une application mail on a facilement 200-300 tests de régression, sur une application web également. Le temps d’exécution et d’analyse est donc long et prend facilement une semaine (voir plus). Ces tests ne peuvent donc pas être exécutés tous les jours hors lors du développement d’un produit ou de nouvelles fonctionnalités sur une application il y a des livraisons quasiment tous les jours ! On arrive alors à une des limites de cet outil que sont les tests de régression, il nous faut donc un autre outil !
Cet outil « miracle », c’est les tests vitaux. Je dis outil « miracle » car je suis un fervent défenseur de ces tests qui sont pour moi les tests les plus importants. S’il faut faire attention à des tests c’est cela, s’il faut avoir des tests fiables, c’est cela, s’il faut automatiser des tests c’est cela !
Mais les tests vitaux c’est quoi ?
Définition:
Le principe des tests vitaux est simple. Avoir un jeu de tests très succincts (une couverture des méthodes peut suffire), rapide à exécuter et à analyser. Le but c’est de les faire tourner quotidiennement et/ou à chaque livraison d’un développeur. Cela permet de s’assurer que les fonctions « vitales » de l’application sont toujours en état de fonctionner.
Prenons l’exemple d’une application mail. Lors de mon post sur les couvertures de tests j’avais défini les 12 fonctionnalités suivantes :
– Authentification
– Affichage liste des mails
– Affichage des mails
– Affichage liste des dossiers
– Afficher le contenu d’un dossier
– Ecrire un mail
– Répondre à un mail
– Transférer un mail
– Déplacer un mail
– Supprimer un mail
– enregistrer un brouillon
– Gérer les options de messagerie
12 tests vitaux peuvent donc suffire, il sélectionne généralement le plus souvent pour chaque fonctionnalité. Si le cas sur le transfert est en échec on peut donc considérer que la fonction transfert ne fonctionne plus.
Utilisation des tests vitaux:
Comme dit précédemment les tests vitaux sont fiables, rapides d’exécution et d’analyse. Il faut donc les tourner le plus fréquemment possible (normalement une campagne de test vitaux doit avoir une durée d’exécution inférieure à 30 minutes !), de préférence à chaque livraison ce qui permet de savoir directement quelle livraison a « cassé » un des tests.
Ce « bug » détecté très tôt est plus simple et moins coûteux à corriger car on en connait la cause. C’est là tout l’intérêt de ces tests.
Ces tests peuvent aussi être utilisés lorsque l’on n’a pas assez de temps pour faire une campagne de régression. On effectue alors ces tests puis des tests exploratoires ciblés sur les fonctionnalités les plus impactées.
Fournir ces tests aux développeurs est également un plus cela peut permettre d’éviter des livraisons à refaire.
Petite comparaison tests vitaux – tests de régression :
Rien n’est mieux qu’une bonne comparaison à la vie de tous les jours pour voir en quoi les « outils » tests de régression et tests vitaux sont complémentaires (mais aussi pourquoi je trouve les tests vitaux encore plus important).
A noter : il faut faire attention avec l’exemple employé en fonction des interlocuteurs. L’exemple que je vais prendre ici n’est pas le premier que j’ai utilisé. Il faut toujours faire attention à la communication !
Ici je vais prendre un exemple de bricoleur !
J’ai 2 outils, un marteau et une perceuse.
– Si je veux faire un trou dans mon mur pour accrocher un tableau je vais évidemment prendre un marteau et un clou.
Utiliser la perceuse fonctionnerait également mais pour cela il me faudrait la sortir de sa boite, la brancher à une rallonge elle-même branchée à l’électricité, mettre le foret approprié percer puis tout re-ranger. Cela me prendrait donc beaucoup plus de temps que le marteau pour un résultat identique.
– Si je veux monter une grande bibliothèque ou étagère accrochée au mur, il faudra par contre que je fasse beaucoup plus de trous, surement plus gros (car le poids sera plus important), ici l’utilisation de la perceuse est nettement plus appropriée !
Le marteau est donc plus un outil de tous les jours et la perceuse un outil plus occasionnel. On peut ici comparer les tests vitaux à un marteau et la perceuse aux tests de régressions. Et je ne sais pas pour vous, autant j’ai pu vivre quelques années sans perceuse autant j’ai toujours eu besoin d’un marteau !
Conclusion :
Les tests vitaux sont un outil très important pour un logiciel. Malheureusement c’est un outil trop souvent ignoré ou non utilisé. Je ne compte plus ne nombre de fois où l’on m’a dit : « pourquoi ne faire tourner que 10 ou 20 tests quand on peut en faire tourner 100 ou 200 ? ». La réponse est simple et j’espère que cet article vous a convaincu : La rapidité d’exécution et donc la possibilité d’une utilisation beaucoup plus fréquente.
Cela permet de trouver des bugs beaucoup plus tôt dans le développement du logiciel et donc de réduire le coût et le temps passer sur la correction de ces bugs.
Les tests vitaux sont simples à mettre en place, peu coûteux (généralement une partie des tests de régression) et peuvent engendrer un fort gain de temps et d’argent. C’est pourquoi, de mon point de vue, les tests vitaux, c’est vital !
