Tester une application native mobile sans mobile… le prix du ‘sans’?

Tester une application native mobile sans mobile… le prix du ‘sans’?

Cet article complète le précédent sur le test des sites web mobiles sans mobile physique.

Il présente moins d’alternatives car de facto, le test d’une application native élimine certains outils comme les User Agents et les outils de développement des navigateurs.

La problématique du gain de temps entre l’utilisation d’un outil de substitution et un vrai mobile refait ici surface avec un gain considérable dans le cas de la plateforme iOS et de son IDE XCode: par exemple lancer la toute dernière build à travers le simulateur permet de s’affranchir des problèmes de certificats requis pour l’installation sur des artefacts mobiles physiques. Si vous n’avez pas les connaissances minimales requises, ces problèmes peuvent prendre un long moment à être résolus et ont dans mon expérience personnelle impliqué l’aide extérieure de mes collègues développeurs qui avaient rencontré les mêmes problématiques  – je fais ici référence à mon expérience avec les versions de XCode 7 pour iOS8 et antérieures.

Expérience utilisateur sur une application iOS de réseau social

Par ailleurs, l’ergonomie d’une application native doit également se concevoir différemment de son homologue web… La tester requiert des conditions de test réelles au plus proche de l’utilisateur final, impliquant les périphériques physiques: il est selon moi trop risqué d’établir des résultats pertinents uniquement basés sur des outils de simulation et d’émulation, car il ne s’agit pas de mettre un état ‘Passed’ ou ‘Failed’ à chaque critère d’acceptation, mais plutôt d’obtenir un ressenti cognitif le plus ‘objectif’ possible afin d’accommoder les principaux utilisateurs – ce qui n’est pas évident étant donné que le terme ‘cognitif’ référence une notion très subjective.

[Petit aparté personnel: je trouve le test d’application native vraiment magique pour notre métier de testeur, car c’est le domaine qui selon moi exacerbe le plus l’activité cognitive du test et met pleinement en valeur l’efficacité des testeurs humains par rapport aux machines et aux checks automatisés…]

Note: tous les exemples repris dans cet article concernent la plateforme iOS car je testais exclusivement les applications de cette plateforme lorsque je travaillais au sein de l’équipe mobile du groupe Yoox – Net-a-porter.com.

 

Simulateur

Cet outil fait partie de l’Environnement de Développement Intégré (‘IDE’ en anglais) spécifique à la plateforme à tester (XCode est l’IDE de la plateforme iOS par exemple): il peut gérer l’outil de simulation pour différentes versions de l’OS concerné, à condition d’avoir au préalable installé les Service Development Kit des versions d’OS correspondantes.

J’ai très souvent utilisé le simulateur pour mes tests fonctionnels: son comportement étant globalement très satisfaisant, il permettait rapidement de vérifier certains correctifs et certaines fonctionnalités sans avoir à passer par le téléphone.

En dehors du fait qu’il ne permet pas de tester pleinement l’ergonomie et l’utilisation des ressources comme les crash mémoire ou les performances – il m’a néanmoins déjà permis de déceler des fuites mémoire -, il offre un GROS avantage pour tester sous différentes versions d’OS lorsque vous n’avez pas suffisamment de téléphone, et SURTOUT lorsque vous devez les partager avec le reste de l’équipe.

Cette problématique doit être répandue: les testeurs ont besoin des vrais périphériques pour rendre leur test pertinent, mais les autres membres de l’équipe aussi. Les développeurs en auront besoin soit pour implémenter une nouvelle fonctionnalité et son ergonomie correspondante, soit pour tester un correctif dont le bug n’est pas reproductible sur simulateur… et qu’en est-il des designers et des ergonomes qui doivent plancher sur l’interaction et la qualité du rendu des images ? Eh oui, eux aussi en ont besoin, et ça devient bien vite la bagarre pour le Saint-Mobile! Cela génère alors un goulot d’étranglement et un risque pour le projet, que le simulateur aide à mitiger.

Dans mon équipe nous étions douze personnes à potentiellement utiliser les téléphones dont nous disposions: ainsi, il ne m’était pas toujours possible de récupérer rapidement le périphérique requis, bien que les tests l’exigeaient – notamment pour un correctif si l’anomalie n’était pas reproductible sur le simulateur. Le projet et la livraison s’en retrouvaient alors légèrement retardés, ce qui pouvait nous amener à reprioriser les tests restants à exécuter afin de tenir les délais de livraison prévus.

A savoir aussi que le simulateur, tout comme le téléphone, présente l’intérêt de se coupler au mode de debuggage de l’IDE, grâce auquel il est possible:

 

  • d’insérer des points d’arrêt à certains endroits du code correspondant à une étape précise de votre scénario fonctionnel; Ceci vous permet de modifier manuellement les pré-conditions ou les données entre deux étapes de scénario et de rendre testable certains cas limites,
  • de visualiser les requêtes HTTP de l’application vers les web services, ce qui peut mettre en évidence des requêtes manquantes ou incorrectes,
  • de visualiser les requêtes HTTP de l’application vers un site web dans le cas d’une application hybride qui utilise des vues web,
  • de visualiser les logs applicatifs.

