Les différences entre test unitaire, fonctionnel et de non régression

Publié le : 1 janvier 2024

Tester est incontournable, tant et si bien que le terme “tests” est utilisé à tort et à travers. Test fonctionnel, de non régression, de montée en charge… Il devient difficile d’y voir clair et, surtout, d’identifier les actions à mener pour tester un logiciel ou une application.

On distingue 3 « grandes familles » :

• Tests unitaires ; pour tester le bon fonctionnement d’une fonction isolée,
• Test fonctionnel ; pour tester l’enchaînement de différentes fonctionnalités et vérifier qu’elles sont conformes aux besoins exprimés par les métiers,
• Test de non régression ; pour vérifier que la version en cours n’a pas généré de régression en regard de la version précédente.

Dans cet article nous allons voir comment différencier ces 3 familles et, surtout, découvrir leurs bénéfices pour votre projet de développement.

Tests unitaires : par qui et quels sont les intérêts ?

Il existe pléthore de définitions sur internet mais on retiendra les synonymes proposés par l’ISTQB pour s’en faire une idée plus précise : “tests de composants” et “tests de module”. En bref, ils permettent de s’assurer que le comportement d’une fonction est correct. Pour cela il faut tester le composant de façon isolée ou avec des bouchons appropriés.

Imaginez un site e-commerce de vente de chaussure. Vous testeriez que l’ajout d’un produit à la “Liste de souhait” soit bien pris en compte. Vous testeriez également que vous pouvez retirer un produit qui s’y trouve. Pour cela vous allez faire 2 tests unitaires.

Pour les mener à bien, ce sont les développeurs qui sont les mieux placés. Cela leur permet de contrôler immédiatement si leur code fonctionne comme attendu.
Les avantages d’un test unitaire sont multiples :

• C’est un retour immédiat sur le développement : ça marche ou ça ne marche pas,
• Puisqu’il est isolé, il est facile de remonter à l’origine du dysfonctionnement (forte probabilité d’une erreur dans le code),
• Il évite d’accumuler les erreurs techniques et permet de gagner du temps (beaucoup de temps) sur la suite du projet.

Non régression : par qui et quels sont les intérêts ?

Si la notion de tests unitaires et de test fonctionnel est claire pour vous, le non regression testing n’en est que la suite logique. Ces processus permettent de valider que la mise en production d’une nouvelle version n’aura pas d’effet de bord sur des fonctionnalités existantes. Ils répondent à la question suivante : si je mets en ligne cette nouvelle version, toutes celles en place continueront-elles à fonctionner ?

Vérifier la non régression permet de comparer une version n à une version n-1, -2, -n …

Plus une régression est identifiée tôt, plus il sera facile de remonter à la racine du dysfonctionnement.

Les avantages sont multiples :

• Valider une version n par rapport à une version n-1,
• Créer l’historique des versions,
• Augmenter considérablement le niveau de qualité de vos livrables via l’automatisation,
• Le Graal : en mettant en place un processus d’intégration continue, vous détectez l’éventuelle régression pour une prise en charge immédiate par votre équipe de développement.

Ainsi, vous évitez d’accumuler une « dette de régression » qui ne sera visible, qu’en partie, à la porte de la nouvelle mise en production. Dans ce cas, inéluctablement, votre version comportera des régressions : catastrophique pour l’image et le business !

Le match : non régression sur mobile en interne VS externalisation ?

Votre application mobile est un enjeu dans votre stratégie d’acquisition ou de fidélisation et la moindre régression peut avoir des conséquences non négligeables sur votre image, vos services et/ou vos ventes ? Nul doute que vous avez mis ou allez mettre en place des tests de non régression automatisés et dignes de ce nom pour parer aux risques. La première question qui va se poser : faut-il les réaliser avec les ressources et compétences internes ou les externaliser ?

I. Prérequis

La qualité et fiabilité de l’automatisation reposent sur les scénarii et les parcours clés qui vont être simulés, voire idéalement reproduits. Ces derniers doivent être fidèles au comportement des mobinautes, aux systèmes d’exploitation et équipements utilisés. L’objectif est de valider que l’utilisateur pourra accéder à l’application, se connecter, télécharger un document, exécuter une requête … tout cela depuis son téléphone préféré et une version déterminée.

Il est évident que les tests vont tenir compte d’un certain ROI. Nous entendons par là qu’il n’est pas pertinent d’effectuer des tests sur TOUS les terminaux (iPhone, Galaxy S …) et sur TOUS les systèmes d’exploitation (Apple, Android …). Vos datas d’utilisation vous permettront d’aligner vos tests sur les usages de vos mobinautes. Il y a fort à parier que 3 à 4 terminaux utilisés sur 1 à 2 systèmes d’exploitation couvriront 90% des usages.

