A l'heure où apparaissent les premières banques 100% mobiles en France, il est incontestable que les applications pour smartphones sont devenues un enjeu essentiel de la relation client. Leur qualité doit donc être absolument irréprochable, ce qui implique une attention toute particulière aux tests dans le cycle de développement.
Or les obstacles à franchir sont nombreux avant de pouvoir garantir la détection et la correction de toutes les anomalies, préalablement à la publication d'un titre sur un AppStore. Nick Jones, analyste chez Gartner, en dresse un panorama complet au détour d'une présentation sur les tendances mobiles pour les 4 années à venir. Voilà une excellente occasion de résumer les difficultés à surmonter et d'évoquer quelques pistes de solutions possibles.
Or les obstacles à franchir sont nombreux avant de pouvoir garantir la détection et la correction de toutes les anomalies, préalablement à la publication d'un titre sur un AppStore. Nick Jones, analyste chez Gartner, en dresse un panorama complet au détour d'une présentation sur les tendances mobiles pour les 4 années à venir. Voilà une excellente occasion de résumer les difficultés à surmonter et d'évoquer quelques pistes de solutions possibles.
Naturellement, le principal écueil est celui de la diversité du marché des smartphones. Celle-ci se matérialise d'abord par la coexistence d'écosystèmes différents (a minima ceux d'Apple, de Google et de Microsoft, qui sont vraisemblablement là pour durer). Viennent ensuite les versions successives de systèmes, puis les adaptations spécifiques aux constructeurs (avec Android) et les configurations propres à chaque modèle de téléphone, pour finir par les personnalisations effectuées par l'utilisateur.
Sans aller jusqu'à dire que chaque appareil est unique, ce sont tout de même sur plusieurs centaines de variantes que devraient théoriquement porter les tests pour être exhaustifs. Dans la pratique, il est courant de devoir vérifier les applications sur quelques dizaines de modèles. Pour sélectionner ces derniers, il faut mettre en œuvre les moyens permettant d'analyser l'équipement des clients et identifier leurs téléphones préférés, sans oublier que les modes changent rapidement et que la liste retenue doit donc évoluer constamment.
A ce stade, il s'avèrera probablement nécessaire d'adapter également les pratiques inscrites dans la démarche projet. En effet, les méthodes agiles en vogue actuellement (tout particulièrement pour le développement d'applications mobiles) ne s'accommoderont pas facilement de contrôles à réaliser sur des dizaines de machines différentes.
Autre handicap majeur, l'automatisation des tests n'apporte pas, en l'état actuel des technologies, une réponse complète aux besoins : les solutions disponibles présentent de sérieuses limitations, par exemple lorsqu'il s'agit d'accéder à certaines fonctions (notamment matérielles) des applications. De fait, une bonne partie des tests ne peuvent être réalisés que "manuellement", ce qui les rend coûteux et donc (classiquement) susceptibles d'être sacrifiés lorsque les budgets sont serrés.
Dans le même registre, il ne faut pas oublier les facteurs d'aléas qui pèsent sur une application mobile et la rendent inutilisable sur le terrain alors qu'elle fonctionne parfaitement dans les "laboratoires". Ce sont, entre autres, les conditions de connectivité variables (qui pense à faire des essais dans le métro ?), les liaisons avec les périphériques (Bluetooth...), les impacts d'une surconsommation d'énergie... Autant de critères qui devraient conduire à réaliser des tests dans des contextes divers à l'infini.
Et face à ces difficultés, les consommateurs ont désormais le pouvoir de détruire une réputation en quelques heures, grâce aux notations et commentaires sur les AppStores, alors que le créateur doit patienter, parfois plusieurs semaines, avant de pouvoir mettre en ligne une nouvelle version de son application, même pour une correction d'anomalie. Et ne parlons pas de la vitesse à laquelle évoluent les systèmes et les appareils, dont les nouvelles versions vont faire surgir des dysfonctionnements qu'il faudra prendre en compte au plus tôt...
Quelle(s) solution(s) ? N'en attendons pas de miracles, mais plusieurs variantes de crowdsourcing peuvent venir à la rescousse : des plates-formes de sous-traitance (telles que uTest) à la généralisation des versions "beta" (comme l'avait initié BNP Paribas avec "Le Lab", totalement abandonné depuis, apparemment), en passant par le recours aux collaborateurs de l'entreprise (à l'image d'une idée que j'ai lancée ici)... Avec un nombre de participants suffisants, ces options peuvent garantir une couverture optimale, en termes de diversité des matériels comme de conditions d'utilisation.
Et, cerise sur le gâteau, dans certaines conditions, les testeurs pourront aussi se transformer en promoteurs de la marque !
Sans aller jusqu'à dire que chaque appareil est unique, ce sont tout de même sur plusieurs centaines de variantes que devraient théoriquement porter les tests pour être exhaustifs. Dans la pratique, il est courant de devoir vérifier les applications sur quelques dizaines de modèles. Pour sélectionner ces derniers, il faut mettre en œuvre les moyens permettant d'analyser l'équipement des clients et identifier leurs téléphones préférés, sans oublier que les modes changent rapidement et que la liste retenue doit donc évoluer constamment.
A ce stade, il s'avèrera probablement nécessaire d'adapter également les pratiques inscrites dans la démarche projet. En effet, les méthodes agiles en vogue actuellement (tout particulièrement pour le développement d'applications mobiles) ne s'accommoderont pas facilement de contrôles à réaliser sur des dizaines de machines différentes.
Autre handicap majeur, l'automatisation des tests n'apporte pas, en l'état actuel des technologies, une réponse complète aux besoins : les solutions disponibles présentent de sérieuses limitations, par exemple lorsqu'il s'agit d'accéder à certaines fonctions (notamment matérielles) des applications. De fait, une bonne partie des tests ne peuvent être réalisés que "manuellement", ce qui les rend coûteux et donc (classiquement) susceptibles d'être sacrifiés lorsque les budgets sont serrés.
Dans le même registre, il ne faut pas oublier les facteurs d'aléas qui pèsent sur une application mobile et la rendent inutilisable sur le terrain alors qu'elle fonctionne parfaitement dans les "laboratoires". Ce sont, entre autres, les conditions de connectivité variables (qui pense à faire des essais dans le métro ?), les liaisons avec les périphériques (Bluetooth...), les impacts d'une surconsommation d'énergie... Autant de critères qui devraient conduire à réaliser des tests dans des contextes divers à l'infini.
Et face à ces difficultés, les consommateurs ont désormais le pouvoir de détruire une réputation en quelques heures, grâce aux notations et commentaires sur les AppStores, alors que le créateur doit patienter, parfois plusieurs semaines, avant de pouvoir mettre en ligne une nouvelle version de son application, même pour une correction d'anomalie. Et ne parlons pas de la vitesse à laquelle évoluent les systèmes et les appareils, dont les nouvelles versions vont faire surgir des dysfonctionnements qu'il faudra prendre en compte au plus tôt...
Quelle(s) solution(s) ? N'en attendons pas de miracles, mais plusieurs variantes de crowdsourcing peuvent venir à la rescousse : des plates-formes de sous-traitance (telles que uTest) à la généralisation des versions "beta" (comme l'avait initié BNP Paribas avec "Le Lab", totalement abandonné depuis, apparemment), en passant par le recours aux collaborateurs de l'entreprise (à l'image d'une idée que j'ai lancée ici)... Avec un nombre de participants suffisants, ces options peuvent garantir une couverture optimale, en termes de diversité des matériels comme de conditions d'utilisation.
Et, cerise sur le gâteau, dans certaines conditions, les testeurs pourront aussi se transformer en promoteurs de la marque !
Aucun commentaire:
Enregistrer un commentaire
Afin de lutter contre le spam, les commentaires ne sont ouverts qu'aux personnes identifiées et sont soumis à modération (je suis sincèrement désolé pour le désagrément causé…)