Savez-vous fixer les objectifs réalistes de vos tests automatisés ?

La question peut surprendre et pourtant, c’est le premier défi à relever lors de la mise en place de tests automatisés. Entre les objectifs fixés et le champ des possibles il y a un monde. Les objectifs de tests peuvent être de plusieurs ordres, mais l’on retrouve souvent les mêmes : mettre une version en production « parfaite » ; avoir une version en production accessible dans les meilleures conditions ; une version en production fonctionnelle à 100% partout, tout le temps et sur tous les supports.

Même si les objectifs sont légitimes, il faut faire attention à ce que cela implique réellement :

Mettre en production une version exempte de dysfonctionnements : 100% PARFAITE

C’est le graal de toutes les équipes impliquées dans un projet de développement : la version parfaite ! Une simple phrase qui donne un objectif précis, comme par exemple : « Je veux que l’application soit testée à 100 % » est inenvisageable ! 

Mettre en production une version PARFAITE, exempte de tout dysfonctionnement, implique de tester 100% des fonctionnalités de votre développement et donc 100% des lignes de code. Mais même cela n’est pas suffisant car il faudrait tester 100% de ces lignes sur 100% des navigateurs sur 100% des terminaux, avec tous les jeux de données possibles …

Au risque d’en décevoir certain, on ne peut absolument pas tester tout un développement même en industrialisant les tests automatisés. Techniquement c’est “possible” mais humainement et financièrement impensable. La constitution du patrimoine de tests nécessaire pour parcourir l’ensemble des lignes de code du développement est juste impossible. Et quand bien même, rien ne permet de garantir une couverture à 100%. 

Imaginons que, à l’aide d’une armée de collaborateurs, vous avez identifié les milliers de scénarios nécessaires, il faut maintenant les créer, avec les jeux de données nécessaires.

Vous allez vous retrouver à devoir mettre en place des centaines de scénarios qu’il ne vous restera plus qu’à exécuter sur des dizaines de navigateurs déployés sur des dizaines de terminaux.

En vulgarisant : 1000 scénarios X 10 jeux de données X 5 navigateurs = 50 000 tests exécutés ou il vous faudra ensuite analyser les résultats. Bonne chance !

Vous l’aurez compris, pour des raisons fonctionnelles et/ou de temps il est irréaliste de vouloir tester 100% des fonctionnalités. Que l’on automatise ou pas, on ne peut pas tout tester et encore moins si l’on automatise pas.

La solution ? Il faut se focaliser sur les fonctions de l’application pour définir des scénarios à établir. Prenons l’exemple d’un site e-commerce pour lequel l’on souhaite tester le catalogue. L’erreur serait de vouloir tester tous les produits présents dans le catalogue, comme on nous le demande souvent. L’important est de tester : la fonction de recherche, d’auto complétion, valider l’affichage et la correspondance de la requête, puis la sélection d’un produit. Si la fonction est opérationnelle pour une, elle l’est pour tous ! (sauf cas exceptionnel) 

C’est le rôle du prestataire (partenaire) de vos tests, que vous allez choisir ! Il n’est pas uniquement là pour définir une stratégie et un plan de tests automatisés, mais aussi pour étayer le choix des scénarios. Pour autant, cela ne veut pas dire que l’on laisse de côté des pans de l’application, cela veut dire que l’on va mettre en place des scénarios qui, en se recoupant, vont permettre de tester la plus grande partie de votre application en fonction : des moyens, des ressources et du temps que vous avez.

Une version accessible dans les meilleures conditions possibles en tout temps.

Une fois la version mise en production, sans dysfonctionnement grâce à des scénarios de tests pertinents, il faut s’assurer que la version en production est accessible dans les meilleures conditions possibles en tout temps. Ça c’est le rôle de la supervision applicative.

L’objectif est que l’application soit accessible, en tout temps, partout et dans des conditions parfaites. Si l’on exprime ce besoin avec des conditions de tests automatisés on obtient :

• Supervision sur les plus grandes villes
• Et, bien entendu, sur les principaux navigateurs du marché : Chrome, Firefox, Safari & Edge

Bien entendu, dernière un projet de supervision applicative (end-user) il y a plusieurs scénarios. Même si vous avez appliqué la leçon de la partie 1 de cet article, vous vous retrouvez au minimum avec une trentaine de scénarios ce qui nous donne, au final :

20 communes en France X 4 navigateurs X 10 scénarios = 800 tâches de supervision à exécuter !

Vous comprenez que tout cela n’a aucun intérêt car, sur bien des facteurs, vous n’avez aucun levier d’action. Il faut donc revenir à des conditions réalistes. Commençons par ne sélectionner que les villes les plus représentatives de vos utilisateurs, avec les navigateurs les plus utilisés par ces derniers. Au final avec 3 villes stratégiques, 3 navigateurs et 10 scénarios nous avons : 3 * 3 * 10 = 90 tâches à automatiser pour couvrir plus de 95% des cas d’utilisation. Ce qui est déjà très significatif mais pas impossible.

Vous remarquerez que nous ne réduisons pas les parcours exécutés, dix dans les deux cas, car c’est ce qui permet de vérifier l’accès dans de bonne condition aux fonctions clefs de votre application : tunnel d’achat, création d’utilisation, chargement d’un RIB. Pertinent non ?

Mettre à disposition une application mobile qui absorbe les pics de charge

Vous avez mis à disposition sur les stores la dernière version de votre application mobile et vous vous attendez à un grand nombre de connexions simultanées. La problématique : comment être sûr que votre application va tenir le coup face à un grand nombre d’utilisateur ? L’objectif des tests est de mesurer la capacité d’absorption de l’application pour mettre en place des pages de débordement.

Pour se faire, nous pouvons imaginer une campagne de tests de charge effectuée depuis 1000 téléphones qui se connectent simultanément sur l’application et depuis différentes localisations. En réalité, c’est envisageable de procéder ainsi, avec les nouveaux Cloud de devices mobiles disponibles. Mais il y a très peu d’intérêt à tester sur des téléphones réels, car il y a X facteurs qui vont intervenir, indépendamment des performances de votre infrastructure.

Alors que, en utilisant un émulateur, on peut exécuter les scénarios et surtout savoir comment réagit l’infrastructure. Pour répondre à l’objectif, commencer par émuler 50 connexion sur le ou les (2) téléphones les plus utilisés par les clients est déjà une très bonne première étape !

Pour conclure

Voici ce que nous pouvons dire sur la différence entre des objectifs des tests automatisés et des conditions réalistes. Dans la très grande majorité des cas il est humainement impossible de couvrir 100% des usages et fonctions d’un développement.

La limite n’est pas technologique mais humaine et financière et cela commence par la capacité même d’imaginer TOUS les scénarios nécessaires pour couvrir TOUTES les fonctions. À cela il faudra ajouter le temps pour décrire les scénarios, les jeux de données, les créer sur une plateforme d’automatisation type CloudNetCare, analyser les résultats obtenus. Et, le temps c’est … !