Tutoriel de test de l'interface utilisateur mobile (test de l'interface graphique des applications iOS et Android)

mobile ui testing tutorial gui testing ios

Guide de test de l'interface utilisateur des applications mobiles: découvrez comment effectuer des tests de l'interface utilisateur iOS et Android

Avec le marché florissant des mobiles, les tests d'applications mobiles sont devenus passionnants de jour en jour.

comment afficher les fichiers .json

En exécutant simplement des tests fonctionnels sur une application mobile, vous ne pouvez pas vous déconnecter de l'application. Il y a peu d'autres types de tests comme les tests sur le terrain, les tests de réseau, les tests d'interface utilisateur, les tests de durée de vie de la batterie, etc., qui doivent être effectués.

Les tests d'interface utilisateur sont l'un des tests importants des tests d'applications mobiles et ils ne doivent pas être pris à la légère.

L'interface utilisateur graphique crée une grande différence dans la façon dont un utilisateur trouve votre application intéressante et interactive. L'importance d'une interface graphique décente et attrayante peut être ressentie de manière plus significative dans un environnement d'appareil intelligent où la taille de l'écran est beaucoup plus petite que celle d'un ordinateur portable ou d'un écran de bureau.

Ce que vous apprendrez:

• Importance du test de l'interface utilisateur des applications mobiles
• Comment décider de combien de tests d'interface utilisateur sont nécessaires?
• Consignes: éléments à tester dans les tests d'interface utilisateur des applications mobiles
  • # 1) Résolution d'écran
  • # 2) Taille de l'écran
  • # 3) Différents éléments de l'interface utilisateur
  • # 4) Style: schéma de couleurs et de thèmes de l'appareil
  • # 5) Multi-touch ou Single Touch
  • # 6) Presse longue ou courte
  • # 7) Emplacement
• Comment tester les variations de l'interface utilisateur sur différentes versions de système d'exploitation?
• Appareils réels ou émulateurs: que choisir pour les tests d'interface utilisateur?
  • Avantages
  • Les inconvénients
• Test d'interface utilisateur manuel ou automatisé?
• Outils de test de l'interface utilisateur des applications mobiles
• Liste de contrôle pour tester l'interface utilisateur de l'application mobile
• 5 mythes sur les tests automatisés de l'interface utilisateur mobile
  • Mythe 1: la vitesse
  • Mythe 2: Couverture
  • Mythe 3: Coût
  • Mythe 4: cohérence
  • Mythe 5: la réticence
• Le mythe et la réalité
• Conclusion
• lecture recommandée

Importance du test de l'interface utilisateur des applications mobiles

En tant qu'utilisateur, aurez-vous envie d'utiliser une application qui manque d'interaction avec l'utilisateur et qui rend difficile la compréhension de son utilisation?

Lorsque les utilisateurs utilisent une application mobile pour la première fois, ce ne sont pas seulement les performances qui attirent l'attention, mais aussi l'interface utilisateur attrayante. Une application conviviale pour l'interface utilisateur se vend plus par rapport à une application qui est mieux développée mais avec une interface utilisateur désagréable.

Si une application a une interface utilisateur parfaite et splendide sur un appareil mais que sur l'autre appareil, elle est complètement tordue simplement parce qu'elle a une taille différente ou un système d'exploitation différent, cela laissera une très mauvaise impression. Le succès commercial de l'application sera gravement affecté.

Ferez-vous la promotion d'une application où le bouton est trop petit pour cliquer et bloque l'ensemble des fonctionnalités?

Ces expériences ne sont-elles pas désagréables pour les utilisateurs? En raison des cas mentionnés ci-dessus, il devient très important de tester l'interface utilisateur d'une application. Les deux principales vérifications à effectuer pour les applications mobiles sont la convivialité et l'apparence des différents modèles et versions de système d'exploitation.

Voici un exemple de la façon dont l'interface utilisateur devrait être parfaite sur différentes tailles d'écran:

Comment décider de combien de tests d'interface utilisateur sont nécessaires?

Le graphique suivant indique les différents secteurs verticaux dans lesquels les applications mobiles peuvent être classées:

(image la source )

À partir du graphique ci-dessus, vous pouvez voir que les applications de jeu occupent la majorité de la part de marché d'environ 24,43%, puis sont suivies par les applications professionnelles et éducatives.

