le-blog-b-acceptance.1.jpg

Blog B/Acceptance

Mutation Testing. Mais qui gardera les gardiens ?

Posté par Le Lab B/Acceptance le 02 mars 2018.

Automatiser est-il le meilleur moyen d'assurer la stabilité de vos systèmes ?
C'est en tous cas la solution que j'ai retenue jusqu'à maintenant, et vu l'essor des outils d'automatisation, il y a de forte chance pour que je ne sois pas le seul.

Néanmoins des questions reviennent souvent.
Les tests automatisés sont-ils efficaces ? Est-ce que je peux totalement arrêter de tester manuellement mon système ?

Si le code est couvert, ça fonctionnera ! (ou pas...)

Usuellement, les tests sont évalués au regard de la couverture du code.
Mais cet indicateur, même s'il ne doit pas être totalement remis en question, est insuffisant et ne prévient pas complétement des régressions.

Des personnes comme Richard Lipton travaillent sur ce sujet depuis les années 1970, et ont accouché de nouvelles techniques de test : les tests de mutationDes outils tels que Humbug sont issus de ces recherches. Ils provoquent des mutations dans le code afin de donner naissance à des mutants. L'enjeu pour les tests unitaires est alors de traquer ces mutants.
L'efficacité de la batterie de tests unitaires est évaluée au regard du nombre de mutants ayant réussi à s'échapper.

L'article qui a intéressé le Lab B/Acceptance cette semaine : "Mutation Testing – Vérifiez la qualité de vos tests unitaires". Il est signé Robin Graillon et il vous explique comment un outil comme Humbug vous permettra d'éprouver vos tests unitaires.

Qu'en est-il pour les niveaux supérieurs d'intégration (tests de service et tests bout-en-bout) ?

La couverture de code est encore moins pertinente pour les tests bout-en-bout.

D'une part, l'indicateur peut-être compliqué à obtenir et consolider pour l'ensem

ble des couches d'un système d'information.
D'autre part, ce qui m'intéresse en bout-en-bout c'est la couverture fonctionnelle et pas uniquement la couverture du code.

Qu'entendons-nous par couverture fonctionnelle ?

Une des interprétations de la couverture fonctionnelle est la multiplication du nombre de parcours des processus métiers (acheter sur un site en ligne) par le nombre de cas de données (un client fidèle & un produit disponible & avec une promotion sur le panier se terminant demain).

Autant dire qu'identifier ainsi ce que représente 100% de couverture fonctionnelle relève de l'impossible dans mes projets quotidiens.

Pourrions-nous élargir cette technique de mutation du code vers le système d'information en introduisant délibérément des bugs ?
Quelles pourront être les mutations à introduire dans les services, dans les données, dans l'infrastructure ?
Voilà un sujet qu'il faudra méditer.

 

Catégories : automatisation

Bienvenue sur le blog de B/Acceptance, spécialiste du test/qualité logicielle en France.

Son objectif :

  • Diffuser et faire découvrir des bonnes pratiques et des outils du test fonctionnel, test automatisé et test de performance
  • Identifier les tendances : automatisation des tests, Intégration continue, Agile Testing, etc
  • Echanger autour du test digital : Web desktop, Web mobile, App

Lire nos articles

Inscrivez-vous au blog