Quelles sont les différences entre tests fonctionnels et TNR ?

Dans le monde passionnant et incontournable des tests logiciels, on définit les différents types en fonction des usages. Sous quelles formes se présentent ces déclinaisons ? Qu’est-ce qu’un test fonctionnel ? Qu’est-ce qu’un test de non régression ? Quels sont leurs objectifs et, surtout, quels sont les bénéfices pour votre application ou pour votre logiciel ?

Nous allons tenter d’apporter une réponse à ces questions.

Les tests logiciels, un vaste domaine

Il existe deux grands types de tests logiciels :

• Statiques : ils ne nécessitent pas le lancement du logiciel testé. Il s’agit le plus généralement de revues de documentation, de planning, de code.
• Dynamiques : ils nécessitent d’exécuter une partie ou tout le code du logiciel testé pour s’assurer qu’il réponde correctement aux besoins exprimés. Ils sont utilisés à plusieurs étapes de la phase de développement : pour tester les composants, l’intégration, le système, l’acceptation.

Nous nous concentrerons sur les tests dynamiques et plus particulièrement ceux dits « fonctionnels » : pour les systèmes et l’acceptation.

Les tests fonctionnels permettent de valider que les fonctionnalités livrées sur le logiciel correspondent aux attentes du cahier des charges. Ils garantissent que les cas d’usage (workflow) peuvent être déroulés et que les résultats obtenus sont cohérents. Ils sont conduits par les équipes MOA ou directement par les équipes métiers.

Par exemple, un test fonctionnel permettra de vérifier que sur un site e-commerce :

• Il est possible de créer un compte utilisateur,
• De mettre au panier un article,
• De le payer.

Les tests fonctionnels peuvent être complétés par des non-fonctionnels. Ces derniers permettent de vérifier que le logiciel fonctionnera correctement en conditions de production (tester la performance, l’utilisabilité, la fiabilité, …)

Autre exemple, un tir de charge nous permettra de vérifier que le site répond toujours correctement lorsque des milliers de personnes effectuent simultanément le même parcours sur le site.

Toutes ces variantes permettent de détecter un maximum de défaillances au plus tôt durant le cycle de développement.

Pour assurer la robustesse du logiciel sur du long terme, chaque test décrit ci-dessus doit être réutilisé et idéalement automatisé afin d’être transformé en test de non régression.

Les tests de non-régression

Un test de non régression permet de valider que la mise en ligne d’une nouvelle fonctionnalité sur un logiciel n’impactera pas les fonctions déjà existantes. Les tests fonctionnels auront bien validé que la nouvelle fonction est opérationnelle mais c’est le test de non régression qui validera que cette dernière n’impacte pas les autres fonctionnalités du logiciel.

Le test de non régression est déployé sur un environnement de recette et doit vérifier au minimum que les fonctionnalités principales ou « critiques » du logiciel sont toujours disponibles après la livraison de nouveaux développements.

Ils permettent de réduire les risques projet, de mieux cibler et estimer les impacts des nouveaux développements ou d’une nouvelle infrastructure sur le comportement du logiciel testé.

L’objectif est d’identifier le plus tôt possible d’éventuelles régressions et, dans ce cas, l’automatisation des cas de tests prend tout son sens.

Il est pertinent de reprendre, de consolider et d’automatiser les cas de tests fonctionnels et non-fonctionnels préalablement utilisés lors des phases de développement afin de les convertir en test de non régression.

Les résultats effectués durant la phase d’implémentation d’une fonctionnalité pourront servir de référence en cas d’anomalie ou de dégradation du temps de réponse sur une version.

En mettant en place une couverture de tests automatisés, il est conseillé de définir lesquels feront partie d’un « socle critique » sur les fonctionnalités principales. Ceci vous permettra plus rapidement, en cas de délais restreints, d’assurer la couverture de tests minimale sur les fonctionnalités critiques de votre système.

Plus une défaillance est identifiée tôt, plus elle est facile à corriger. En suivant rigoureusement ces différentes étapes, vous minimisez les risques.

Identifier les 4 moments clés où l’automatisation des tests de non régression devient pertinente

Bon nombre peuvent être mis en place et conduits manuellement. Il n’est pas nécessaire d’automatiser les tâches si vos mises en productions, publications sur les stores, restent épisodiques. Cela va de soi dans un certain nombre de types de tests : test de non régression ou de montée en charge par exemple. Les variantes pour assurer la fiabilité de vos applicatifs rentrent toujours sous la contrainte du ROI.

Que vous coûte réellement une série générée manuellement ? Quelle est la marge d’erreur que vous êtes prêts à tolérer dans le cadre d’une campagne de tests de non régression ? Autant de questions auxquelles il n’est pas évident d’apporter une réponse claire et précise. Pour vous aider dans votre décision, voici les 4 moments clés où l’automatisation des tests de non régression devient pertinente.

1 – La fréquence

Élémentaire ! La fréquence du test de non régression est un critère qui va naturellement vous amener à vous poser la question de l’automatisation. Pour mettre en place et conduire un test de non régression une fois par an, il y a fort à parier que dans 9 cas sur 10 une campagne de test de non régression manuelle répondra à vos besoins. Toutefois, il se peut que les caractéristiques de la campagne imposent une automatisation même ponctuelle.

