Tests de profils d'appareil : mobile, tablette et ordinateur

Vous devez prouver qu'un paiement mobile ou un tableau de bord pour tablette fonctionne sans réserver un laboratoire matériel pour chaque revue ? BotBrowser peut répéter depuis un profil approuvé la condition d'affichage, de saisie, de médias et de plateforme visible par le navigateur, mais ne prouve ni les capteurs réels, ni les dialogues du système, ni les performances de l'appareil ; utilisez du matériel réel pour ces critères d'acceptation.

Résumé

Utilisez un profil approuvé pour un parcours nommé, consignez le profil et le résultat observé, puis passez au matériel réel lorsque l'acceptation dépend d'un équipement ou d'un comportement du système hors navigateur.

Sommaire

• Partir du parcours
• Choisir les familles d'appareils
• Vérifier formulaires et tactile
• Contrôler orientation et permissions
• Conserver les preuves de publication
• Passer au matériel réel
• Conclusion pratique

Partez du parcours, pas de la largeur d'écran

Une page sur téléphone est plus qu'une page de bureau rétrécie. La saisie tactile modifie la réaction des commandes. Le clavier à l'écran change la zone utile autour des formulaires. L'orientation influe sur la navigation et sur les médias. Les conventions de la plateforme jouent sur les menus, les envois de fichiers, les permissions et la manière dont le navigateur confie une tâche à une autre application. Un bon test d'appareil réunit tous ces comportements.

BotBrowser s'appuie sur des familles d'appareils fondées sur des profils pour ce travail. Un profil sélectionné fournit une base cohérente pour l'affichage, la saisie, les médias, l'identité de plateforme et le comportement de la famille de navigateur. Les équipes peuvent répéter le même test autorisé sur un poste de travail, un exécuteur de CI ou un serveur géré, sans reconstruire la description de l'appareil à partir de réglages sans lien entre eux.

Le point de départ pratique est le parcours client : choisissez un profil de téléphone pour un paiement sur mobile, un profil de tablette pour un tableau de bord tactile et un profil d'ordinateur pour un parcours sur poste de travail. Consignez ce choix avec le cas de test afin que les relecteurs puissent reproduire les mêmes conditions et comprendre ce que représentent les preuves.

Le contenu web peut observer des caractéristiques générales de l'appareil et de la session du navigateur. Isolément, une disposition d'écran ou un mode de saisie peut sembler banal. Ensemble, l'affichage, l'interaction, les graphismes, les médias, la langue et le contexte réseau peuvent permettre une corrélation à long terme. Un profil maintient ces familles alignées, de sorte qu'une revue de confidentialité autorisée n'expose pas un mélange accidentel entre le comportement de l'hôte et celui de l'appareil cible. La cohérence améliore aussi la qualité d'une revue de mise en page : un échec observé avec un profil de tablette documenté se reproduit plus facilement qu'un échec issu d'un assemblage de réglages temporaires du navigateur.

La cohérence du profil ne remplace pas la gouvernance. Les équipes doivent utiliser des comptes de test approuvés, des destinations autorisées, des données maîtrisées et une politique de conservation pour les captures et les journaux. La couverture des appareils doit répondre à un objectif de QA écrit, car une longue liste de profils est moins utile qu'un ensemble plus restreint rattaché à de vrais besoins du produit.

Un profil d'appareil est le plus utile lorsque les relecteurs le traitent comme une condition de test complète. Les familles de comportements concernées sont les suivantes :

• Affichage : zone utile de la page, densité visuelle, orientation, comportement en plein écran et mise en page adaptative.
• Saisie : toucher, pointeur, clavier, focus, sélection, glisser-déposer et commandes à base de gestes.
• Formulaires : effets du clavier à l'écran, messages de validation, disposition de la saisie automatique, commandes de date et d'heure, et sélection de fichiers.
• Médias : images adaptatives, commandes de lecture, demandes d'autorisation de capture et présentation adaptée à l'appareil.
• Identité de plateforme : contexte de famille de navigateur et de système d'exploitation présenté comme une famille d'appareils cohérente.
• Graphismes et texte : comportement de rendu adapté au profil choisi et au contenu examiné.
• Contexte régional : langue, fuseau horaire et localisation réseau choisis selon le plan de test autorisé.

