Quels outils pour faire tester vos apps à distance à des clients non-technophiles ?
“Ça y est, on a une première version de l’app sur chaque environnement de développement !”. L’équipe exulte. De l’autre côté de l’écran, le sourire est de rigueur chez le client. Quand soudain, la question tombe : “Ok du coup je peux la trouver sur l’App Store pour la tester ?”. Stupeur. L’équipe se retourne vers le PO qui, pris de court, garde son sourire et répond que “non, il va falloir mettre en place un moyen de vous mettre les apps à dispo ; il existe plein de solutions”. Le client acquiesce. Ouf. On a gagné un peu de temps. Mais dès la fin de la visio, le PO garde l’équipe : “ok, quelles solutions a-t-on pour que ce soit la mise à dispo des applications la plus simple possible ?”.
Contexte
Jusque là, les applications étaient installées directement en reliant le téléphone à l’ordinateur via Xcode ou ADB : le sideloading. Sauf que pour ce projet, le client est à 600 kilomètres de nos locaux. Le sideloading ne serait possible que lors de nos déplacements chez le client, une fois par semaine au mieux ; ce n’est pas suffisant. Et pour ne rien arranger, ce client n’a pas d’affinité particulière avec l’informatique. Il faut donc partager les applications avec monsieur Tout-le-monde. Bon. L’équipe fait le tour des solutions principales :
- HockeyApp, pour iOS et Android
- TestFlight, pour iOS (via App Store Connect, le nouveau nom d’iTunesConnect)
- Play Store, pour Android (via Google Play Console)
C’est le début du projet et nous avons une application dans laquelle nous pouvons switcher entre nos 3 différents environnements de développement : dev, démo et prod (respectivement développement, démonstration et production). Nous n’avons donc qu’un seul build (version exécutable d’un programme) à gérer. Assez naturellement, l’équipe privilégie la seule solution cross-platform : HockeyApp.
Solution 1 : HockeyApp
HockeyApp possède le grand avantage d’être cross-platform. Nous avons donc paramétré un compte HockeyApp, et y avons mis en place une procédure afin d’uploader automatiquement tous les builds dessus. Nous avons choisi de ne pas intégrer le SDK d’Hockey App afin de ne pas avoir à gérer le cas de la version de prod séparément.
Une fois les apps uploadées dans HockeyApp, il suffit d’inviter un utilisateur via l’interface du service. Les étapes pour l’utilisateur sont les suivantes :
- créer un compte sur HockeyApp
- cliquer sur le lien du mail pour pouvoir accéder à l’app mise à disposition
- télécharger le build voulu
Premier hic : il n’existe pas d’application dédiée dans l’App Store ni le Play Store (ndlr : il en existe une sur le Play Store depuis fin avril 🎉). Il faut donc expliquer à notre client comment ajouter un raccourci depuis une page du navigateur web. Et sur iOS, l’utilisateur doit faire une manipulation particulière pour envoyer l’UDID de chaque device qu’il souhaite utiliser afin d’avoir accès aux builds envoyés.
Sur Android et iOS, l’installation d’une nouvelle version n’est pas possible sans supprimer manuellement la version précédemment installée. Dans ce cas de figure, l’erreur n’est malheureusement pas assez explicite pour comprendre la manipulation à faire : on doit se débrouiller avec le laconique “une erreur est survenue”.
Sur iOS, l’icône d’Hockey App ouvre une nouvelle fenêtre de Safari à chaque clic, et demande de se connecter à son compte à chaque fois. Ce qui ne nous semblait pas être un frein s’est montré particulièrement gênant si vous réalisez l’opération plusieurs fois par jour.
Dans les deux cas, l’utilisateur est prévenu par e-mail de la disponibilité des nouvelles versions. Malheureusement plutôt que de subir plusieurs dizaines de mail par jour, notre client s’est désinscrit de ces mails. Il nous fallait donc le prévenir de faire la manip lorsque que nous souhaitions tester un nouveau développement avec lui.
Bilan
L’utilisation d’Hockey App n’a pas été le havre de productivité que nous avions imaginé. La manipulation est suffisamment lourde pour qu’un utilisateur sans affinité particulière avec l’informatique rechigne à l’utiliser à une fréquence suffisante pour du développement Agile ou Lean.
Les griefs mentionnés ici sont loin d’être insurmontables. Intégrer le SDK de Hockey App (nous l’avons fait sur d’autres projets) permet d’aller au-delà de la plupart de ces écueils, avec notamment les notifications de nouvelles versions disponibles directement dans l’application. Toutefois, nous avons continué à chercher une solution plus simple et efficace pour ce client.
Nous avons donc décidé de tester la solution mise en place par Apple : TestFlight.
Solution 2 : HockeyApp pour Android et TestFlight pour iOS
Une fois le setup mis en place, TestFlight est d’une efficacité redoutable : il suffit d’aller sur l’application TestFlight et d’appuyer sur “mettre à jour” ; vous pouvez choisir d’activer les notifications pour être prévenu de la mise à disposition des mises à jour. Cette fois-ci, notre client est conquis par la simplicité !
La mise en place est un peu plus compliquée que l’utilisation. Côté équipe de développement, il faut uploader les builds sur TestFlight. Dans notre cas, nous avons décidé d’uploader automatiquement tous nos builds. Côté testeur, il y a deux options pour accéder à votre app sur TestFlight : être testeur externe, ou être intégré à l’équipe App Store Connect. Dans les deux cas, il faut un compte Apple ; si ce n’est pas le cas Apple vous propose d’en créer un durant la procédure.
Testeur Externe
Sur le papier, cette solution est la plus attirante. Vous allez dans les paramètres de votre application sur App Store Connect, puis ouvrez l’app aux testeurs externes en renseignant leur adresse e-mail. Les utilisateurs n’ont qu’à télécharger TestFlight et cliquer sur le lien du mail pour avoir accès à votre application.
Le service de testeur externe d’Apple possède toutefois une contrainte particulièrement gênante : pour que l’application puisse être testée, il faut la soumettre à Apple manuellement. Oui. Comme pour la publication sur le Store. La durée de validation par Apple est généralement de 24h pour ce cas. C’est court en soi, mais problématique dans notre cas où nous voulons pouvoir tester rapidement les apps.
Note : il est possible de passer outre la vérification de l’app par Apple si vous utilisez un numéro de version identique à une version déjà validée pour publication par Apple. Cela implique 2 choses : que vous ayez une app déjà validée pour la publication par Apple, et de faire vos développements ultérieurs avec le même numéro de version, et ne bumper le numéro de version qu’à la nouvelle publication. Nous ne rentrions pas dans le premier cas, et ne voulions pas du deuxième.
Intégration à l’équipe App Store Connect
Pour ne pas avoir à soumettre les applications à tester à Apple, la solution est d’ajouter vos testeurs en tant qu’utilisateur App Store Connect. La procédure devient un peu plus lourde : il faut d’abord inviter les testeurs sur le compte App Store Connect (ndlr : attention, il faut valider le mail depuis le web, car sur mobile certains boutons de la page sont inaccessibles… !), puis les inviter à tester l’app. Dès que c’est fait, tous vos builds envoyés sur TestFlight sont accessibles à vos testeurs.
Attention toutefois, intégrer vos testeurs sur App Store Connect a une implication forte : aucun rôle attribuable ne permet uniquement de télécharger les builds. En choisissant le rôle de “développeur”, vous donnez par exemple à votre utilisateur la possibilité de voir la liste des utilisateurs App Store Connect et leurs rôles, ou encore de créer des achats intégrés. Bien qu’il soit impossible pour un rôle “développeur” de modifier les informations de l’App Store ou des achats intégrés, nous recommandons d’être prudents et de n’utiliser cette méthode que si vos clients sont les propriétaires du compte App Store Connect.
Bilan
Notre cas d’usage se prêtant bien à l’utilisation de TestFlight, nous en sommes satisfaits. Nos clients ont pris en main l’application et ont compris le fonctionnement. Reste un dernier frein.
Souvenez-vous, nous envoyions tous nos builds sur TestFlight. Ce qui signifie qu’on y retrouvait pêle-mêle des builds de feature en cours de développement, des buids de feature à tester, des builds pour l’environnement de prod, etc. Lorsque nous pouvions tester immédiatement une nouvelle fonctionnalité avec notre client, il lui suffisait effectivement de cliquer sur “mettre à jour” dans TestFlight.
C’était en revanche plus compliqué quand nous devions indiquer un build spécifique à télécharger, en communiquant son numéro de version. Cette manipulation s’est révélée être un frein à une utilisation parfaitement fluide côté client pour les tests.
Nous avons alors décidé de renoncer à la simplicité de lecture de notre proposition initiale, qui était de n’avoir qu’une seule application permettant de changer d’environnement de développement. Pour rendre l’utilisation plus facile et plus fluide, nous avons créé 3 applications distinctes. Une pour chaque environnement de développement.
Solution 3 : HockeyApp pour l’environnement de “dev”, TestFlight et le Play Store pour “démo” et “prod”
En interne, l’équipe de développement avait apprécié l’utilisation de Hockey App. On peut y remonter à des builds anciens sans être limité, et les uploads n’y rencontraient pas de conflit, ce qui n’était malheureusement pas toujours le cas de ceux sur TestFlight. Nous avons donc gardé cette solution pour nos builds de l’environnement de dev.
Côté client, l’utilisation de TestFlight a largement contribué à faire plus de tests et à nous faire gagner du temps sur les retours et donc en qualité de produit livré en fin de sprint. Nous gardons donc ce principe pour les applications de démo et prod. Ainsi, il y a beaucoup moins de builds uploadés pour chacune de ces deux applications et notre client a toujours la bonne version lors de la mise à jour pour les tests.
Il nous restait donc à trouver un équivalent à TestFlight pour Android. Après plusieurs recherches, nous avons décidé d’utiliser la mise à disposition de versions alpha/bêta depuis la Google Play Console. Ici aussi nous avons créé une app Android dédiée à l’environnement de démo. Pour donner accès aux versions alpha/bêta sur Android, le principe est équivalent aux tests externes mis en place par Apple :
- on renseigne l’adresse e-mail des testeurs
- on leur transmet ensuite un lien qu’il doivent consulter pour avoir accès à l’application depuis le Play Store
- l’application apparaît ensuite comme n’importe quelle autre sur le Store
Setup final
Notre setup actuel est donc :
- les builds d’application de l’environnement de dev sont uploadés automatiquement sur Hockey App, et réservés à l’équipe de développement
- les builds d’application de l’environnement de démo sont uploadés automatiquement sur TestFlight pour iOS, et sur le canal alpha de l’app de démo sur Google Play Console
- les builds de l’application de l’environnement de prod sont uploadés automatiquement sur TestFlight pour iOS et sur le canal alpha de l’app de prod sur Google Play Console
Ce que cela nous a apporté
Nous gardons une séance de test par sprint clairement identifiée, mais le grand avantage de cette solution est que les mises à jour se font automatiquement sur le téléphone du client. On récupère ainsi un maximum de retours sur les services de base du produit, ceux qu’ils utilisent tous les jours, avant de publier les versions.
Et au-delà de la recherche de bugs, cette transparence a renforcé la confiance dans la relation avec notre client. D’abord frileux à l’idée d’utiliser des produits “non finis”, les retours successifs et leur prise en compte rapide lui a permis de mieux saisir l’importance de l’amélioration continue et de notre processus Agile.
N’hésitez pas à me poser des questions ou à partager en commentaire vos outils, vos setups, ou vos expériences de mise à disposition continue d’applications mobiles !
