Le bon état d’esprit pour une stratégie de test mobile – Yannick Cum

Il est vrai que faire une stratégie de test mobile n’est rien de plus qu’une énième déclinaison des standards métier.

Je ne vais pas dans cet article vous expliquer pour la 100ème fois, quels sont les items que l’on trouve dans un plan de test, je pense que vous le savez tous aussi bien que moi.

Je vais donc me pencher sur « l’état d’esprit » qu’il faut avoir pour mener à bien cet exercice.

La fragmentation quezaquo ?

Premier point, et pas le moindre, lorsque l’on doit tester sur des appareils mobiles, la chose à bien identifier c’est sur quel device je dois le faire.

Et là, première difficulté : vous avez déjà entendu parler de « fragmentation du marché » ?

Non ?

Regardez la belle image…

(qatestlab : 2018)

Cette image représente la répartition du marché des mobiles Android.
Chaque taille de case correspond à la place du modèle sur le marché.
Je vous laisse imaginer le volume de matériel nécessaire pour n’avoir que « 80% du marché » 😊

Sur cette fragmentation matérielle, il faut en plus identifier le taux d’adoption des OS.

Hé oui ça serait trop simple que tous les devices soient en même temps sur le même OS.

La bonne combinatoire serait donc énorme entre le matériel et le système.
( grosse maille 26000 devices seraient nécessaire pour tester l’exhaustivité des combinatoires.)

Evidement nous ne pouvons pas avoir ce matériel à disposition.

Nous devons donc étudier la répartition optimale du marché et identifier la combinaison la plus représentative de notre cible.

Pour ce faire, il faut étudier les dernières ventes de mobile sur la zone cible (marque et modèles), et recroiser avec les OS pour identifier, dans une matrice de risque, quelle combinatoire offrira la meilleure couverture.

Lors de ma dernière étude, j’ai établi qu’avec 17 devices, je couvrais 75% du marché cible ce qui limitait les risques.
Evidement, cette étude n’est valable que sur un court laps de temps et pour un périmètre géographique et démographique établi.

Bref, vous aurez d’ores et déjà compris qu’avant même de parler de ce que l’on va tester, le « sur quoi » prend déjà beaucoup de place.

Une fois ce point éclairci, nous attaquons une partie plus conventionnelle de la stratégie :  qu’allons-nous tester ?

Des types de tests fréquents pour du mobile sont les suivants :

• Test fonctionnel & Test d’IHM
• Test d’interruption
• Test de sécurité
• Test d’efficience
• Test de communication & Test de flux applicatif

Dans ces tests, nous retrouvons les thématiques de tests d’une stratégie standard (ou presque.)

Voyons voir les spécificités de ces tests.

Le test fonctionnel & test d’IHM

Comme son nom l’indique, cet item permet de valider le fonctionnement attendu de mon application.
Il faut toutefois être prudent, les applications mobiles sont souvent découpées en petites briques, et le volume de test fonctionnel peut vite monter en flèche. Il faut donc plutôt réfléchir de manière plus globale et bout en bout si l’on veut concevoir des tests.

Je lie le test fonctionnel au test d’UI (utilisabilité, ergonomie) car, lors de l’exécution de ces tests, il faut vérifier que l’interface de l’application est bien utilisable et répond, soit à des standard mobile (position du menu et icône associée, position des barres de navigations, position des données importantes sur l’écran…), soit à une charte spécifique et documentée.
Il y a de plus une variable à prendre en compte, la définition de l’écran, évidement en fonction du device l’écran possède des dimensions spécifiques et l’application doit pouvoir s’y adapter.
Cette partie de test est très importante quand on sait que tout le monde aujourd’hui utilise des applications mobiles. L’ergonomie et l’UX/UI fait désormais parti des points clés de la validation mobile.

Questions types à se poser (exemple non exhaustif bien évidement) :

A qui est destinée mon application ? (B2b/B2E/B2C)
Où sera-t-elle utilisée ? (Intérieur/extérieur/condition extrême…)
Comment utilisera-t-on l’application ? (Une main/deux main/ganté…)

Ces 3 questions peuvent déjà nous donner un certain nombre de tests spécifiques à effectuer.

Le test d’interruption

Contrairement à une application standard, l’app mobile est déployée sur…. Un mobile…

De ce fait, il faut prendre en compte des comportements différents dans le cas d’interruption de celle-ci par des aléas dus au téléphone.

Certaines interruptions sont précédées d’une notification et laisse le choix à l’utilisateur de changer d’application, comme la réception et réponse d’un sms ou une notification sur un media social.