• Les applications développées en tant qu'applications de jeu nécessitent des tests approfondis à tous les niveaux, car l'interface utilisateur est le plus grand contributeur au succès, qu'il s'agisse d'une application native ou hybride
• Une application d'entreprise peut ne pas s'appuyer entièrement sur l'interface utilisateur pour son succès, car dans la plupart des cas, le public cible est formé à l'utilisation de l'application. Par conséquent, ces applications peuvent avoir une interface utilisateur simple.
• Les applications développées à des fins éducatives nécessitent des tests d'interface utilisateur approfondis.
• Les applications commerciales telles que les achats, les voyages, etc. nécessitent également des tests d'interface utilisateur complets sur les appareils et différentes versions de système d'exploitation.

En bref, en fonction de l'objectif de l'application, la profondeur des tests d'interface utilisateur peut être décidée, mais les tests d'interface utilisateur doivent toujours être effectués sur au moins 3 versions de système d'exploitation différentes.

Consignes: éléments à tester dans les tests d'interface utilisateur des applications mobiles

Lors du test de l'interface utilisateur sur une application mobile, diverses caractéristiques doivent être vérifiées.

Voici quelques-unes des caractéristiques à tester pour chaque application:

#1) Résolution d'écran

Voici quelques-unes des résolutions d'écran courantes prises en compte lors de la création de bancs de test:

• 640 × 480
• 800 × 600
• 1 024 × 768
• 1 280 × 800
• 1366 × 768
• 1 400 × 900
• 1680 × 1050

Toutes ces résolutions sont indispensables pour les tests lorsque vous avez une mise en page à plusieurs colonnes dans votre application.

Par conséquent, la vérification doit être effectuée en commençant par la résolution la plus petite à la plus grande. En dehors de cela, si votre application a une longue liste de cartes avec des informations, celles-ci doivent également être testées sur une résolution différente pour leur emballage d'informations.

( source d'image )

# 2) Taille de l'écran

Il existe trop de variations dans les tailles d'écran et les résolutions disponibles. Dans les appareils intelligents en particulier, les tailles des contrôles ne sont pas statiques, elles sont liées à la taille d'écran disponible.

Lors du test, assurez-vous que la taille des contrôles est esthétiquement bonne et que le contrôle est complètement visible à l'écran sans aucun défilement. Testez l'interface graphique sur différents appareils avec différentes tailles d'écran et résolutions.

Les émulateurs sont bons à cet effet, mais rien ne correspond à l'appareil réel. Assurez-vous donc de tester au moins deux ou trois appareils réels. N'oubliez pas non plus de tester les orientations paysage et portrait si l'appareil le prend en charge.

Vous devez tester l'application avec des résolutions couramment utilisées pour garantir sa convivialité.

Voici quelques éléments que vous devez comprendre:

La différence entre la taille de l'écran et la résolution: La taille de l'écran est la longueur de l'écran en pouces mesurée en diagonale ou d'un coin à un autre coin de l'écran. La résolution de l'écran est la largeur et la hauteur, Exemple 640w × 480h qui représente le nombre de pixels traversant l'écran multiplié par plusieurs pixels descendant.

# 3) Différents éléments de l'interface utilisateur

Les éléments de l'interface utilisateur tels que les boutons, les en-têtes, les icônes, les images, les champs de sélection, les champs de texte, les cases à cocher, etc., sont quelques-uns des différents éléments qui doivent être vérifiés pour leur apparence et leur taille à l'écran.

En particulier pour les champs de texte, si le clavier virtuel apparaît au toucher dans le champ de texte, il doit être testé et vérifié.

Plus important encore, des tests approfondis de la taille des boutons sont nécessaires car je me souviens que dans notre application lors des tests sur le téléphone Galaxy S, nous avons trouvé un bloqueur où un bouton avait bloqué toute l'application simplement parce que le bouton semblait trop petit pour cliquer.

La position des éléments de l'interface utilisateur doit également être vérifiée par rapport à l'exigence, c'est-à-dire si tous doivent être alignés au centre ou à gauche, etc.

# 4) Style: schéma de couleurs et de thèmes de l'appareil

L'interface utilisateur et le schéma de couleurs de l'application doivent être cohérents avec les différentes couleurs et schémas de thème du téléphone. La couleur et le thème d'un téléphone Samsung sont très différents de ceux de Nokia ou du téléphone MI .

Par conséquent, vous devez vérifier si l'application est cohérente sur ces téléphones.

Votre application a un design spécifique. Et le style des commandes doit correspondre à cette conception. Vous avez peut-être vu de nombreuses applications où certains contrôles, par exemple les panneaux ont des bords arrondis et d'autres commandes, par ex. les zones de texte ont des arêtes vives.

Bien que ce type de problèmes n'affecte pas la convivialité ou la fonctionnalité de l'application, une apparence cohérente de l'application permet de créer une relation conviviale entre l'application et l'utilisateur.

L'une des choses les plus importantes dans le style est la police des différentes pages. La police doit être bien testée pour éviter toute incohérence dans l'aspect et la convivialité de l'application.

La plupart du temps, nous nous concentrons sur le texte qui est visible dans des situations normales et ignorons le texte qui apparaît dans des situations spécifiques. Les messages de réussite et d'échec sont un exemple de ce type de texte.

Un autre facteur important dans le style est la relation entre la couleur de la police et la situation dans laquelle le texte est affiché.

Par exemple, La couleur rouge est utilisée pour les messages d'erreur, le vert pour le succès, le jaune pour les avertissements et le bleu pour les hyperliens.

# 5) Multi-touch ou Single Touch

Si votre application prend en charge la fonctionnalité multi-touch telle que pincer pour zoomer ou pincer pour rétrécir, etc., vous devez tester minutieusement cette fonctionnalité et créer de nombreux cas de test pour tous les écrans applicables.

# 6) Presse longue ou courte

Un appui long sur une icône affiche le menu contextuel tandis qu'un appui court effectue la toute première action du menu. Si cette fonctionnalité est fournie dans votre application, vous devez vérifier cette fonctionnalité et toutes les fonctionnalités qui l'entourent.

# 7) Emplacement

L'emplacement et la position sont les deux mots qui sont utilisés alternativement et, fait intéressant, ils sont également utilisés pour transmettre deux concepts différents qui sont expliqués ci-dessous:

1) Parfois, c'est la zone de l'écran où apparaît un contrôle.

