Définition ISTQB : test d‘un composant ou système au niveau spécification ou implémentation sans exécution de ce logiciel (p.ex. : revues ou analyse statique du code)
En fait les tests statiques correspondent à l’ensemble des tests qui ne nécessitent pas l’utilisation ou l’exécution du logiciel. Les tests statiques peuvent être utilisés à toutes les étapes d’un cycle en V :
Le principal « type » de test statique c’est les « revues ».
On a différents types de revues :
· Les revues des documents tels que les expressions de besoins, les cahiers des charges, les plans de test…
· Les revues de codes (pour le code et/ou les tests automatisés)
· Les revues de tests
Mais il existe aussi d’autres types de test statiques qui peuvent être exécutés avec des outils, avec ces outils on peut tester :
· La qualité du code (éclipse vérifie que la syntaxe est correcte, Sonar…)
· La couverture des tests (avec un ALM= Application Lifecycle Management)
· …
Bref, on peut avoir des tests statiques à tous les niveaux de n’importe quel projet. Mais quel est leur intérêt ?
Intérêt des tests statiques
Les tests statiques permettent de repérer des erreurs ou des failles avant d’avoir le logiciel ou d’avoir à l’utiliser. Cela permet donc de trouver des bugs très rapidement et donc de pouvoir les corriger très rapidement et à moindre coût.
Pour rappel, 70% des bugs viennent des spécifications, un très grand nombre de produit finaux ne correspondent pas à ce qui est attendu par le client car le besoin de ce dernier a mal été exprimé et/ou compris. Les revues permettent de limiter ces erreurs et l’insatisfaction client, tout cela pour un coût relativement faible : une réunion entre le client et un représentant de l’équipe afin de clarifier certains points sujets à interprétation ne coûte quasiment rien sur un projet par contre cela peut permettre d’éviter de faire un produit qui ne répond pas aux besoins.
De même les revues de codes et de tests sont très importantes, des failles sont souvent trouvées. Je ne compte plus le nombre de fois où j’ai perdu du temps à ouvrir des bugs alors que le problème venait du test qui comportait une erreur…
Si une vérification avait été faite sur le test avant son exécution j’aurai économisé :
· Au moins 1 exécution de mon cas de test
· L’analyse du test en échec
· L’ouverture d’un bug
· L’envoi du bug à un développeur
· L’analyse du développeur
· Le retour du développeur disant : « Working as Designed »
· La vérification du retour du développeur
Toutes ces étapes auraient pu être évitées avec une revue des tests (la mise à jour du cas n’est pas « économisée » dans ma liste précédente car dans tous les cas elle est faite à un moment).
On voit tout de suite le retour sur investissement du test statique dans ce cas.
Implémenter les tests statiques
Comme souvent il faut savoir être pragmatique. Je suis toujours en faveur des tests statiques, par contre selon les besoins (et moyens) du projet différents processus peuvent être mis en place.
Dans un grand nombre de cas une simple revue informelle est possible. Il est également possible avec GIT d’avoir une revue obligatoire par un membre de l’équipe afin de mettre sur la branche voulue du code ou même des spécifications et des tests). Enfin la tenue de réunions beaucoup plus formelles est également possible. Encore une fois cela va dépendre du contexte.
La formalité des revues dépend également de la revue en elle-même. Une revue de test peut être informelle alors que les revues de code seront formelles…
A noter : en SCRUM, certains processus de tests statiques sont inclus dans les cérémonies (la cérémonie de planning permet de faire une revue des User Stories).
Conclusion :
Les tests statiques peuvent être implémentés à toutes les phases du projet. Ils peuvent permettre d’économiser beaucoup d’argent et de temps et ont donc un très bon retour sur investissement. Ces tests ne sont pas à négliger car ils sont faciles et peu onéreux à mettre en place (ils peuvent juste être informels et ne nécessite généralement que peu de ressources), de plus, ils peuvent améliorer grandement la qualité finale du produit.
Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
ROI: Return On Investment (Retour sur investissement)
Autre article : https://www.linkedin.com/pulse/understanding-benefits-static-testing-ruslan-desyatnikov?trk=mp-reader-card
La taverne du testeur 
merci pour toutes ces précisions
je commence à peine à m’intéresser au test logiciel dans le cadre d’une reconversion professionnelle et je suis vraiment un bleu en informatique. je potasse à fond le syllabus ISTQB mais lorsque l’on n’a pas la culture informatique alors cela devient vite difficile ! Donc merci encore pour vos éclaircissements!
J’aimeJ’aime
Merci pour ce retour!
Vous trouverez dans la taverne de nombreux articles abordant des sujets liés à l’ISTQB et qui pourront vous aider.
J’aimeJ’aime