Bien que ces opérations puissent aussi se réaliser avec le mobile physique, il faut noter que le simulateur n’est pas en reste de ce point de vue. Les outils de l’IDE peuvent ainsi être comparés aux outils de développement du navigateur pour les sites web mobile, bien que ces derniers n’offrent pas les outils de test d’interaction entre l’application et les ressources physiques du téléphone.

Avantages

  • Fiable pour effectuer la plupart des tests fonctionnels,
  • Permet des premiers retours rapides sur des fonctionnalités ou des correctifs en s’affranchissant des contraintes liées aux disponibilités des périphériques physiques,
  • De nombreuses informations disponibles pour analyse grâce aux outils de l’IDE.

Inconvénients

  • Utilisation en mode debug seulement: les scenarii de mise à jour, installation, ou désinstallation ne sont pas représentatifs de l’interaction utilisateur avec l’AppStore,
  • Impossible de tester l’ergonomie utilisateur car pas de ‘tap’ possible,

    Notification de batterie faible
  • Non représentatif pour les tests de contraintes liées au hardware: crash liés à un excès d’utilisation mémoire, faible espace de stockage disponible, batterie faible (voir image ci-contre)…

 

 

Emulateur

Je n’ai malheureusement jamais testé d’application native sur émulateur, mais je serais curieux de connaître vos retours d’expérience.

 

Le vrai smartphone

Sans vous vanter ici les bienfaits évidents du Saint-Mobile, je souhaite relativiser l’utilisation du simulateur au-delà des quelques inconvénients que je vous ai cités précédemment: la différence de comportement que j’ai parfois observé entre ce simulateur et le vrai smartphone, sans qu’il s’agisse d’un comportement lié aux contraintes hardware, est suffisante pour conserver sa vigilance.

L’une des raisons était l’utilisation de l’application en mode ‘debug’ pour les tests, alors que l’applicatif était mis à disposition à l’utilisateur dans l’AppStore en mode ‘release’, non testable via le simulateur: une logique de compilation différente entre ces deux modes expliquait l’apparition d’anomalies en mode ‘release’ uniquement.

Afin de répondre à cette problématique, et parce que nous avions malheureusement repéré ce phénomène suite à un bug en production une fois, nous réalisions les tests suivants sur le mobile physique en mode ‘release’:

L’AppStore est le point de passage de l’utilisateur pour une application native
  • Scenarii de mise à jour, de première ’installation et désinstallation/réinstallation de l’application au travers de TestFlight qui simulait le comportement de l’AppStore,
  • Tests de non-régression.

 

Tester sur un vrai mobile, c’est fun et ça permet aussi de faire de l’exercice, notamment concernant les tests de connectivité réseau et leur impact sur le chargement des données; A ma connaissance deux aspects en particulier ne peuvent pas être testés en restant assis sur son siège malgré les outils mis à disposition:

  • Tous sont des testeurs incognito…

    la dégradation/l’amélioration progressive du signal,

  • la déconnexion/reconnexion automatique et constante à des nouveaux relais lorsqu’on utilise le mobile en déplacement rapide (TGV par exemple…).

Tandis que nous pouvions tester ce dernier cas sur le trajet domicile-travail, le premier cas nous faisait faire un peu d’exercice puisque nous allions tester au centre commercial à côté des bureaux: nous avions repéré quelques endroits où la connectivité était plus ou moins faible, et faisions les aller-retour entre différentes zones tout en déroulant les scenarii de chargement des données.

Avantages

  • Obtention du véritable ressenti utilisateur quant à l’ergonomie,
  • Écosystème représentatif qui met en avant les problèmes issus des contraintes auxquelles est soumis l’applicatif: réactivité des transitions, rapidité de chargement, etc.
  • Permet de dérouler des tests de stress: mémoire limitée et dépendant des autres processus, niveaux de batterie très bas, espace de stockage plein, etc.

Inconvénients

  • Nécessite d’avoir un téléphone par version d’OS/configuration particulière testée,
  • Nécessite une gestion centralisée efficace des périphériques pour les partager entre les différents membres de l’équipe,
  • Parfois difficile de tester les applications hybrides – mélange de web et de natif: nous avions sous iOS des problèmes de certificats nécessitant l’intervention d’autres équipes pour se connecter au site web au travers de l’application.

 

J’espère que ce premier état des lieux sur les outils disponibles pour les tests d’application mobile vous aura apporté des limitations que vous ne connaissiez pas, et que cela alimentera des réflexions en cours ou futures concernant la pertinence des tests en fonction des outils disponibles.

D’ailleurs, ces deux articles vous auront-ils éclairés ? Utilisez-vous beaucoup ces différents outils ? Ou avez-vous fait le choix d’éviter ces pièges en investissant dans une gamme large et variée de périphériques physiques ? N’hésitez pas à partager votre expérience et à laisser des commentaires.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.