Imaginez : vous sortez à peine d’une boutique avec votre achat et vous réalisez qu’il est cassé. Vous retournez à la boutique pour faire une réclamation ou un échange, n'est-ce-pas ? Pourquoi la qualité est-elle obligatoire pour un produit de consommation "classique" mais pas pour un produit numérique ? Pourquoi les applications mobiles "abîmées" sont-elles tolérées ?
Et pourtant, on le lit tous les jours dans la presse : les Français passent de plus en plus de temps sur leur smartphone, la majorité des 20/35 ans dépassant les 2 heures par jour. Le smartphone n'est plus un accessoire, il est devenu incontournable et l’appétit des utilisateurs pour les produits numériques de qualité est exponentiel.
En 2015, les ventes m-commerce devraient augmenter de 24 %, le marché français étant un des plus importants en Europe. Les utilisateurs veulent ce qu'il y a de plus facile et de plus intuitif, ils veulent pouvoir faire leurs achats sur smartphone ou tablette ou desktop sans avoir à se poser la question de la stratégie omni-canale adoptée (ou non) par leurs commerçants ! En progression constante, le m-commerce ne représente pourtant que 7 % de la vente en ligne : ce faible pourcentage s'explique avant tout par la frustration vécue par les consommateurs durant le parcours d'achat sur mobile. Pourquoi la frustration ? Le plus souvent parce que l’application plante : 70% désinstallent une application instable après une seule utilisation, ce qui fait du crash le bug le plus rédhibitoire. Bon nombre d'autres anomalies altèrent l'expérience digitale des utilisateurs. Il est donc impératif qu'ils se sentent en confiance lorsqu’ils utilisent une application, d’où l'importance du test, garant de la qualité, malheureusement trop souvent sous-estimé ou incompris.
Penchons-nous sur quelques idées préconçues qui portent préjudice au test :
- Le test d’application mobile est chronophage et coûteux, " On testera si on a le temps ", "cela reste une bonne pratique", entend-on très souvent. Pourtant, s'il est intégré au plus tôt dans le développement du projet, le test sera plus efficace, moins cher et apportera de bons résultats.
- Les utilisateurs vous remonteront les bugs. Certes, certains utilisateurs vous feront un retour d'expérience mais vos utilisateurs ne sont pas des testeurs. Ils n’ont ni les outils ni l’expertise pour le faire, ils veulent simplement utiliser votre produit.
- Les développeurs testent et débuguent ce qu’ils ont conçu, c'est suffisant pour garantir la qualité de l'App. Attention, les développeurs ne sont pas des experts Qualité : il leur manque un regard objectif sur leurs développements et la capacité de se mettre à la place de l'utilisateur final. Surtout, le test utilisateur n'est pas leur métier. Seuls des testeurs expérimentés sauront faire des retours quantitatifs (liste des bugs) et qualitatifs (ressenti utilisateur) sur un projet en développement.
- Un test réussi sur un device garantit que l’application fonctionne sur tous les autres appareils du même OS. Faux, compte tenu de la fragmentation de l’environnement digital actuel (tailles d'écrans, résolutions, versions d'OS), les risques sont d'autant plus importants. Tester sur une large variété d'appareils n’est pas un plus, c’est obligatoire.
- Le test d'application mobile, c'est comme le test de site web. Encore faux : il doit être traité différemment en raison des spécificités propres à la mobilité : soumission, installation, performance, connexion (WiFi, 3G/4G), interruptions (appel, message), ergonomie, mémoire, multi-devices (smartphone, tablette, phablet)…
Le Test, Garant indéniable de la qualité des applications mobiles
Anticiper, définir et organiser une stratégie de test avant le lancement d'une application mobile est vitale. Ne pas prendre en compte l’Assurance Qualité correctement, ou la faire à la va-vite, c'est ne pas prendre en considération ce qui est véritablement en jeu : une perte de confiance des utilisateurs, une dégradation de l'image de marque, une perte de revenus. Le bénéfice d’une QA structurée l’emporte largement sur le coût de sa mise en œuvre. Plus on attend pour corriger le bug, plus il coûte cher ! En somme, il vaut mieux prévenir que guérir.
