Chaque jour la barrière d’accès au mobile se réduit pour quasiment s’effacer. Et c’est une excellente chose. Pour ceux qui seraient passés à côté de l’information, la marque indienne Ringing Bells a récemment annoncé et dévoilé les spécifications d’un smartphone tournant sur Lollipop (avant dernière version d’Android 5.1), doté d’un écran 4 pouces, le tout ayant accès au réseau 3G. Le plus drôle dans l’histoire ? Ce mobile coûte uniquement 251 roupies (soit 3,30 euros).
L’apparition de ce genre d’appareil constitue à la fois une bonne et une mauvaise nouvelle, comme je vais vous l'expliquer. Mais, pas de panique : j'ai également une solution à vous proposer pour mieux s'adapter à cette nouvelle donne.
Pourquoi le smartphone Ringing Bells représente-t-il à la fois une bonne nouvelle et un motif d'inquiétude ?
Équipé d’une version relativement récente d’Android avec les différents services Google intégrés et un accès au PlayStore, ce smartphone va de façon évidente booster la pénétration d’Android sur un marché Indien déjà dynamique. Et par la même occasion, permettre l’accès à de nombreuses applications mobiles auprès d’un public jusqu’ici peu, voire pas du tout, concerné par le téléchargement et l’utilisation d’applications. Porté par 1 milliard d’utilisateurs mobile, l’écosystème va ainsi continuer de grandir et offrir de belles opportunités aux développeurs.
A présent, la mauvaise nouvelle : la fragmentation du parc de smartphones tournant sur Android n’a rien de nouveau et représentait déjà une difficulté pour les PM/PO et développeurs travaillant sur un produit mobile. Cette fragmentation va devenir de plus en plus importante avec l’arrivée de nouveaux constructeurs de smartphones, et se caractérise par 2 problèmes majeurs:
- La dilution des versions du système d’exploitation (s'étalant de 2.2 à 6.0). Sans rentrer dans le détail de l’état des versions d’Android en circulation, cette diversité peut poser de réelles problématiques en tant que PO. Quelles versions minimum doit supporter le produit afin de s’adresser à un public assez large tout en étant en mesure d’utiliser les services offerts par les API Google Play Services? Dès la phase de conception de votre application, il est important de définir la version minimale supportée en se basant sur 3 éléments propres à votre produit et stratégie :
- Quel est le volume d’utilisateurs de smartphones Android visé ?
- Est ce que l’utilisation d’animations recherchées et fluides fait partie de l’ADN de votre produit ?
- Quels sont les services Google dont votre produit a nécessairement besoin pour bien fonctionner ?
- Le second problème, bien plus préoccupant pour les PO, réside dans l’explosion du nombre de modèles et constructeurs de devices sous Android. L’excellent rapport de Open Signal publié tous les ans donne une vision concrète de l’état du parc mobile à l’aide du graphique ci-dessous :
Une valeur clé à suivre et garder en tête afin de délivrer un produit de qualité: en 2015, le marché du smartphone Android est composé d’un peu plus de 24 000 modèles différents. Si l’on jette un coup d’oeil à ce même rapport fin 2014, on constate l’apparition de 5297 nouveaux modèles jusqu’ici inconnus, en moins d'un an.
Bref, vous l’aurez compris, sortir une application mobile de qualité sur Android nécessite de mettre en place des processus et outils de tests permettant de s’assurer une qualité équivalente de votre application sur l’intégralité des mobiles de vos futurs utilisateurs.
Comment les Product Owners peuvent s'adapter
Given un product owner mobile chez Docapost IOT,
When il doit rédiger cet article,
Then il propose un retour d’expérience
Dans le cadre de ma mission, j’ai eu l’occasion de constater les points suivants:
- Les product owners manquent généralement de temps pour assurer une phase de recette approfondie. Par conséquent, il est souvent matériellement difficile d’effectuer les tests et la validation des fonctionnalités avec le niveau d’approfondissement pourtant nécessaire.
- L’équipe de test ne possède pas le même degré de connaissance produit. De ce fait, certaines anomalies remontées aux équipes de développement et aux PO manquent parfois de finesse dans la compréhension du fonctionnel attendu et des guidelines Android préconisés par Google.
- Les phases de test de non régression sont nécessaires avant chaque release d’une nouvelle version de l’application. Cependant, ces parcours de tests fonctionnels peuvent devenir longs à réaliser, répétitifs et la valeur ajoutée du testeur manuel sur cette tâche est assez faible.
- L’équipe de test ne possède pas une collection de smartphones suffisante pour s’assurer que leurs tests couvrent à minima une partie du parc d’appareils sur lesquels l’application sera utilisée une fois sur les stores. La part d’inconnu quant au comportement de l’application sur les modèles de smartphones non testés est trop importante pour pouvoir distribuer sereinement le produit.
A partir de ces différentes observations, il m’a semblé nécessaire de faire évoluer le processus de test et de validation avant chaque nouvelle soumission de l’application (qu’il s’agisse d’une release mineure ou majeure).
Action 1 : Rédiger des tests fonctionnels d'acceptation complets (si le besoin s’en fait sentir)
Considérer que la qualité du code mobile tient uniquement de la responsabilité des développeurs est selon moi une mauvaise chose. Bien qu’il ne soit pas techniquement en mesure de développer les tests unitaires et fonctionnels, le PO doit être moteur dans la réalisation d’un code de qualité. Pour cela, c’est dès la phase de conception, lors de la rédaction des spécifications d’une story qu’il faut prévoir des critères d’acceptation idéalement rédigés en Gherkin (pourquoi ce langage particulièrement ? on en parle ici pour les curieux). Pour forcer l’équipe à gagner en qualité, une des idées émises lors de la dernière rétrospective de mon équipe mobile consistait à intégrer dans la Definition Of Ready des US, la présence des tests fonctionnels rédigés dans la syntaxe mentionnée plus tôt.
L'intérêt sur le plan qualitatif est évident mais j’ai le sentiment que la rédaction puis le développement de ces tests d’acceptation peuvent vite devenir chronophages, dès lors qu’il faut faire du spécifique pour chaque user story. Afin de ne pas trop impacter la capacité de production de l’équipe, nous avons donc convenu de discuter à chaque présentation d’une US, de l'intérêt d’avoir ou non les TF en Gherkin avant de débuter les développements d’une story.
Action 2 : Mettre en place un outil d’automatisation des tests fonctionnels.
L’un des nombreux mérites de Gherkin, c’est que cette syntaxe soit interprétable par Cucumber qui va se charger de traduire le scénario écrit en langage humain vers une version beaucoup plus détaillée. Cette version Cucumber comprendra du code (du ruby dans mon cas) détaillant les différentes étapes du test.
L’étape qui suit est clé et consiste à associer le travail fait par Cucumber à un second outil : Calaba.sh. L’avantage de ce second framework est qu’il permet d'exécuter chaque étape du test en déclenchant l’action sur un device iOS ou Android et fournit donc une équivalence dans le langage natif approprié (Objective-C ou Java).
Une fois ce processus mis en place sur votre projet mobile, vous pourrez dérouler vos tests fonctionnels sur iOS et Android de façon automatique. Dans le cas de mon projet, le choix de cet outil s’est fait par rapport aux critères suivants :
- possibilité d'exécuter des scénarios de tests sur des parties natives et hybrides de l’application
- possibilité de vérifier que le contenu des webviews contient bien les éléments attendus
- adaptation de l’outil au vocabulaire spécifique lié aux interactions et gestes tactiles que l’on retrouve sur mobile
- capacité à réaliser des screenshots à chaque étape des scénarios de test
- utilisable aussi bien pour iOS que pour Android
Action 3 : Lancer vos tests fonctionnels sur un parc de smartphones le plus large possible.
Vous êtes maintenant capables de lancer différentes séries de tests fonctionnels sur votre poste ou celui d’un de vos développeurs. C’est déjà bien, mais les tests en question seront réalisés localement sur un simulateur, par conséquent, vous risquez de passer à côté d’un contexte pourtant immanquable : le comportement réel de votre application sur la multitude d’appareils et versions d'Android sur lesquels elle va être utilisée.
Que diriez-vous de pouvoir lancer ces tests fonctionnels sur de véritables smartphones dans le cloud et d'observer, de façon quasi certaine, des différences d’un constructeur à un autre, d’une taille d’écran à une autre ou encore dans différentes conditions de réception du réseau ?
Deux outils proposent aujourd’hui de réaliser vos tests sur ce que l’on appelle des devices farm: Xamarin TestCloud et Amazon Device Farm. Jusqu'à maintenant c’est plutôt dans l’outil de Xamarin que nous avons investi du temps de prise en main et documentation.
L'intérêt de cet outil est multiple et représente selon moi un gain énorme sur un projet mobile sérieux :
- Il n’est plus nécessaire de posséder physiquement une base importante de téléphones de test. Au lancement d’un de vos tests, le service se charge d’installer votre application sur des centaines de devices réels en même temps.
- Chaque phase de tests se clôture en générant un reporting détaillé des téléphones sur lesquels le test est passé avec succès ou a échoué. Ci- dessous, le visuel d’exemple d’un test lancé sur plusieurs modèle de smartphones Android à l’aide de Xamarin TestCloud :
- Lors de l’échec d’un test sur un modèle précis, vos développeurs possèdent l’information sur la partie du code qui a provoqué l’échec. Un moyen efficace de gagner en réactivité sur des bugs et ainsi les corriger avant une mise à disposition de l’application sur les stores.
- Enfin, l’utilisation de cet outil peut facilement s’inscrire dans un processus d’intégration continue déjà en place. Le déclenchement d’un scénario de tests peut se faire manuellement par le PO / l'équipe de test / les développeurs mais on peut également intégrer ces tests dans la chaîne de build de l’aplication, ce qui permet d’avoir un feedback très rapide si une partie du code est affectée par une modification faite il y a peu et donc de corriger le tir dans la foulée (voir proposition de workflow plus bas).
Product Owner / Product Manager, vous voilà maintenant un peu plus informés sur les moyens qui sont votre disposition pour veiller à la qualité des applications mobiles sur lesquelles vous travaillez.
Si vous avez également eu l’occasion de mettre en place ce genre d’outils ou d’autres solutions, n’hésitez pas à faire part de votre expérience suite à cet article !