Par exemple, L'en-tête se trouve sur Haut de la page, les étiquettes sont Aligné à gauche , et les zones de texte sont Aligné à droite, etc. Ici, «haut», «aligné à gauche» et «aligné à droite» sont des positions relatives des commandes.

deux) Parfois, c'est l'ordre de contrôle parmi les autres contrôles.

Par exemple, lors de l'obtention d'informations personnelles, le prénom est suivi par le nom de famille. Ou, le format des contrôles pour demander une adresse aux États-Unis doit être au format ordre - Code postal, ville, état.

Pour ces deux situations, nous parlons de l'emplacement des commandes.

Lorsque vous testez l'emplacement et la position des commandes, assurez-vous que tout est logiquement placé sur l'écran et montre un bon sens esthétique.

Il existe des situations dans lesquelles une ou plusieurs commandes apparaissent sur plusieurs écrans. Dans cette situation, vous devez vous assurer qu'ils apparaissent au même emplacement et dans le même ordre relatif sur toutes les pages.

Comment tester les variations de l'interface utilisateur sur différentes versions de système d'exploitation?

L'interface utilisateur varie avec la version du système d'exploitation et avec le lancement d'une nouvelle version, des améliorations sont apportées à l'interface utilisateur.

Observons l'interface utilisateur des 3 derniers OS actuellement disponibles et comprenons comment ces variations affectent une application mobile.

Elles sont:

1. Sucette
2. Guimauve
3. Nougat

En regardant la liste ci-dessus des nouvelles fonctionnalités d'interface utilisateur ou de fonctionnalité, en tant que QA, vous devez concevoir des cas de test autour de cela.

1) Sucette:

• Créez des scénarios de test pour l'effet du nouveau design sur votre application.
• Pas nécessairement pour tous les écrans, mais créez des cas de test pour accéder aux nouveaux raccourcis de votre application.

2) Guimauve:

• Si votre application traite des emojis, créez des cas de test pour vérifier les nouveaux emojis. Les applications qui permettent aux utilisateurs d'écrire des critiques ou de discuter sont celles qui utilisent fréquemment des émojis.
• Lorsque votre application est publiée et installée pour la première fois, elle peut avoir besoin de demander l'autorisation, d'où la nécessité de tester l'interface utilisateur du nouvel écran d'autorisation. Et créez des cas de test pour le même.
• Si votre application utilise Google Now, vous devez créer des scénarios de test pour tester l'interface utilisateur de la fonctionnalité Google Now mise à jour.

3) Nougat:

• Des tests approfondis de votre application doivent être effectués pour le mode réalité rêverie et donc créer des cas de test en conséquence.
• Créez des scénarios de test pour vérifier les options de menu de votre application.
• Si votre application traite des émojis et des GIF, créez des cas de test pour vérifier les nouveaux émojis et l'option d'envoyer des GIF.

Appareils réels ou émulateurs: que choisir pour les tests d'interface utilisateur?

Lorsque vous devez tester une application mobile, vous pouvez penser à ce que devrait être le banc d'essai?

Que ce soit pour tester sur un appareil réel ou un émulateur ou les deux? Il n'y a pas de réponse ferme à cela, car le choix dépend de ce que vous voulez tester.

