Tests de régression, votre type de test

Vous est-il déjà arrivé qu’avec la sortie d’une nouvelle version de votre application préférée, certaines fonctionnalités ont disparu ? Ou est-ce que ça marche, mais avec un comportement inattendu ? Ou tout simplement tombent d’une manière éblouissante ?

Aujourd’hui, nous verrons quels sont les tests possibles qui garantissent d’éviter tout ce panorama, les tests de régression.

Vous ne savez pas encore ce que sont les tests de régression ?

Il existe de nombreuses normes pour effectuer les tests de logiciels et vous pourriez être surpris de vous dire qu’il existe même un travail de documentation des tests de logiciels.

*Je laisse ici quelques secondes d’intervalle pour vous surprendre.

Et il n’y a pas que cela, mon ami, il y a des organismes internationaux qui se consacrent à l’étude et à la formulation de recommandations générales. 

*Par exemple, les normes ISO/IEC 29119 posent, grosso modo, ce que devraient être les processus de test de logiciels. 

Depuis plusieurs décennies, je suis fasciné par tous ces processus, y compris la supervision des dispositifs industriels, à tel point que je suis fidèle à eux qu’ils finissent toujours par me traiter de perfectionniste, moi… ! 

Automobiles, climatiseurs, centrales électriques qui refroidissent les maisons en étés chauds…

Pour cette raison, les tests de logiciels doivent être adaptés au travail lui-même effectué par ces programmes :

• Un programme pour piloter automatiquement un avion ? Soyez assuré qu’il sera soumis à des tests très approfondis.
• Un logiciel bancaire ? Sera testé et aura une section spéciale pour les tests du logiciel d’audit correspondant.
• Un logiciel de jeu vidéo ? Personne ne mourra si quelque chose ne va pas, dans le pire des cas les joueurs achètent le jeu de la concurrence, mais qui veut cela, compagnon gamer ?

C’est pourquoi, ici même, je voudrais vous expliquer, de la manière la plus simple possible, ce que sont ces processus et tests.

Tests unitaires, réapprobation et réanalyse

Voyons rapidement quelques concepts clés :

• Tests unitaires :

Contrairement au siècle dernier, nous avons une meilleure offre matérielle, qui permet d’effectuer tests automatisés, complets et rapides, qui peuvent être réutilisés encore et encore (et qui s’exécutent indépendamment) pour le code source lui-même.

Une virgule, quelques parenthèses peuvent être mal ou bien placées selon la version du langage de programmation utilisé (par exemple, voir en langage Python la commande print). Pour cela, des tests unitaires sont effectués.

• Processus de réapprobation :  

Lorsqu’un logiciel est modifié, quelle qu’en soit la raison, il faut réapprouver tous les points qui ont été travaillés.

Ces tests sont toujours effectués manuellement.

• Processus de réanalyse :

Si le point précédent est suspendu, le logiciel sera renvoyé au département de développement en précisant quels sont ses dysfonctionnements.

Une fois qu’ils auront été corrigés et livrés, ils seront réanalysés et, si tout va bien, ils seront réapprouvés.

Assez de préambules ! Qu’est-ce qu’un test de régression ?

Les tests de régression sont totalement différents des tests précédents. 

Ils sont ainsi nommés parce qu’ils partent du principe que si un logiciel fonctionne comme prévu, et qu’il est altéré, que ce soit en interne ou en externe, il faut s’assurer qu’il retourne à son état de stabilité antérieur.

*Quand nous disons qu’un logiciel est stable et fonctionne comme il a été conçu, nous parlons de tout dans son ensemble, de manière générale. 

Par conséquent, un test de régression doit être appliqué à chacun des composants. 

Comme vous pouvez l’imaginer, il s’agit d’une tâche titanesque, mais si elle est bien accomplie, elle contribuera à améliorer l’expérience utilisateur et à gagner la confiance du client.

Quand effectuer un test de régression ?

Lorsqu’une nouvelle fonctionnalité est ajoutée à un logiciel, après les tests de réapprobation et de réanalyse, un test de régression doit être effectué avant la livraison au client. 

Et aussi lorsque :

• L’exigence change ou a été mal comprise par les développeurs et alors une fonctionnalité doit être « réparée ».
• Le logiciel a subi un test de régression, il est livré et fonctionne très bien jusqu’à ce que quelque chose change.*Par exemple, l’utilisateur a mis à jour le système d’exploitation ou a migré vers une version plus récente : le programme subit une défaillance qui doit être corrigée.
• Le logiciel fait son travail, mais au fil du temps, les données s’accumulent et il faut de plus en plus de temps pour exécuter les mêmes tâches. Une optimisation du code source est alors nécessaire et tout le cycle de test est à nouveau répété.
• Selon les pays, il y aura de nouvelles législations et le logiciel devra se conformer aux dispositions légales. Dans ce cas, le logiciel est refacturé et un test de régression sera nécessaire avant d’être à nouveau légalisé.
• Nous avons besoin de porter le logiciel à un autre système d’exploitation (par exemple de GNU/Linux® à MS Windows®) pour pouvoir le vendre à plus de clients. Ici, les mêmes tests de régression seront également copiés et adaptés au nouvel environnement.

Quelques inconvénients de ce type de test de régression

Tout n’est pas beau : 

• Le moindre changement doit être testé dans un test de régression.

Même sans modification du code source du logiciel.

• Comme la surveillance fonctionne, il y aura des fonctionnalités simples et certaines plus complexes, ce qui peut être un problème si vous avez une limite de temps.

Par exemple, la supervision d’une page Web peut prendre des millisecondes s’il s’agit de faire un ping ou d’obtenir une valeur concise, mais dans le cas de la surveillance de l’expérience utilisateur il faudra enregistrer chacun des tests à effectuer.

• Une fois que vous aurez automatisé les tests de régression, il est possible que vous deviez effectuer un test manuel, ce qui entraînera plus de temps et d’argent.

Ressources

Bibliothèque de plugins Pandora FMS

Forum officiel Pandora FMS

Je veux en savoir plus !

Notre Essai