L'automatisation à 100 % des tests est peut-être souhaitable, mais est-elle pratique ?

Par Jonny Steiner, responsable marketing produit

 

Si je pouvais mettre la main sur une machine à remonter le temps, ou même sur des jumelles temporelles (un moyen magique de voir à travers le temps que je viens d'inventer), je ferais bien des choses avec. Pour cet article, cependant, j'aimerais utiliser mes jumelles temporelles pour observer l'avenir. Plus précisément, j'aimerais voir si nous atteindrons un jour une automatisation à 100 % des tests continus.

Des tests 100 % automatisés sont peut-être impossibles.

C'est un objectif partagé par tous. Automatiser intégralement les tests continus est le rêve de tout membre d'une équipe QA et de test. Cependant, cela représente un véritable défi. D'une part, certains codes sont trop complexes pour permettre l'écriture de tests automatisés. D'autre part, certains codes ne sont pas suffisamment importants pour justifier des tests automatisés. L'idée est qu'une approche de l'automatisation des tests basée sur les risques permet de se concentrer sur les parties les plus importantes d'un logiciel donné.

Certains experts conseillent d'abandonner l'objectif d'une automatisation à 100 %. Selon eux, le processus de développement logiciel, en constante évolution, ne permet pas une automatisation complète. Ils estiment qu'il faut privilégier le retour sur investissement et ce qui satisfera les dirigeants et les parties prenantes.

What If?

Imaginons qu'il soit possible d'automatiser 100 % de vos tests continus. Certains signes indiquent que des organisations s'y essaient déjà. Avec l'essor du développement sans code et des solutions de tests autonomes, les bases sont posées pour un avenir où une application sera développée puis soumise à un processus de tests entièrement automatisé. La seule intervention humaine consisterait à relancer chaque exécution de tests lorsqu'une nouvelle version est prête ou lorsqu'un défaut est corrigé.

L'avantage serait de pouvoir accélérer encore davantage les mises en production tout en éliminant les bogues dès le début du processus, sans intervention humaine. Cependant, comme nous le verrons, les tests automatisés créent de la valeur, mais pas toujours de la manière attendue.

La « valeur » de l’automatisation des tests

Le processus de test automatisé se déroule comme suit : les tests sont exécutés à partir d'un point de départ, d'une modification et d'un résultat attendu. Une fois l'exécution d'un test terminée, l'automatisation a fonctionné, mais la fonctionnalité testée n'est pas encore fonctionnelle. Elle ne le sera qu'après l'exécution des vérifications. La valeur ajoutée réside dans le processus de test, de correction et de nouveau test. Ce processus permet d'obtenir des instructions claires pour corriger les erreurs.

Il est important de comprendre que lorsque des contrôles automatisés sont créés, que l'exécution initiale des tests est terminée, que des modifications sont mises en œuvre et que les tests sont réexécutés, ces derniers détectent alors des défauts lorsque le résultat attendu est incorrect.

Dans le monde des tests continus, il existe un vieil adage : « Une seule modification logicielle transforme l'automatisation des tests en détection des changements. »

L'automatisation, à l'origine de tous vos problèmes

En clair, les tests continus peuvent engendrer de nouvelles difficultés. Dès qu'une modification est apportée à l'application en développement, la suite de tests automatisés devient obsolète. La maintenance des tests, souvent négligée, est pourtant essentielle. Certaines organisations rencontrent des problèmes liés à un manque de supervision de la maintenance des tests existants et à la suppression des tests obsolètes, ce qui entraîne une dette technique liée aux tests.

La couverture des tests est également essentielle dans les tests automatisés. Chaque scénario doit être couvert, sinon un test « réussi » pourrait ne pas être aussi précis qu'il n'y paraît. Certes, vous avez peut-être réussi 100 % de vos tests, mais qu'en est-il des scénarios non couverts ? Ils ne seront pas pris en compte.

Se pose ensuite la question des tests non concluants. Tous ces cas doivent faire l'objet d'une enquête. Ce qui complique encore la situation, c'est que parfois, les tests échouent pour des raisons environnementales et non techniques. Dans un monde où chaque minute compte, les faux négatifs sont un véritable fléau.

Il faut également tenir compte des échecs de tests, car chacun d'eux nécessite une investigation. Certains tests donnent des « faux négatifs », par exemple un test qui expire pour une raison quelconque liée à un problème environnemental. Cela représente une perte de temps.

Le dernier défi de l'automatisation des tests réside dans le fait que ces derniers ne sont pas autonomes. Ils suivent le parcours prédéfini et leur fonction première. Or, ce n'est pas ainsi que les humains interagissent avec les applications. Nous sommes distraits, notre attention se détourne et il nous arrive de cliquer sur des éléments inappropriés. Un test automatisé ne couvre que les comportements présélectionnés par l'utilisateur.

Quel niveau d'automatisation est suffisant ?

Des dirigeants d'entreprise aux développeurs et aux testeurs, chacun a constamment des idées à tester et à explorer lorsqu'il utilise ou navigue dans ses applications. On peut se contenter d'un seul essai pour vérifier le bon fonctionnement. Ce qu'il ne faut surtout pas faire, et que personne ne devrait faire, c'est développer un test pour chaque petit scénario.

Nous n'en sommes pas encore au stade où il suffit de fournir des exigences à nos outils de test et d'attendre les résultats. Cependant, nous sommes au point où les testeurs souhaitent pouvoir exécuter leurs tests en un clic et obtenir les résultats. Si l'on parle d'une automatisation complète de nos tests, cela signifierait qu'en cas de réussite, le logiciel pourrait être déployé directement en production sans analyse supplémentaire.

La bonne nouvelle, c'est que je viens de décrire les tests de régression automatisés. Cela exclut les tests de performance et de sécurité, mais signifie qu'une application peut être déployée en production une fois que le test a été effectué de manière isolée et qu'il a été réussi.

Vivre avec la vérité

Il est donc possible que l'automatisation à 100 % des tests ne soit pas envisageable. C'est une bonne idée, certes, mais pas la plus pratique. Il y aura toujours du code trop complexe pour être testé automatiquement, et parfois difficile à lire, mais il arrive aussi qu'une portion de code ne soit pas suffisamment importante pour justifier une automatisation. L'approche basée sur les risques que je préconise ici se concentre sur les éléments logiciels les plus critiques.

Il est peut-être préférable de raisonner en termes de retour sur investissement. Réfléchissez au niveau de couverture dont votre entreprise a réellement besoin. Sondez vos dirigeants et cadres supérieurs pour connaître leur tolérance au risque concernant le logiciel en cours de développement.

N'oubliez pas que tous les bugs ne sont pas identiques et, par conséquent, tous les tests n'ont pas besoin d'être automatisés.