Pour tester la fonctionnalité, les performances, la réponse du réseau, le test sur le terrain, etc., vous devez toujours préférer un appareil réel. Mais pour des choses comme l'interface utilisateur, vous devez choisir des émulateurs avec de vrais appareils.

Avantages

Les avantages de l'utilisation d'émulateurs pour les tests d'interface utilisateur sont:

1) Il n'est pratiquement pas possible de rassembler les appareils de toutes les résolutions et cela coûterait également une somme énorme. Mais les émulateurs ne coûtent rien.
deux) Avec un émulateur, vous pouvez créer toutes les combinaisons de résolution d'écran et de système d'exploitation.
3) Si vous ne possédez qu’un seul ensemble d’appareils réels mais que l’équipe de contrôle qualité est composée de plus d’une personne, tous les contrôleurs ne peuvent pas tester le même banc de test en parallèle. Avec un émulateur, chaque QA peut créer la même combinaison sur sa machine et tester en parallèle.
4) Les tests sur un émulateur prennent moins de temps et sont plus rapides par rapport à un appareil réel.
5) Les bogues courants liés à l'interface utilisateur tels que l'alignement, etc. peuvent être facilement détectés sur les émulateurs.

Les inconvénients

Les inconvénients comprennent:

différence entre les commandes unix et linux

1) Les gestes ne peuvent pas être testés sur les émulateurs. Un seul geste peut être émulé à la fois.
deux) Les entrées physiques du GPS, du réseau en baisse ou faible, etc. ne peuvent pas non plus être testées.
3) Il est impossible de créer un émulateur pour les téléphones Sony, LG, Nexus, etc.
4) Il n'est pas possible de créer un environnement réel avec une batterie faible ou une mémoire faible, etc., sur l'émulateur.

Par conséquent, la décision doit être prise en fonction de votre application et des exigences de test.

Test d'interface utilisateur manuel ou automatisé?

Aucun produit, qu'il s'agisse d'une application de bureau, d'une application Web ou d'une application mobile, ne peut être publié sans test. En tant que QA, nous avons du mal à trouver et signaler chaque défaut, mais ils sont néanmoins signalés par les clients.

Est-ce que tu sais pourquoi?

Parce que de longs tests qui sont souvent évités ou manqués laissant ainsi des bogues non détectés. De plus, une couverture à 100%, une exécution approfondie n'est pas possible avec des tests manuels.

Les tests d'interface utilisateur sont assez simples et directs et il vous suffit de regarder comment cela apparaît à vos yeux. Maintenant, si cela est fait manuellement, cela prend beaucoup de temps. De plus, la plupart du temps, nous devons créer d'énormes données pour les tests d'interface utilisateur, comme un parchemin n'apparaîtra que si les lignes de cartes croisent un nombre particulier.

La création de Big Data prend beaucoup de temps. Avoir une suite automatisée peut résoudre les deux problèmes.

Au contraire, si les fonctionnalités ou l'interface utilisateur de l'application sont encore dans une phase de changement, cela n'a pas de sens d'investir dans l'automatisation. De même, si les fonctionnalités de l'application sont vitales, il est préférable de tester manuellement.

Par conséquent, en fonction des pointeurs suivants, vous devez décider de tester manuellement ou d'automatiser:

• La nature de votre application.
• La stabilité de votre application.
• Les ressources disponibles comme la main-d'œuvre pour étudier les outils et les comparer.
• Combien de temps faut-il consacrer à l'étude et à la montée en puissance d'un outil d'automatisation?
• Le client est-il prêt à investir du temps dans la montée en puissance et l'étude?

Outils de test de l'interface utilisateur des applications mobiles

Voici une liste de 5 outils pouvant être utilisés pour tester l'interface utilisateur d'une application mobile pour Android et / ou iOS.