À contrario, lorsque la fréquence est de plus en plus rapprochée, l’automatisation peut devenir une vraie alternative, voire s’imposer naturellement par exemple en développement Agile.

2 – Quelle couverture ?

Pour tenir compte des différentes évolutions : fonctionnelles, technologiques, des navigateurs utilisés par les internautes ou des devices par les mobinautes, la couverture nécessaire des tests est de plus en plus importante. De fait réaliser une campagne de test de non régression avant une mise en production, devient impératif.

Mais la réaliser sur un seul environnement peut s’avérer insuffisant. Aujourd’hui, un test de non régression pour un site Internet doit être effectué a minima sur 2 à 3 navigateurs : Chrome (68% des utilisateurs), Firefox (11%), IE (7%) – Source StatCounter et sur 2 à 3 machines. Si vous avez une app mobile ou un accès en responsive design sur plusieurs mobiles, tablettes.

On résume ; pour une campagne de tests de non régression d’une application disponible sur mobile et web, soit la majeure partie aujourd’hui, on a :

Soit, pour une configuration simple, 5 environnements à tester donc autant de scénarii à exécuter, maintenir, faire évoluer… et pléthore de résultats à analyser, répertorier, cartographier, à communiquer aux équipes de développement. Sans parler des KPIs à établir pour obtenir un retour sur cette MEP et améliorer la prochaine.

Si l’on combine la « fréquence X couverture fonctionnelle X environnement » on se rend compte qu’il est impératif de mettre en place des outils d’automatisation.

3 – Quels scénarios ?

La typologie du scénario de votre test de non régression est critique pour déterminer s’il est pertinent de passer à l’automatisation. Dans le cas d’un seul scénario où vous allez tester les points critiques du parcours utilisateur : valider que l’utilisateur peut mettre un produit dans son panier, s’enregistrer et payer, des procédures manuelles pourraient suffire.

Mais ce cas n’arrive quasiment jamais car alors votre couverture de tests se restreint à une seule fonction, certes stratégique ! Encore que, comme expliqué ci-dessus, il faut corréler cela avec la fréquence et l’environnement à tester.

Pour exemple un scénario plus précis et intégrant l’ensemble du parcours utilisateur de votre site internet ou votre application mobile :

1. Chargement de la page d’accueil
2. Chercher un produit dans la barre de recherche
3. Cliquer sur la fiche produit
4. Cliquer sur l’image
5. Ajouter le produit au comparateur
6. Aller dans le menu catégorie
7. Aller et cliquer sur la sous-catégorie A
8. Cliquer sur une fiche produit
9. L’ajouter au comparateur
10. Accéder au comparateur
11. Sélectionner un des deux produits
12. L’ajouter au panier
13. Se connecter / Ou créer un compte
14. Choisir son option de transport
15. Payer
16. Accuser réception du paiement

Le nombre d’actions par scénario peut vite augmenter, il est cependant impératif de segmenter au mieux les parcours pour les établir par fonction.

4 – Le nombre de profils ?

Le dernier des éléments-clés concernant l’automatisation de vos tests de non régression est le nombre de profils à tester. Les parcours utilisateurs sur votre site ou votre applicatif varient-ils en fonction des différents droits d’accès, ou selon des personnalisations par profil : connecté, non connecté, client récurrent, client VIP, Admin …

Ces profils sont autant de coefficients multiplicateurs au nombre d’actions à reproduire. Dans notre exemple ci-dessus, admettons que 3 profils utilisateurs sont à tester :

On résume la formule magique :

fréquence x nbr environnements x actions par scénario x profils = nbr d’actions à reproduire.

À raison d’une minute en moyenne par action : prise de connaissance de l’action, saisie de la valeur, action, étude du résultat, saisie du résultat et commentaire… vous avez devant vous une journée de tests à effectuer pour une seule phase de tests.

Bien entendu, avant la livraison de la nouvelle MEP, il sera nécessaire d’en réaliser plusieurs. Sachant que dans notre exemple nous n’avons que 4 scénarios. Nous vous laissons faire le calcul pour votre contexte. Attention le nombre de jours/hommes nécessaires va vous effrayer !

À cela s’ajoute que la récurrence des actions manuelles va augmenter le pourcentage d’erreur. À ce stade, pas de secret, l’automatisation des tests est la seule alternative pour assurer la fiabilité de vos applicatifs !

Pour conclure.

Tout au long de la vie d’un projet, des évolutions sont apportées. Un test fonctionnel doit devenir un test de non régression à chaque nouvelle mise en production, s’il est pertinent de les rejouer à chaque sprint.

Un maximum de tests logiciels doit être effectué avant une mise en production. Ils ne garantissent pas l’absence de défauts, mais permettent d’assurer la qualité des applicatifs, de gagner du temps tout au long du processus de développement et de permettre aux utilisateurs finaux d’avoir confiance lors des livraisons de nouveaux lots.