Servez-vous de ces catégories pour observer l'application : une commande reste-t-elle visible, un formulaire peut-il être terminé, le consentement est-il respecté, et le même profil donne-t-il un résultat stable ?

Conservez device-profile, journey-id, expected-result et evidence-id avec la fiche du cas. Pour le contrat géométrique du clavier, consultez VirtualKeyboard : limites du viewport et des insets, qui sépare la politique du profil des mesures du viewport visuel.

Choisir les profils et examiner chaque famille d'appareils

Partez des données d'usage que votre organisation est autorisée à utiliser. Les analyses produit peuvent montrer la part globale des sessions sur téléphone, tablette et ordinateur. Les dossiers de support peuvent révéler un parcours mobile qui pose sans cesse problème aux clients. Les tests d'accessibilité peuvent exiger des conditions à la fois tactiles et centrées sur le clavier. Ces sources permettent de définir un ensemble compact et défendable de profils, où chaque profil a une raison d'exister.

Évitez de choisir des profils uniquement parce qu'ils sont récents ou populaires. Le bon ensemble reflète l'application, les régions qu'elle dessert et les engagements de support pris par l'équipe. Révisez cet ensemble périodiquement, retirez les profils qui ne correspondent plus à une exigence active et ajoutez-en un lorsque l'usage ou un changement visible par les clients le justifie.

Notez pourquoi chaque profil appartient à l'ensemble. Une courte note comme « couvre le paiement sur écran étroit » ou « représente le tableau de bord à dominante tactile » permet à un relecteur ultérieur de décider si le profil mérite encore sa place. Lorsque deux profils produisent toujours les mêmes constats, conservez celui qui correspond à davantage d'usages réels et retirez l'autre.

Téléphone. Le test sur téléphone doit suivre des tâches complètes. Une capture de la page d'accueil dit peu de choses sur la capacité d'un client à se connecter, à faire un choix de consentement, à récupérer un compte, à envoyer un document ou à finaliser un achat. Parcourez le chemin de l'entrée à l'aboutissement avec le même profil et soyez très attentif aux commandes proches du bas de l'écran, à la navigation fixe, aux boîtes de dialogue et aux formulaires en plusieurs étapes. N'examinez le mode portrait et le mode paysage que si le produit prend en charge les deux.

Les cibles tactiles doivent être suffisamment espacées, mais la revue doit aussi confirmer l'accès au clavier là où le produit le promet. Un profil de téléphone n'est pas une raison de négliger l'ordre du focus, les libellés, la récupération après erreur ou les préférences de réduction des animations. Les revues de confidentialité et d'accessibilité sur mobile font souvent apparaître les mêmes défauts de conception : choix cachés, état peu clair ou commandes qui dépendent d'un seul mode de saisie.

Tablette. Les mises en page de tablette se situent souvent entre les hypothèses du mobile et celles de l'ordinateur. Un site peut passer à une disposition en plusieurs colonnes alors que la saisie reste d'abord tactile, et un menu compact peut devenir une barre latérale permanente. Utilisez des profils de tablette pour les tableaux de bord, les outils d'inventaire, les applications de service sur le terrain, les produits éducatifs et les expériences multimédias. Examinez les vues partagées, les grandes boîtes de dialogue, les interactions de glissement, les claviers virtuels et la rotation, et vérifiez que la largeur supplémentaire n'expose pas des commandes réservées à l'ordinateur et difficiles à utiliser au toucher. Un test de tablette n'est pas un test de téléphone agrandi : donnez-lui ses propres captures attendues et ses propres notes d'interaction.

Ordinateur. Les profils d'ordinateur restent importants même lorsque le trafic mobile est plus élevé. Les parcours sur poste de travail comprennent souvent de longs formulaires, des tâches sur plusieurs fenêtres, des téléchargements, des envois de fichiers, des raccourcis clavier et des informations denses. Conservez une référence documentée pour la comparaison, car une taille de fenêtre aléatoire à chaque exécution rend les écarts entre captures difficiles à interpréter. La revue sur ordinateur sert aussi de témoin pour les constats mobiles : si une boîte de dialogue de consentement échoue uniquement avec un profil de téléphone, l'équipe dispose d'un périmètre d'investigation plus étroit, et si elle échoue dans toutes les familles, le problème relève peut-être de la logique applicative partagée.

Enregistrez profile-rationale, coverage-family, review-date et retire-decision pour chaque profil sélectionné.