(Pour les outils de test de fonctionnalité y Vous pouvez vous référer à la liste des outils d'automatisation sur notre automatisation outils de test des applications Android page).

# 1) Selendroid

Selendroid est l'un des outils les meilleurs et les plus recommandés pour l'automatisation des applications mobiles pour les tests d'interface utilisateur.

Il peut être utilisé pour les applications natives et hybrides. Il ne peut être utilisé que pour les applications Android et les tests d'API client sont écrits à l'aide de Selendroid 2. Il peut également être utilisé avec plus d'un appareil et est entièrement compatible avec JSON.

# 2) Testdroid

Il s'agit d'un outil basé sur le cloud et peut être utilisé pour une variété d'appareils, différentes résolutions d'écran et versions de système d'exploitation à la fois Android et iOS. Les tests d'appareils parallèles sont un gros avantage de cet outil et un bon outil pour les tests d'interface utilisateur. Il aide les développeurs à améliorer le délai de mise sur le marché.

# 3) SeeTest

C'est un outil payant et peut être utilisé pour Android, iOS, Windows, Symbian, etc.

C'est un outil multiplateforme et donc l'avantage est que le même test peut être exécuté sur toutes les plateformes. Il peut être utilisé pour toutes les applications mobiles et les tests peuvent être exécutés en parallèle sur plus d'un appareil.

# 4) Automatisation de l'interface utilisateur

Il s'agit de l'outil de test officiel de l'interface utilisateur pour Apple et du meilleur outil pour automatiser les applications iOS. Bien qu'il soit difficile à apprendre, il offre un grand avantage avec les bibliothèques, les performances, les tests d'interface utilisateur, etc.

# 5) Calebasse

Il peut être utilisé pour les tests Android et iOS pour les applications natives ou hybrides. C'est un outil multiplateforme et il est mieux utilisé pour automatiser les gestes, les captures d'écran, les assertions, etc. Il peut être utilisé sur de vrais appareils à écran tactile. Il prend également en charge le concombre.

Lorsque les développeurs testent l'application de manière unitaire, ils peuvent également effectuer des tests d'interface utilisateur à l'aide d'Android Studio, mais cela ne peut être utilisé que pour les applications Android.

Lecture recommandée => Automatisez les tests d'interface utilisateur

Liste de contrôle pour tester l'interface utilisateur de l'application mobile

Vous trouverez ci-dessous la liste de contrôle pour les testeurs afin de garantir que l'interface graphique est parfaitement testée sur les appareils intelligents:

5 mythes sur les tests automatisés de l'interface utilisateur mobile

Les tests automatisés de l'interface utilisateur mobile sont considérés comme cruciaux lorsque la question du succès des applications se pose. Mais il existe certains mythes liés aux tests automatisés.

Ces mythes peuvent ne pas être vrais parce qu'ils peuvent être superficiels. Plonger profondément dans le processus de test automatisé le fait disparaître. Explorons-les plus en profondeur.

Mythe 1: la vitesse

Ce mythe est très courant. La plupart des personnes liées aux industries informatiques ont un mythe selon lequel effectuer des «tests d'automatisation» prend plus de temps que des «tests manuels». Ce fait est vrai dans une certaine mesure dans quelques scénarios.

La raison en est que les tests manuels produisent des résultats rapides par rapport aux tests automatisés de l'interface utilisateur mobile. Mais ce n'est le cas que dans les étapes préliminaires et initiales.

Avec des tests répétés, vous avez besoin soit d'ajouter beaucoup plus de fonctionnalités de test, soit de diminuer les qualités de test. Alors qu'avec les tests automatisés, vous exécutez toujours des niveaux de test similaires à chaque fois, ce qui vous permet de gagner du temps à long terme.

Mythe 2: Couverture

Dans le scénario actuel, de nouveaux appareils Android sont régulièrement lancés sur les marchés. Et le nombre d'applications de ces systèmes d'exploitation (OS) augmente. Ensuite, il existe des systèmes d'exploitation tels que iOS qui ont encore plus d'applications conçues pour un usage quotidien.

Le test manuel de tant d'applications devient très difficile. Mais en cas de test automatisé, la maintenance des serveurs cloud suffit. Avec l'aide de tests automatisés, une couverture de test totale et complète des applications est possible.

Mythe 3: Coût

C'est un fait que les tests automatisés des applications coûtent plus cher que les coûts des tests manuels. Cependant, cela n’est vrai que si des tests sont effectués sur l’essentiel de l’application. Au fur et à mesure que l'environnement de l'application et le logiciel se compliquent, les tests manuels deviennent plus chers.

En effet, des outils plus sophistiqués sont nécessaires pour des résultats de test optimaux. Parallèlement à ces outils de test sophistiqués, il existe un besoin de personnel hautement qualifié capable de gérer ces outils. Cela nécessitera de les former.

Les tests manuels deviennent donc plus coûteux par rapport aux tests automatisés.

Mythe 4: cohérence

Dans le cas des tests manuels, il y a toujours de la place pour des perceptions différentes qui varient d'un testeur à l'autre. Cela dépend également des tests considérés, des environnements et des applications ainsi que du système d'exploitation (OS).

Lorsque vous appliquez des tests manuels au logiciel, il y a des trous par lesquels peu de bogues peuvent passer. Par conséquent, les tests manuels ne sont utiles que pour détecter les bogues de base. Les tests automatisés s'exécutent sur les scripts sans possibilité de variation de perception, ce qui le rend infaillible.

Mythe 5: la réticence

Il est faux de dire que les tests automatisés ont remplacé les êtres humains, mais plutôt pour l’amélioration des testeurs manuels. Les tests automatisés fournissent des résultats automatisés à plusieurs reprises, plusieurs fois avec une précision maximale. Alors la question se pose, pourquoi il y a un besoin d'humains?

Les tests automatisés nécessitent la rédaction de scripts et la planification de l'ensemble de la procédure de test. Cette tâche nécessite un effort humain. La procédure de test automatisé permet d'économiser du temps et de l'argent de sorte que vous utilisiez ces ressources pour améliorer les procédures de test manuel. Le développement de meilleurs outils contribuera à son tour à faire progresser les procédures déjà existantes de tests automatisés.

Ci-dessus, quelques-uns des mythes les plus répandus qui prévalent dans l'industrie des tests automatisés. Cela doit être éradiqué pour améliorer les tests automatisés de l'interface utilisateur mobile.

Le mythe et la réalité

Le fait est que même les sociétés de développement les plus sophistiquées utilisent des tests manuels pour les mobiles, ou ne réalisent pas du tout de tests complets. Selon les enquêtes Xamarin 2014, 13,2% des développeurs de mobiles effectuent des tests sur des interfaces utilisateur automatisées. Selon les études de Forrester Research, seulement 53% des développeurs effectuent des tests superficiels sur des appareils uniques.

Les cinq facteurs les plus courants expliquant pourquoi les équipes de mobiles n'ont pas les qualités automatisées des applications mobiles et cinq raisons expliquant pourquoi celles-ci ne sont pas simplement logiques sont les suivants:

a) La vitesse est le premier mythe.