Le but est de présenter une application avec 0 dysfonctionnement à vos utilisateurs et ce avant soumission aux différents stores.

II. Le match de l’automatisation : en interne VS externe ?

Si pour vous la question se pose, c’est que vous disposez des compétences nécessaires en interne pour :

• Configurer et maintenir l’ordinateur qui va émuler voire reproduire les tests
• Auditer, installer et configurer le logiciel d’automatisation (open source ou sous licence)
• Mettre en place un cahier de tests (on vous aiguille ici)
• Exécuter, générer et valoriser les résultats
• Maintenir les terminaux et systèmes d’exploitation
• Faire évoluer la couverture de tests

À partir de là, le tableau ci-dessous vous intéresse :

III. En interne

On ne vous le souhaite pas, mais les projets d’automatisation en interne sont régulièrement sous-évalués. Mettez à plat toutes les actions à conduire et affectez en face les compétences nécessaires. Validez systématiquement avec les équipes concernées leurs disponibilités et leurs compétences sur le sujet.
Le choix du logiciel est déterminant :

• Open source : on pourra difficilement trouver meilleur rapport qualité-prix, car ils sont gratuits, mais cela va demander beaucoup de temps et des compétences pour les configurer et reproduire les scénarii.
• Sous licence : opérationnel plus rapidement, mais qui dit licence dit coût d’acquisition et souvent intervention d’un consultant pour former les équipes à son utilisation. Avec un peu de recul, vous faites un premier pas vers l’externalisation.

En interne il faut aussi anticiper l’investissement en temps nécessaire au maintien opérationnel :

• Maintenance de la performance en actualisant la couverture de tests en fonction de l’évolution de l’application.
• Maintenance technique : acquisition des nouveaux terminaux pour suivre le comportement des mobinautes, maintenance des systèmes d’exploitation sur les terminaux, maintenance des machines d’émulation, maintenance du logiciel de test …

Contrairement aux idées reçues, automatiser la vérification de la non régression en interne demande beaucoup de temps à l’initialisation et d’une manière conséquente ensuite. Soyez vigilant(e) pour que cela n’impacte pas la qualité et fiabilité des résultats.

IV. En externe

C’est sûr, vous créez une dépendance avec prestataire. Soyez donc très exigeant au moment de sa sélection ! Calculez également le ROI avant d’externaliser. C’est ce dernier qui va vous permettre de déterminer le moment ou l’externalisation devient la plus pertinente.

Car, oui, à un moment où à un autre, l’externalisation sera incontournable pour conserver un ROI positif.

En externalisant vous gagnez en temps et en compétences car votre prestataire :

• Supporte en mutualisant les coûts d’acquisition des infrastructures techniques et des compétences humaines.
• Maintient les terminaux et systèmes d’exploitation.
• Dispose d’une expertise et vous permet une mise en œuvre plus rapide.
• Acquière de la compétence sur votre métier et vous conseillera.

Toutefois, externaliser ne vous déchargera pas de tout, il vous appartiendra toujours d’exprimer vos besoins en fonction du comportement de vos utilisateurs ! Eh oui, n’oublions pas que c’est l’utilisateur qui est au cœur de toutes ces réflexions.

Lors de votre voyage dans le monde du test vous avez commencé ou commencerez par des variantes manuelles et aléatoires. Puis, pour suivre l’évolution de votre application et de son utilisation, vous automatiserez tout ou partie de vos processus.

Peut-être en interne dans un premier temps, si les enjeux ne sont pas cruciaux ni chronophages. Mais lorsqu’ils nécessiteront des investissements trop importants (humain et technique) l’externalisation sera alors la solution !

Test fonctionnel : par qui et quels sont les intérêts ?

Dans le prolongement des tests unitaires, le test fonctionnel valide l’enchaînement d’une suite de fonctionnalités. Est-ce que l’application marche dans son ensemble ? Pour répondre à cette question, le test fonctionnel s’appuie sur le cahier des charges là où les tests unitaires ont une approche purement technique.

Il faut partir d’un scénario, conçu pour reproduire le parcours attendu d’un utilisateur. Ce scénario intégrera une suite de jeux de données. Un test fonctionnel est conduit, en général, par les équipes de testeurs conjointement avec la MOA.

Le test fonctionnel doit s’incrémenter parallèlement au développement. Plus les tests fonctionnels sont effectués tôt dans le cycle de développement et plus la qualité du livrable sera élevée. Pour assurer la fiabilité dans le temps du logiciel, le patrimoine de test fonctionnel pourra être utilisé et automatisé pour mettre en place des tests de non régression.

Les objectifs du test fonctionnel sont multiples :

• Valider un bon fonctionnement des parcours utilisateurs,
• Intégrer des jeux de données,
• Garantir la qualité du livrable,
• Valider que le logiciel est conforme aux expressions de besoins.