Formulaires, clavier à l'écran et saisie tactile

Les formulaires méritent un passage mobile dédié, car le focus peut modifier la zone visible de la page. Testez la connexion, la saisie d'adresse, le paiement, la recherche, la récupération de compte et tout éditeur personnalisé avec le profil de téléphone ou de tablette choisi. Le champ actif, son libellé, son message de validation et l'action suivante doivent rester compréhensibles.

Ne jugez pas un formulaire uniquement sur le premier événement de focus. Parcourez toute la séquence de focus, d'erreur et de perte de focus, corrigez une erreur, ouvrez et fermez une boîte de dialogue, puis revenez à la page. Vérifiez que le défilement reste prévisible et que la page retrouve une position utile après la fermeture du clavier. Ces contrôles protègent les utilisateurs réels et produisent des preuves qu'un autre relecteur peut reproduire.

La différence entre le viewport de mise en page et le viewport visuel explique pourquoi le comportement du clavier demande un contrôle à part. MDN décrit le viewport visuel comme la partie visible de la page, sans les claviers à l'écran ni les autres éléments qui ne suivent pas l'échelle de la page. Lorsqu'un clavier s'ouvre, la zone visible peut se réduire alors que la mise en page sur laquelle s'appuient le CSS et le positionnement fixe reste inchangée. Un pied de page fixe dimensionné d'après la mise en page peut donc laisser une action principale sous le clavier, alors qu'une page qui réagit aux changements de la zone visible peut la garder accessible. Pour un modèle de revue plus complet, qui couvre les états du viewport et les parcours au clavier et au toucher, consultez Revue de qualité des profils de navigateur mobiles.

Rédigez le résultat attendu d'une revue du clavier en termes observables. Pour un formulaire de connexion, le champ actif reste dans la zone visible, le message de validation apparaît à côté du champ sans être masqué par le clavier, l'action d'envoi reste accessible sans quitter la page et la perte de focus ramène la page à une position raisonnable. Conservez ces résultats sous forme de courte liste dans le cas de test et exécutez-les avec le profil choisi pour ce cas, afin qu'un autre relecteur puisse répéter la séquence et comparer le résultat.

Pour le comportement mobile sensible au clavier, utilisez la configuration documentée du produit plutôt que de superposer un viewport du framework au profil. Le profil doit rester responsable de la condition d'appareil pendant tout le test, et le framework d'automatisation doit seulement suivre le parcours approuvé.

La revue de la saisie doit se concentrer sur les résultats pour l'utilisateur. Vérifiez que les touchers activent la commande prévue, que le défilement ne déclenche pas une action voisine, que les poignées de glissement restent utilisables et que les menus peuvent être fermés. Lorsqu'un parcours prend en charge un pointeur ou un clavier physique, testez cette condition séparément et conservez ses propres preuves. Pour savoir comment se comportent les événements de souris, de toucher et de stylet, et comment garder chaque voie accessible, consultez Événements de pointeur : saisie accessible.

La revue manuelle garde sa valeur. Les contrôles automatisés peuvent confirmer qu'une commande existe et qu'une tâche aboutit, tandis qu'un relecteur peut remarquer qu'un menu paraît surchargé, qu'une explication de permission manque de clarté ou qu'un choix de confidentialité devient difficile à atteindre après une rotation. Les profils d'appareil ne remplacent pas les tests d'accessibilité, qui exigent toujours des contrôles sémantiques, une couverture au clavier et au lecteur d'écran, une revue du contraste, une gestion du focus et des testeurs qualifiés.

Capturez focus-target, visualViewport.height, validation-state et return-position pour la séquence du formulaire.

Orientation, médias, permissions et contexte régional

Ne testez les changements d'orientation que là où les utilisateurs sont censés faire pivoter l'appareil. Les médias, la relecture de documents, les cartes, les graphiques et certains outils de tablette ont souvent besoin des deux orientations, alors qu'un paiement officiellement limité au mode portrait peut s'en passer. Lorsque l'orientation fait partie du périmètre, vérifiez la continuité : la page doit conserver un état significatif, garder la tâche active visible, éviter de rouvrir des boîtes de dialogue fermées et conserver les données saisies dans le formulaire. Pour voir comment la rotation fonctionne comme un état de mise en page et comment garder la tâche intacte pendant celle-ci, consultez Screen Orientation API et expériences responsives.