Une personne ne peut pas prendre de temps pour l'automatisation. En 2014, les fournisseurs avaient introduit 7 000 nouveaux types d'appareils Android. Ensuite, il y a eu 10000 API spécifiques pour les mobiles. Les applications mobiles sont expédiées plus rapidement et se modifient rapidement. Avec l'assurance qualité (QA) dans des modes d'analyse constants, il n'y a pas de temps pour créer des scripts de test, en les maintenant synchronisés avec des fonctionnalités en constante évolution.

Le scénario pratique du premier mythe:

On perd actuellement un temps précieux. C'est très vrai. Les tests manuels sont plus rapides que les tests automatisés. Mais c'est pour le tout premier essai. Lors des exécutions ultérieures, quels que soient les avantages marginaux que les tests manuels apportent aux érosions. C'est presque immédiatement. Avec toutes les exécutions de test répétées ou les ajouts de fonctionnalités, les développeurs d'applications doivent réduire la portée des tests ou des ressources de test supplémentaires.

Avec la budgétisation finie, cela conduit finalement aux cycles vicieux de ces qualités qui diminuent. En réponse aux engagements de données et aux critiques négatives des utilisateurs d'appareils qui n'ont pas été testés, les équipes souhaitent une extension de la couverture de l'appareil. Celles-ci augmentent encore le stress sur les départements d'AQ déjà en tant que capacités.

C'est que l'entreprise a du mal à maintenir, rechercher et acheter des appareils tout en effectuant des tests. Même les programmes manuels de test de l'assurance-chômage les mieux financés tombent sous la couverture complète.

Aux États-Unis, les équipes mobiles nécessitent des tests sur 188 appareils pour couvrir 100% des parts marketing. Selon les recherches Xamarin de 2014, la majorité des équipes de développement testent fréquemment sur 25 appareils ou moins.

Plus d'un quart de ces communautés de développeurs ciblent cinq appareils ou moins. Dans des situations de test réelles, l'automatisation est rentable presque instantanément et immédiatement. Lors du tout premier test, on constate que les consommateurs accélèrent les délais de test de 4 fois. C'est sur des tests manuels entiers lors de l'exécution contre cinquante ou des appareils plus que cela.

Les exécutions qui sont dans la sous-séquence ont été beaucoup plus rapides. Pourtant, le raccourcissement est là pour une semaine de test presque complète à seulement des utilisations de quelques heures.

b) La couverture est le deuxième mythe.

La fragmentation est la cause de l'absence de possibilité d'obtenir une couverture élargie de l'appareil. Avec plus de 19000 appareils d'Androïdes uniques et une permutation de dizaines de systèmes d'exploitation et de facteurs pour iOS, de nombreuses équipes pensent qu'il n'est pas possible de couvrir la majorité des appareils sur les marchés fournis.

Il y a donc un test par défaut sur la poignée de ces appareils comme assez bon.

La réalité du deuxième mythe:

On aurait pu terminer la couverture de l’appareil. Dans le cas où les gens entretiennent des appareils en interne par poignée, ils en font beaucoup. L'achat d'appareils est difficile.