3 méthodes pour maintenir en condition opérationnelle (MCO) des scénarios de test fonctionnel UI.

Nous souhaitions partager avec vous un des prérequis de l’automatisation, grâce aux différents retours d’expérience de partenaires et de clients : la création et le maintien en condition opérationnelle (MCO) des scénarios. Le modèle le plus apte à détecter les défauts, car au plus proche du besoin de l’utilisateur, est aussi celui qui est le plus complexe à créer et à maintenir : le test fonctionnel UI.

Rappels sur la notion de test fonctionnel

Pour mémoire, le test fonctionnel permet de valider que les fonctionnalités livrées sur le logiciel correspondent aux attentes du cahier des charges. Il garantit que les cas d’usage (workflow) peuvent être déroulés et que les résultats obtenus sont cohérents. Le test fonctionnel est conduit par les équipes MOA et/ou par les équipes métiers.

Par exemple, sur un site e-commerce, un test fonctionnel permettra de vérifier qu’il est possible de créer un compte utilisateur, de mettre au panier un article et de le payer.

Le test fonctionnel peut être complété par des tests non-fonctionnels qui permettent de vérifier que le logiciel fonctionnera correctement en conditions de production (tests de performance, d’utilisabilité, de fiabilité, …).

Lorsque la couverture en test unitaire est importante, la nécessité d’avoir une couverture en test fonctionnel UI est présente, mais peut être optimisée sur des parcours spécifiques.

Si elle est faible ou inexistante, le test fonctionnel UI doit devenir le « filet de protection » de l’application.
Dans les processus automatisés, la première phase est la création et la maintenance des scénarios, tout comme pour des variantes manuelles ou semi-automatisées.

La différence fondamentale est qu’en automatisant votre couverture sera bien plus importante et de fait bien plus chronophage à maintenir. C’est là que, fréquemment, plus on livre et moins on maintient les scénarios permettant de vérifier la non régression.

Erreur souvent fatale, car inévitablement des effets de bord, des régressions, … sont introduits au fur et à mesure que de nouvelles (ou adaptations) de fonctionnalités sont introduites dans les versions livrées.

On entend par scénario la définition des parcours (scénarios / mots-clés / jeux de données) et de leur maintenance au fil des itérations.

Quelles sont les trois méthodes à déployer ?

Voici les différents types de test fonctionnel avec lesquels vous pouvez procéder :

• Méthode « Capture + Replay » avec des données statiques ou variabilisées. Cela consiste à enregistrer un parcours utilisateur en le jouant dans le contexte d’exécution. Les actions manuelles sont enregistrées pour être reproduites ensuite. Les données enregistrées peuvent rester statiques ou être variabilisées. Cette méthode est simple pour la création rapide du test fonctionnel, mais complexe à maintenir au cours des itérations.
• Méthode structurée basée sur des scripts. Cela consiste à scripter les parcours et utiliser une sémantique dédiée qui décrit les actions. Cela est très puissant et modulable, mais attention d’éviter les langages de script propriétaires ! La maintenance demande à l’automaticien de l’expérience et des compétences dédiées.
• Méthode par « mots-clés ». Cela consiste à découpler la complexité de l’exécution et celle des notions fonctionnelles à tester. L’automaticien peut générer des fonctions élémentaires avec une des méthodes précédentes et les rendre disponibles sous la forme de mots-clés (potentiellement avec des variables). Les mots-clés auront une sémantique fonctionnelle. Il suffit alors d’enchaîner les mots-clés pour créer le parcours du test fonctionnel. Si le contexte technique évolue (mise à jour du navigateur qui demande une adaptation de script par exemple), l’automaticien modifie le script, mais l’ensemble reste inchangé (enchaînement des mots-clés).

Il existe bien entendu des outils qui prennent en charge toutes les méthodes et qui peuvent les combiner (exemple : la « capture » génère un script utilisable avec des mots-clés). Pour identifier la méthode qui vous conviendra le mieux il faut systématiquement peser les « pour » et les « contre ».

Dans une stratégie d’intégration du test fonctionnel au sein d’un patrimoine, pour optimiser et améliorer la qualité des livrables, il est préférable de vous baser sur des scripts. La méthode qui vous permettra d’atteindre vos objectifs est avant tout celle que vous appréhenderez le mieux !

Pour conclure.

Vous savez désormais que lorsque l’on parle de tests il convient d’en préciser la typologie. Il n’y a qu’avec cette granularité que vous pourrez augmenter considérablement la qualité de vos livrables.
L’un ne va pas sans les autres et inversement. C’est pour cela qu’il est indispensable de penser et de mettre en place une stratégie en parallèle de la définition du cahier des charges du projet. C’est la garantie d’un projet qui aboutit et dans de bonnes conditions !