Recueillez des preuves avant et après le changement avec le même profil. Ne mélangez pas une revue d'orientation avec un changement sans rapport de langue, de région réseau ou d'état du compte. Un seul changement maîtrisé rend le résultat plus facile à comprendre.

La caméra, le microphone, la localisation, les notifications et l'accès aux fichiers font intervenir à la fois la présentation du navigateur et le consentement dans l'application. Ne testez ces parcours qu'avec des comptes autorisés et des données de test approuvées. L'application doit expliquer pourquoi l'accès est demandé, gérer un refus sans enfermer l'utilisateur et permettre de changer d'avis plus tard lorsque le produit le prévoit. Pour les médias, vérifiez que l'aperçu, la mise en sourdine, l'annulation et la reprise après erreur se comportent comme prévu.

Les résultats des permissions peuvent persister dans un répertoire de données du navigateur ; adoptez donc une politique délibérée d'état de test. Un état vierge convient au consentement lors de la première exécution, tandis qu'un état conservé convient aux visites suivantes. Étiquetez les preuves pour qu'un autre relecteur sache quelle condition a été testée.

La famille d'appareils n'est qu'une partie de l'expérience mobile. La langue, le fuseau horaire et la région réseau peuvent modifier le contenu, les formats, les obligations de consentement et les voies de support. Choisissez ces valeurs d'après le plan de test autorisé et gardez-les cohérentes avec le scénario. Un profil de téléphone n'impose pas un type de réseau particulier, mais la route doit être approuvée, documentée et assez stable pour que le résultat puisse être examiné. Gardez les identifiants hors des captures et des journaux partagés.

Exécutez les variations régionales comme des cas distincts. Ne mélangez pas à la légère un changement de langue avec un autre compte, un autre profil et une autre route réseau. Des limites de cas claires facilitent la reproduction des échecs et réduisent la collecte inutile de données d'utilisateurs.

Nommez les entrées contrôlées orientation-change, permission-state, locale et network-route.

Preuves, matrices de publication et CI

Une preuve utile relie la condition d'appareil au comportement observé dans l'application. Consignez la famille de profil, la version du navigateur, la version de l'application, la catégorie de compte de test, les paramètres régionaux, l'orientation et le parcours tenté. Conservez la plus petite capture ou le plus court enregistrement qui explique le résultat, et masquez les données personnelles avant de partager.

Les journaux doivent obéir à la même retenue. La sortie de la console de l'application, les traces réseau et les diagnostics du navigateur peuvent contenir des identifiants ou des informations de compte. Ne collectez que ce que l'enquête exige, stockez-le selon la politique de conservation de l'équipe et limitez l'accès. Nommez clairement les références attendues, afin que les relecteurs sachent si une capture relève d'un paiement sur téléphone, d'un tableau de bord de tablette ou d'un parcours de support sur ordinateur sans ouvrir un tableur séparé.

Une fiche de cas qui survit aux changements d'équipe indique le parcours, la famille de profil, le résultat observable attendu, la catégorie de données de test, le responsable et la prochaine date de revue. Conservez la fiche à côté du test lui-même plutôt que dans un document séparé, afin qu'une capture modifiée ramène toujours à la personne et à l'exigence concernées.

Les grandes matrices deviennent souvent lentes et finissent ignorées. Séparez une petite porte de publication d'une couverture planifiée plus large : la porte contient les familles d'appareils et les parcours dont l'échec bloquerait la livraison, et les exécutions planifiées couvrent d'autres dispositions, langues et parcours moins fréquents. Attribuez un responsable à chaque cas et gardez la mise en quarantaine temporaire et visible. Si un cas d'appareil est instable, consignez la raison, conservez un cas de diagnostic plus petit et fixez une date de revue, plutôt que d'accepter en silence des captures changeantes ou des nouvelles tentatives répétées.

Les exécuteurs de CI ont besoin du même profil, de la même version du navigateur, des mêmes polices et ressources associées et du même état applicatif que la référence approuvée. Diffusez ces éléments par les contrôles habituels de l'organisation pour les secrets et les artefacts, et ne récupérez pas un profil différent à chaque exécution, sauf si le test couvre explicitement la rotation des profils. Empêchez les réglages d'affichage du framework de remplacer la condition d'appareil fournie par le profil et utilisez des instances de navigateur distinctes pour des identités d'appareil différentes, afin que l'état de stockage et les échecs restent attribuables au profil prévu.