Le maintien de leur argent, de leurs coûts et de leur temps, à leur tour, rendre les disponibilités de leurs testeurs là et quand le besoin se fait sentir crée des blocages logistiques. Gartner avait déclaré que les développeurs mobiles devraient trouver des moyens d’atteindre des taux d’automatisation élevés pour suivre le rythme de la plate-forme et la propagation des changements. Cela avait été dans l'hébergement. Différentes fonctions ont utilisé la gestion interne.

Le chemin vers une telle automatisation passe par les services cloud de tiers. Les services cloud tiers aident à l'automatisation des processus de chargement des applications, à l'exécution de scripts de test, à la communication des résultats et à la réinitialisation en toute sécurité des appareils pour les normes des usines. Des sous-ensembles de tests d'applications s'exécutent en parallèle, accélérant ainsi les résultats.

Lors des tests sur une large gamme d'appareils réels, les nuages ​​de test permettent à tous les membres des équipes de savoir précisément comment fonctionne l'application, ce qui élimine les conjectures typiques des développements mobiles.

Exemple: Les chefs de produit définissent moins d'exigences système ainsi que des confidences justifiées dans les performances des appareils. Les développeurs reçoivent des confirmations visuelles objectives de la correction des bogues avant l'engagement de nouvelles versions. Ceci indépendamment de l'endroit et du moment où ils opèrent.

c) Le coût est le troisième mythe.

Les individus ne peuvent se permettre que des tests manuels. Les tests d'automatisation nécessitent la création de scripts de test, de courbes d'apprentissage pour le personnel d'assurance qualité et d'infrastructure. De nombreuses équipes ont déjà du mal à respecter les délais. Ils ont déjà dépassé le budget. Les tests d'automatisation semblent donc être à une longue distance.

Le scénario pratique du troisième mythe:

Les tests manuels permettent d'économiser de l'argent uniquement au cas où les gens sacrifieraient les couvertures. Les tests manuels ne semblent moins coûteux que dans la plupart des environnements simples.

Dans le cas où les tests incluent une «vérification intestinale» rapide des fonctionnalités de base de moins d'appareils, les tests manuels semblent être des aubaines. Mais toute ressemblance avec la couverture de test et le dispositif complet rendra les tests manuels beaucoup plus coûteux que les tests d'automatisation. Cela pourrait même être rapide.

Les tests manuels ne sont mis à l'échelle que par l'ajout de plus de personnes et de masses. Les coûts n'ont pas de véritable linéarité. Le renforcement du personnel pour répondre aux demandes entraîne d'énormes frais généraux sous forme de coordination et de formation. La division des cas de test réduit ainsi l'efficacité de tous les testeurs en effectuant la suppression des perspectives.

De plus, les testeurs qui ont suffisamment de sophistication pour creuser au-delà des comportements des utilisateurs explorant et anticipant ainsi les raisons pour lesquelles les applications peuvent échouer, pourraient ne pas être abondants ni bon marché. Les tests d'automatisation nécessitent toujours un peu plus de frais généraux au moment de la configuration initiale.

Mais comme indiqué ci-dessus, il peut produire des gains et des bénéfices de manière spectaculaire dans les vitesses de test. Il produit également une réduction de personnel correspondante en quelques jours. Les environnements de test basés sur le cloud ont encore réduit les coûts. Ceci en éliminant l'infrastructure de test sur site sous-utilisée et coûteuse.

d) La cohérence doit être le quatrième mythe.

Des besoins suffisants doivent être menés, exécutés et exploités. Pour différentes équipes de test, les déploiements prêts sont des décisions subjectives fondées sur les perceptions de nombreux testeurs manuels variés. Ils savent que le sens est que les bogues tombent entre les mailles du filet.

Les couvertures de test qui se chevauchent doivent détecter les problèmes les plus courants et les plus critiques avant les versions. Le reste des bogues attend les versions de maintenance.

Le vrai scénario du quatrième mythe:

Les qualités ne sont pas qualitatives. La disponibilité des productions ne doit pas être un facteur et une question d'opinions. Dans un environnement de test purement manuel, les perceptions varient d'un test à un autre et d'un testeur à un autre. Cela conduit à des résultats de tests erratiques et à des documentations non cohérentes.

Les décisions se compliquent lorsque des considérations de disponibilité des produits sont présentes. Cela conduit à des échecs de conformité, au désenchantement des masses et à des pertes de revenus. De plus, il y a la création de poches de compréhensions tribales non capturées qui sont perdues lorsque les gens et les employés sortent de chez eux.

comment ouvrir le fichier swf dans chrome

