Un test mobile n'est utile que si son environnement l'est également. 

Votre équipe a réalisé un test mobile pour le parcours de paiement. Ce test est concluant sur le téléphone utilisé pour sa création. Avant la prochaine mise en ligne, on vous demande si ce même parcours fonctionne sur les appareils et systèmes d'exploitation utilisés par vos clients. C'est à ce moment que la conversation se déplace du test lui-même vers son environnement. 

L'inverse est également possible. Une équipe peut disposer de nombreux appareils, mais d'aucune méthode reproductible pour transformer ses parcours utilisateurs les plus importants en tests. Dans les deux cas, il n'existe pas de solution universelle. Il est essentiel de considérer la création des tests et l'accès aux appareils comme des décisions interdépendantes lors de la planification des tests mobiles. 

Votre équipe est-elle capable de créer des tests qu'elle aura envie de maintenir ? 

Un test mobile doit reproduire un parcours utilisateur pertinent : connexion, passation de commande, paiement d’une facture ou reprise après une interruption de session. Créer une première version est utile. Maintenir cette pertinence malgré les modifications d’écrans, d’étiquettes et de comportement de l’application représente un travail de plus longue haleine. 

Réfléchissez aux personnes qui rédigeront les tests. Les personnes qui comprennent le parcours utilisateur pourront-elles y contribuer ? Un autre membre de l’équipe peut-il consulter le flux de travail et en comprendre les vérifications ? Si un test échoue après une mise à jour de l’application, l’équipe peut-elle déterminer si l’application a été modifiée ou si le test nécessite une attention particulière ? Ces questions, plus que la rapidité d’une première démonstration, déterminent la pertinence d’une approche de rédaction. 

Une organisation peut déjà disposer d'une plateforme d'automatisation utilisée dans d'autres secteurs de l'entreprise. Étendre cette approche éprouvée au mobile peut s'avérer judicieux, à condition qu'elle soit compatible avec les applications et les appareils que l'équipe doit valider. Une autre organisation peut être en train de définir sa stratégie de création de contenu mobile. Dans les deux cas, il est important d'évaluer comment les tests seront maintenus une fois le projet initial terminé. 

Ces tests peuvent-ils être exécutés là où ils sont nécessaires ? 

La prochaine étape concerne l'environnement. Quels modèles d'appareils et versions de systèmes d'exploitation sont importants pour vos utilisateurs ? Quels flux nécessitent du matériel physique plutôt qu'un appareil virtuel ? Qui a besoin d'y accéder et quand les appareils seront-ils disponibles pour le déploiement ? 

La solution peut consister en un laboratoire interne existant, des appareils hébergés par un fournisseur, ou une combinaison de ces options. Chaque solution implique des tâches opérationnelles. Les appareils doivent être provisionnés, mis à jour, configurés pour l'application et mis à la disposition des équipes concernées. Une ferme d'appareils peut répondre à ce besoin, mais son intérêt dépend de son adéquation avec la couverture de test et le calendrier de déploiement de l'organisation. 

Il n'y a aucune raison de supposer qu'une équipe doive remplacer un laboratoire performant. La question pertinente est de savoir si son environnement actuel peut prendre en charge la couverture, l'accès et le contrôle attendus à mesure que les tests mobiles se développent. En particulier, un test qui attend un appareil ou qui s'exécute sur une configuration différente de celle prévue réduit la confiance de l'équipe dans ses résultats. 

Le lien compte autant que n'importe quel choix. 

Un outil de création et un environnement de test ne constituent un flux de travail de test que s'ils sont compatibles. Un test doit pouvoir atteindre l'appareil cible, s'exécuter sur la version appropriée de l'application et fournir à l'équipe suffisamment d'informations pour comprendre le problème. Cette compatibilité mérite une attention particulière dès le début, avant que l'augmentation du nombre d'outils de test ne rende les modifications coûteuses. 

C’est pourquoi le choix ne doit pas se limiter à la question : « Quel outil écrit nos tests ? ». Il faut s’interroger sur le parcours de l’auteur du test jusqu’à l’appareil pour l’équipe qui l’exploitera. Il convient de déterminer la configuration nécessaire, les responsables et la procédure d’investigation en cas de panne. 

Planifiez l'intégralité du parcours, du test au résultat. 

Commencez par définir un petit ensemble de parcours mobiles essentiels. Déterminez comment l'équipe créera et maintiendra ces tests, puis associez chacun d'eux aux appareils et aux conditions qu'il doit couvrir. Vérifiez que la méthode de création est compatible avec l'environnement choisi et que l'équipe peut répéter l'exécution lorsqu'une version en dépend. 

Voilà le test pratique d'une stratégie de test mobile : Votre équipe est-elle capable de créer les tests nécessaires, de les exécuter sur les appareils requis et de comprendre suffisamment bien les résultats pour pouvoir agir ?  

Deuxième partie de notre série d'articles de blog sur UiPath examine une façon de connecter ces éléments avec UiPath et Digital.ai Essai.