La planification de capacité doit reposer sur des mesures faites sur vos propres pages. Un tableau de bord riche en médias et un formulaire simple n'ont pas les mêmes coûts en mémoire, en graphismes et en réseau. Commencez par un petit ensemble d'exécutions simultanées, observez le temps d'achèvement et la marge de ressources, puis fixez une limite pour cette charge de travail.

Les mises à niveau du navigateur, du profil, du framework d'automatisation et de l'application peuvent chacune affecter un test d'appareil. Modifiez une couche à la fois lorsque c'est possible, exécutez la porte de publication avant d'étendre à la matrice planifiée et comparez avec une référence produite par la même famille de profil. Après une mise à niveau, réexaminez le consentement, les permissions, la récupération de compte, les envois de fichiers et le paiement, et ne conservez les anciennes preuves que tant que la politique et l'intérêt technique le justifient.

Chaque ligne de matrice identifie browser-build, profile-revision, app-build et matrix-case.

Quand le matériel réel reste le bon choix

Les tests sur ordinateur fondés sur des profils ne suppriment pas le besoin d'appareils physiques. Utilisez du matériel lorsque les critères d'acceptation dépendent d'une vraie caméra, d'une radio, d'un capteur biométrique, d'une boîte de dialogue du système d'exploitation, d'un transfert vers une autre application, d'un comportement matériel propre à un fabricant ou de performances dans des conditions réelles de batterie et de température. Le matériel est aussi approprié pour une certification finale lorsqu'un contrat ou une politique de plateforme l'exige.

Une règle d'escalade utile est simple : si le résultat attendu dépend d'un équipement physique ou d'un service du système d'exploitation extérieur au navigateur, confirmez-le sur l'appareil cible. S'il concerne la présentation dans le navigateur et un parcours pris en charge fondé sur un profil, l'exécution sur ordinateur ou sur serveur peut fournir les preuves reproductibles dont l'équipe a besoin, et le temps limité du laboratoire d'appareils est consacré aux conditions qui exigent réellement du matériel.

BotBrowser peut exécuter des profils mobiles Android ou de la famille WebKit correspondants, avec une prise en charge tactile définie par le profil. Grâce à l'option documentée --bot-mobile-keyboard, le focus de confiance sur un champ modifiable réduit visualViewport.height sans modifier le viewport de mise en page, de sorte qu'une équipe peut répéter une revue mobile des formulaires et du clavier à partir d'une condition de profil documentée. Les profils d'ordinateur ignorent cette option. BotBrowser ne peut pas remplacer les appareils physiques, les vrais claviers du système d'exploitation, les boîtes de dialogue ni le comportement du matériel, et il ne garantit pas que chaque appareil ou chaque mise en page d'application se comporte de façon identique.

Choisissez des tests d'appareil fondés sur des profils lorsque l'équipe a besoin d'une QA de navigateur reproductible sur les familles mobile, tablette et ordinateur, surtout en CI ou sur une infrastructure gérée. Choisissez un service d'appareils physiques lorsque l'acceptation dépend du matériel réel, et l'émulation adaptative standard lorsque la tâche est une ébauche de mise en page et que l'identité de l'appareil est hors périmètre. Avant d'étendre le déploiement, confirmez qui est responsable de chaque profil, l'usage approuvé, le traitement des données de test, la conservation des preuves, la capacité des exécuteurs et la voie d'escalade. Ces décisions comptent plus que le nombre de noms d'appareils d'un catalogue.

Téléchargez BotBrowser pour exécuter des profils d'appareil approuvés, ou consultez les fonctions de cohérence de plateforme avant de définir un déploiement. Pour la planification mobile, voir les tests de profils de navigateur Android. La cohérence de l'écran et de la fenêtre traite de la revue de l'affichage adaptatif, et les profils de navigateur multiplateformes traitent des choix de déploiement sur l'hôte.

Conclusion pratique

Choisissez le plus petit ensemble de profils approuvés couvrant des parcours nommés, conservez ensemble profil et preuve de publication, et faites du matériel réel l'escalade nécessaire lorsque le critère d'acceptation dépend d'un équipement ou d'un service du système.

Sources

• Documentation BotBrowser sur l'émulation d'appareils
• MDN : VisualViewport