L'automatisation, à son tour, crée des métriques quantifiables. Cela sert de sources objectives de vérité pour éclairer les décisions concernant la justification de la décision commerciale, l'état de préparation du produit et la progression des équipes chargées des graphiques.

e) La réticence est le cinquième mythe.

Les tests manuels ont été remplacés par des tests d'automatisation. De nombreux développeurs différents ont accès à l'automatisation des tests car ils s'attendent à remplacer les testeurs manuels par des machines.

Dans le cas où l'automatisation des tests répète des tests similaires 1000 fois avec une précision de 100%, des questions se posent pour savoir pourquoi les humains ont besoin à des fins de test. L'automatisation des scripts de test peut également être effectuée par des machines.

L'image en temps réel du cinquième mythe:

Les testeurs manuels s'améliorent avec les tests d'automatisation. Les machines et les humains possèdent de bons scénarios dans de nombreux domaines et facteurs. Les testeurs, qui effectuent des tests manuels, peuvent toujours tester de manière plus créative.

Les tests d'automatisation les libèrent de cela. Alors que les humains attendent avec impatience de nouvelles façons de casser les applications, l'automatisation garantit la conformité sur la large gamme d'appareils. Cela va des tests unitaires aux tests de régression complets. Il n'est pas nécessaire que les approches 2 fonctionnent isolément.

Effectuer des tests étant manuel exploratoire alors que les systèmes back-end n'ont pas été soumis à des tests automatisés. Ce sont d'excellents moyens pour découvrir les erreurs qui surgissent dans les environnements de production. Les tests d'automatisation ne remplacent pas les testeurs qui sont des humains. Cela leur permet de mener un travail enrichissant et intéressant.

Une cohérence, une couverture, un coût et une vitesse améliorés s'ajoutent aux qualités améliorées. Économiser de l'argent et du temps signifie que l'on peut faire plus de tests et pas moins. C'est le cas lorsque l'on atteint des jalons critiques. Cela permet aux tests de suivre le rythme des équipes de développements agiles au lieu de se tenir debout.

Les organisations publient donc du code beaucoup plus fréquemment. Cela réduit les impacts et les quantités de défauts sont construites. Cela signifie que les développeurs travaillent avec des codes propres. La correction des bogues a été moins compliquée de façon spectaculaire. Cela libère les testeurs en agissant seuls, les gardiens se concentrant sur la créativité. Les tests exploratoires améliorent ainsi les qualités des produits.

Les tests d'automatisation des interfaces utilisateur mobiles offrent des avantages en termes de temps et de qualités. Des outils automatisés permettant aux testeurs d'évaluer facilement les interfaces utilisateur des applications via une gamme élargie d'appareils mobiles, ainsi que d'apporter des modifications pour améliorer facilement l'expérience utilisateur.

Conclusion

Une mauvaise interface graphique est une expérience désagréable pour l'utilisateur. Le test de l'interface graphique est fortement recommandé et important, en particulier lorsqu'il s'agit d'appareils intelligents, car ici la taille de l'écran est relativement petite et de nombreuses variantes des appareils sont disponibles sur le marché.

Votre application peut se présenter et se comporter différemment sur différents appareils. Il est donc important de tester l'application sur au moins certaines tailles et variations standard d'appareils.

Toutes les applications mobiles nécessitent des tests d'interface utilisateur, mais la profondeur des tests requis est définie par la catégorie ou le but de l'application. Vous devez effectuer une analyse complète des fonctionnalités de l'interface utilisateur de l'application par rapport au modèle du téléphone ou aux versions du système d'exploitation avant de finaliser votre banc d'essai.

Sur la base de cette analyse, vous devez créer vos cas de test pour les tests. Utilisez l'automatisation dans la mesure du possible pour gagner du temps.

Gardez un œil ouvert tout en testant l'interface utilisateur car elle est simple mais elle a un effet important sur la vente de votre application.

Jetez un œil à notre prochain tutoriel pour des informations détaillées sur Test réactif mobile .

lecture recommandée

• Tutoriel Appium pour tester les applications mobiles Android et iOS
• TOP 15 des meilleurs outils de test mobile en 2021 pour Android et iOS
• Meilleurs outils de test de logiciels 2021 (Outils d'automatisation des tests QA)
• Services de test bêta des applications mobiles (outils de test bêta iOS et Android)
• Pourquoi les tests mobiles sont-ils difficiles?
• Premiers pas avec Robotium - L'outil de test d'interface utilisateur d'application Android le plus populaire
• Téléchargement de l'e-book 'Testing Primer'
• 11 meilleurs outils d'automatisation pour tester les applications Android (outils de test des applications Android)