Définition des tests de logiciels mobiles

Trop souvent, je vois les parties prenantes du projet et les testeurs se référer à la tâche de tester un projet ou une application de logiciel mobile comme à des « tests mobiles ». Mais les tests mobiles sont un vaste sujet avec quatre types d’architecture distincts.

Les projets de test mobile comprennent une application (app) mobile native, une application mobile hybride, une application Web mobile et un site Web mobile.

Levons l’ambiguïté de la discussion et distinguons ces quatre types de projets de test mobile et examinons les tests distinctifs basés sur chaque type.

Application hybride

J’aime la définition de Julian Harty : « une application hybride est une combinaison de code natif – souvent écrit par une personne, mais pouvant être écrit par un générateur de code ou fourni dans le cadre d’une application générée par un générateur de code – et d’un contrôle de vue Web intégré à cette application. L’application comprend donc deux technologies, une vue Web, où le HTML, le JavaScript ou le CSS sont rendus et traités, et un code natif, qui fournit le reste de la fonctionnalité et de l’interface utilisateur. »

Le traitement dans une application hybride utilise à la fois le processeur du serveur Web et le processeur de l’appareil et, par conséquent, des types de tests spécifiques doivent être conçus et mis en œuvre pour le projet de test des applications hybrides. Lors de la conception des cas de test, le testeur doit tenir compte du moment où le code natif est invoqué et où le code interagit avec le code de la vue Web. Les concepteurs de tests doivent avoir une connaissance architecturale du fonctionnement du système, y compris des interdépendances au sein du code. Tous les types de projets de tests mobiles doivent tenir compte de la synchronisation.

Cependant, avec les applications hybrides, les tests de synchronisation peuvent devenir plus complexes en raison de la conception architecturale. Les testeurs doivent savoir quand on accède au code de la vue Web, quand on accède au code natif, et comment les conditions du matériel et du micrologiciel affectent l’application logicielle.

Par exemple, comment se comporte l’application sur l’appareil lorsqu’elle se charge, se connecte à une base de données Web, effectue une recherche dans la base de données, puis accède aux données à afficher dans l’application ? Ajoutez le temps comme condition à ce test, y compris l’accès à l’application elle-même, la connexion à un serveur Web, la réalisation d’une recherche, la transmission des données à l’application et leur affichage. Quels types de graphiques doivent être affichés dans chaque phase de l’objectif ? Ces graphiques sont-ils du code natif ou sont-ils intégrés dans le code CSS, JavaScript ou HTML ? La complexité de l’interaction des deux types de technologies dans un même but rend les tests uniques à l’application mobile hybride.

Application native

Le code des applications natives est contenu dans l’appareil. Tout le code est téléchargé sur l’appareil, tout le traitement est effectué par l’unité centrale de l’appareil, et l’application ne contient pas de code HTML, JavaScript ou CSS. L’interface graphique affichée n’utilise pas de navigateur Web ni de connexion à Internet. Une application native peut interagir avec l’Internet, mais uniquement dans le but d’envoyer des données de l’appareil à une autre application. Aucun traitement de données n’est effectué en dehors de l’application native existant sur l’appareil.

Il s’agit d’une application autonome, dont le fonctionnement dépend du micrologiciel et du matériel de l’appareil. Comme pour l’application hybride, les tests relatifs aux conditions du matériel et du micrologiciel jouent un rôle important dans la conception des scénarios de test. Cependant, l’objectif des cas de test reste strictement dans les limites de l’appareil lui-même. Il existe bien sûr des tests de communication, mais ils sont limités par rapport à une application hybride. Ainsi, davantage de tests couvriront les interactions entre le code et l’appareil lui-même.

La température de la batterie de l’appareil joue un rôle plus important pour la fonctionnalité de l’application native, car le traitement génère également plus de chaleur dans un espace restreint – l’appareil.

Les tests de charge pour les applications natives ne sont pas définis de la même manière que pour les tests des applications hybrides, des sites Web et des applications Web. Les applications natives n’ont qu’un seul utilisateur, qui constitue la « charge ». Cependant, il existe d’autres types de charge à prendre en compte dans les tests. Qu’en est-il de la charge sur la vitesse du processeur pendant que l’application native exécute une fonction ? Il y a une charge provenant d’autres applications fonctionnant en arrière-plan pendant que votre application native est utilisée/en cours/active. Il est essentiel de tenir compte des ressources propres à l’appareil lors de la conception de tests d’applications natives.

Les applications natives n’ont pas la même dépendance en matière de sécurité car l’interaction en dehors de l’appareil ne fait pas partie de la fonctionnalité. Les applications natives peuvent envoyer/recevoir des données par le biais de transmissions sans fil, qui doivent faire l’objet de tests de sécurité pour l’intégrité des données, mais si la transmission de données n’est pas une priorité élevée, les tests de sécurité seront moins importants.

Les tests d’applications natives exigent que le testeur tienne compte de différents types d’appareils lorsqu’il construit un laboratoire de test. De nombreux tests conçus pour les applications natives nécessitent des tests directs sur les appareils et ne peuvent être émulés ou simulés. La planification d’un laboratoire de test devient alors une partie importante des projets d’applications natives.

Applications Web mobiles

Les applications Web mobiles dépendent de l’interaction avec l’utilisateur pour atteindre leur objectif. L’expérience utilisateur est donc différente entre les projets logiciels d’applications Web mobiles et de sites Web mobiles. Pour mieux comprendre la différence, regardez le site Web mobile d’un restaurant et comparez-le à un site Web de vente au détail comme Amazon.com. Appliqueriez-vous les mêmes tests aux deux types d’entités mobiles ? Bien sûr, le site du restaurant peut inclure un formulaire à remplir, mais le site Web ne demande pas à l’utilisateur de remplir son objectif, qui est d’afficher des informations sur le restaurant lui-même.

L’attention portée à la sécurité, à la validation des données, à la charge, au stress à plusieurs niveaux, à la fonctionnalité, à la communication réseau, à la compatibilité des navigateurs et aux tests des transporteurs sera très importante. Si l’on ajoute l’utilisabilité, la formabilité et la désirabilité, le test de la valeur et de l’utilité des applications Web dans un environnement mobile est plus complexe que le test d’un site mobile. L’état des appareils n’est pas une priorité absolue. L’application elle-même ne changera pas ou n’aura pas de problèmes en fonction de la consommation de la batterie. Cependant, l’application Web doit tenir compte des ressources du dispositif et se documenter en conséquence.

Sites Web mobiles

Les sites mobiles sont conçus spécifiquement pour s’afficher sur une petite surface de visualisation. Par conséquent, il y a peu ou pas d’interaction avec l’utilisateur, si ce n’est la modification de ce qui est affiché en fonction du contenu du site Web.

Les tests effectués sur les sites Web mobiles visent à déterminer si le site est agréable pour l’utilisateur, s’il est facile d’accès pour l’utilisateur compte tenu de la compatibilité du navigateur, s’il est sûr à afficher sur l’appareil de l’utilisateur et s’il fonctionne comme prévu. Les images et le texte s’affichent-ils dans une couleur et une taille favorables ? Le contenu s’affiche-t-il bien sur un écran plus petit ? Le site mobile se charge-t-il en un temps raisonnable ? Peut-il se charger malgré un trafic important sur le site Web ou sur les supports mobiles ?

Types de tests

Des tests communs sont appliqués aux projets de tests mobiles et chaque environnement fournit des tests spécifiques à chacun. N’oubliez pas de différencier le type de test mobile dont il est question et évitez toute ambiguïté. Chaque type de projet mobile a une perspective distincte et exige du testeur qu’il planifie en conséquence.