D’autre cependant ne laisse pas le choix à l’utilisateur et s’imposent à lui, comme un appel, une panne de batterie par exemple.

Evidemment, nous n’allons pas pouvoir tester tous les écrans ou toutes les transactions applicatives avec ces « aléas » mais il faut tout de même prévoir, lors de la saisie d’un formulaire par exemple ou de l’envoi de données importantes (processus de paiement), de pouvoir effectuer cette transaction avec un appel entrant.

Le mode de fonctionnement de ces interruptions doit être spécifié afin de pouvoir être testé.

Le test de sécurité

Tout le monde le sait, tout le monde le dit, mais nous n’avons que très rarement le temps de tester la sécurité de nos applications. Or, une application mobile est de fait, beaucoup plus sensible.

En effet, plusieurs évènements peuvent se produire et mettre en danger l’utilisateur de l’application.

La plupart des tests à produire sont des analyses de codes, ou des analyses de gestions de données mais il faut les anticiper et tracer, via une analyse de risque, dans la stratégie ce que l’on attend des modes de stockages de données locales par exemple.

Le test efficience

Afin de valider notre application, il faut que celle-ci soit « performante ». Il est évident qu’un utilisateur ne souhaite pas avoir une application « qui rame » sinon il ne va pas la garder.

La partie performance est donc importante pour une application mobile.

Seulement, nous ne devons pas tester « uniquement » la performance de l’application, il faut tester l’efficience.

Mais ça veut dire quoi « efficience » ??

Evaluer la performance d’un système versus son impact énergétique.

En clair, il faut non seulement évaluer la performance des API de communication, évaluer la fluidité des IHM de notre application, mais il faut aussi évaluer la consommation électrique et la consommation de donnée ou de stockage.

Il est évident que nous n’effectuons plus ces tests sur nos applications actuelles hébergées sur des machines avec des To de disque dans des datacenters sécurisés et exploités h24.

Mais dans notre téléphone, 80% du temps (si vous êtes chanceux 😊) sans fils, avec quelques Go de stockage pour les photos et le film de vacances, on n’a pas envie que l’application pour la liste des courses prenne 50% de batterie au démarrage et stocke 15Go de fichier sur le disque pour les références du catalogue d’InterCarouf…

Bref, encore une fois, il faut pouvoir effectuer ces vérifications pour avoir une vision globale de la qualité de notre application, et la Stratégie doit bien évidement faire ressortir ces points d’attention.

Le test de communication et de flux applicatif

Le dernier volet des tests à prendre en compte est celui qui permet à l’application d’interagir avec le reste du monde.

Ces tests se répartissent en 2 catégories distinctes et liées (oui c’est paradoxal 😊) :

• Les tests de communication, qui permettent de valider le fonctionnement de l’application sur différents modes de communication unitaire ou combiné (passage d’un mode à l’autre) par exemple :
  • 3G=> 4G
  • 5G=> 6G (faut prévoir le futur on ne sait jamais)
  • Wifi => 3G
  • 4G => Edge (oui ça existe encore !!! 😊 )
• Les tests des flux applicatifs qui permettent, eux, de valider la bonne interaction de l’application avec son BackEnd. Ils doivent permettre de valider les données transmises par ou à l’application et la qualité de leur retranscription.

La Conclusion (oui on m’en a demandé une)

La stratégie mobile ce n’est pas compliqué. Il faut juste rester curieux et se poser les bonnes questions.

La grosse différence par rapport à une stratégie dite « standard » c’est qu’on ne peut pas réutiliser l’existant tel quel. Le monde mobile évolue très vite, ses contraintes et ses attentes aussi. Il faut donc sans cesse se reposer les mêmes questions. De même la stratégie se doit également d’évoluer au cours des développements.

Ne baisser pas les bras, ce n’est pas du tout insurmontable ! Mettre en place une stratégie mobile va vous permettre de vous positionner réellement comme un utilisateur, avec cette simple question : « moi en tant qu’utilisateur du téléphone qu’est-ce que je n’accepterai pas d’une application ? ».

Vous verrez qu’avec cette simple question, vous pouvez rebalayer tout ce dont je viens de vous parler.
Mais si j’avais commencé par ça vous n’auriez pas tout lu 😊

A propos de l’auteur: Yannick Cum

actuellement coach testing sur des sujets aussi varié que l’automatisation ou l’opérabilité des systèmes, je navigue dans le monde du test depuis plus de 15 ans. Avec mon appétence technique je me positionne entre l’architecture et le business pour donner, aux Tests, une vision globale des systèmes.