Profils d'appareil sur mobile, tablette et ordinateur

Partir du parcours, pas de la largeur

Une page de téléphone n'est pas une page d'ordinateur rétrécie. Le tactile modifie les commandes. Le clavier à l'écran réduit l'espace autour des formulaires. L'orientation affecte la navigation et les médias. Les conventions de plateforme influencent les menus, les fichiers et les permissions. Un test utile conserve ces comportements dans une même condition.

BotBrowser s'appuie sur des familles d'appareils définies par profil. Le profil choisi fournit une base cohérente pour l'affichage, la saisie, les médias, l'identité de plateforme et la famille de navigateur. Une équipe peut répéter le même test autorisé sur un poste, un runner CI ou un serveur administré sans assembler des réglages indépendants.

Commencez par le parcours client. Associez un profil de téléphone à un paiement mobile, un profil de tablette à un tableau de bord tactile et un profil d'ordinateur à un outil de bureau. Notez ce choix dans le cas de test. Un autre réviseur saura reproduire les conditions et interpréter les preuves.

Cohérence et protection de la vie privée

Le contenu web peut observer des caractéristiques générales de l'appareil et de la session. Affichage, interaction, graphismes, médias, langue et contexte réseau peuvent contribuer à la corrélation. Un profil maintient ces familles alignées et évite qu'un audit autorisé mélange accidentellement le comportement de l'hôte et celui de l'appareil visé.

Cette cohérence facilite aussi l'enquête. Un défaut observé avec un profil de tablette documenté se reproduit mieux qu'un défaut obtenu avec des réglages provisoires. Le principe vaut pour le consentement, l'accessibilité, le paiement, la récupération de compte et le support. Une base stable distingue plus facilement un problème applicatif d'une variation de l'environnement.

Le profil ne remplace pas la gouvernance. Utilisez des comptes approuvés, des destinations autorisées, des données contrôlées et une politique de conservation. Chaque profil doit répondre à un objectif QA écrit. Une sélection limitée liée aux besoins du produit apporte davantage qu'un grand catalogue sans responsable.

Les familles de comportement

Un profil représente une condition complète :

• Affichage : espace utile, densité visuelle, orientation, plein écran et mise en page adaptative.
• Saisie : tactile, pointeur, clavier, focus, sélection, glisser et commandes gestuelles.
• Formulaires : clavier à l'écran, validation, remplissage, dates et choix de fichiers.
• Médias : images adaptatives, lecture, demandes d'accès et présentation appropriée.
• Identité de plateforme : famille de navigateur et système d'exploitation cohérents.
• Graphismes et texte : rendu adapté au profil et au contenu examiné.
• Contexte régional : langue, fuseau et route réseau définis par le plan autorisé.

Utilisez ces catégories pour observer l'application : une commande reste visible, un formulaire aboutit, le consentement est respecté et le même profil produit un résultat stable. L'automatisation de production peut rester centrée sur le parcours et son résultat attendu.

Choisir une sélection représentative

Partez de données que l'organisation est autorisée à utiliser. Les statistiques produit indiquent la répartition générale entre téléphone, tablette et ordinateur. Le support peut signaler un parcours mobile problématique. Les exigences d'accessibilité peuvent imposer des conditions tactiles et clavier. Ces éléments définissent une sélection compacte et justifiable.

Chaque profil doit avoir une fonction. Un téléphone représente le parcours principal. Un second couvre une classe d'affichage ou de saisie réellement différente. Une tablette traite les mises en page intermédiaires. Les ordinateurs représentent des postes courants plutôt que tous les écrans possibles.

La nouveauté ne suffit pas. La sélection reflète l'application, les régions servies et les engagements de support. Révisez-la régulièrement, retirez les cas sans besoin actif et ajoutez un profil lorsque l'usage ou une évolution visible le justifie.

Vérifier un parcours sur téléphone

Suivez des tâches complètes. Une capture de la page d'accueil ne prouve pas qu'une personne peut se connecter, choisir une option de consentement, récupérer son compte, envoyer un document ou finaliser un achat. Gardez le même profil de l'entrée au résultat.

Examinez les commandes en bas de l'écran, les barres fixes, les boîtes de dialogue et les formulaires à étapes. L'espace visible change lors de la saisie. Le champ actif, son libellé, le message d'erreur et l'action principale doivent rester compréhensibles et accessibles. Testez les deux orientations seulement si le produit les prend en charge.

Le tactile ne dispense pas d'accessibilité. Contrôlez l'ordre du focus, les libellés, la correction des erreurs et les préférences de mouvement selon les engagements du produit. Les problèmes mobiles de confidentialité et d'accessibilité révèlent souvent les mêmes défauts visibles : choix masqué, état ambigu ou commande liée à une seule méthode d'entrée.

Vérifier une tablette

La tablette se situe entre les hypothèses du téléphone et de l'ordinateur. Une page peut passer à plusieurs colonnes tout en restant tactile. Un menu compact peut devenir une barre latérale. Les tableaux gagnent de la place sans obtenir la précision d'une souris.

Utilisez un profil de tablette pour les tableaux de bord, outils de terrain, produits éducatifs, inventaires et médias où cet état intermédiaire compte. Vérifiez les vues partagées, les grandes boîtes de dialogue, le glisser, le clavier virtuel et la rotation. Une largeur plus grande ne doit pas faire apparaître des commandes de bureau difficiles à toucher.

Préparez des références et des notes propres à la tablette. Si le produit accepte un clavier externe ou un pointeur, créez une condition distincte au lieu de mélanger les modes.

Vérifier un ordinateur

Les parcours de bureau comprennent souvent des formulaires longs, plusieurs fenêtres, des fichiers, le clavier et des données denses. Le profil doit correspondre à la famille de navigateur et de système couverte par le produit.

Testez le redimensionnement dans la plage prise en charge, tout en conservant une base nommée. Une taille aléatoire à chaque exécution rend les captures difficiles à interpréter. Définissez séparément un portable compact et un grand poste si les deux font partie du support.

Le bureau sert aussi de comparaison applicative. Un dialogue défaillant uniquement sur téléphone indique une piste mobile. Un défaut présent partout peut provenir de logique commune. Comparez le comportement visible et l'état final du même parcours.

Formulaires et clavier à l'écran

Consacrez un passage mobile aux formulaires de connexion, recherche, adresse, paiement, récupération et édition. Le champ, son libellé, l'erreur et l'étape suivante doivent rester visibles ou facilement atteignables.

Parcourez toute la séquence. Corrigez une erreur, ouvrez une aide, fermez-la et revenez au formulaire. Vérifiez le défilement et la position après la fermeture du clavier. La première mise au point ne suffit pas.

BotBrowser peut représenter le comportement lié au clavier dans les parcours mobiles pris en charge. Utilisez la configuration produit documentée et évitez qu'un réglage du framework remplace l'affichage du profil.

Tactile, pointeur et clavier

Concentrez-vous sur le résultat utilisateur. Un toucher doit activer la bonne commande, le défilement ne doit pas déclencher l'action voisine, les poignées doivent rester utilisables et les menus doivent pouvoir se fermer. Testez séparément le pointeur ou le clavier physique s'ils sont pris en charge.

Le framework réalise les actions approuvées, sans redéfinir l'appareil. Le profil établit la famille et l'automatisation suit le parcours. Une revue manuelle complète les scripts sur les chemins importants. Elle peut repérer un menu trop dense, une demande peu claire ou un choix devenu difficile après rotation.

Orientation et mise en page

Testez la rotation lorsqu'elle répond à un usage réel : vidéo, document, carte, graphique ou outil de tablette. Un paiement prévu uniquement en portrait ne réclame pas forcément la même matrice.

L'état doit survivre au changement. Les données saisies, les choix, la lecture et les dialogues fermés ne doivent pas se réinitialiser. Capturez avant et après avec le même profil et ne modifiez pas en même temps la langue, le réseau ou le compte.

Médias et permissions

Caméra, microphone, position, notifications et fichiers associent présentation du navigateur et consentement de l'application. Utilisez des comptes autorisés et des données approuvées. La page explique la demande, accepte un refus et permet une modification ultérieure lorsque le produit le prévoit.

Gardez le profil constant pendant la demande, la réponse et la reprise. Examinez le parcours visible. Pour les médias, contrôlez aperçu, silence, annulation et récupération. Pour les fichiers, assurez-vous que les consignes et avis de confidentialité restent lisibles.

Les décisions peuvent persister dans les données du navigateur. Définissez un état propre pour la première visite et un état conservé pour le retour. Étiquetez les preuves.

Langue et contexte réseau

La langue, le fuseau et la région réseau peuvent modifier contenu, format, consentement et support. Choisissez-les dans le plan autorisé et gardez-les cohérents.

Un profil mobile n'impose pas un type de réseau particulier. Développement, CI, bureau et réseaux de test administrés ont leurs contraintes. La route doit être approuvée, documentée et stable. Les identifiants ne doivent pas apparaître dans les captures ou journaux partagés.

Exécutez chaque variante régionale comme un cas distinct. Des limites claires facilitent la reproduction et évitent de collecter des données inutiles.

Des preuves utiles

Notez famille de profil, versions du navigateur et de l'application, classe de compte, langue, orientation et parcours. Conservez la capture minimale qui explique le résultat et masquez les données personnelles.

Les journaux peuvent contenir des identifiants. Recueillez uniquement ce qui sert à l'enquête, limitez l'accès et appliquez la conservation prévue. Nommez clairement les références afin de distinguer téléphone, tablette et ordinateur lorsque plusieurs cas tournent en parallèle.

Associez chaque échec à l'étape visible qui l'a produit. Un bouton inaccessible, une erreur masquée par le clavier ou une permission mal expliquée demandent des responsables différents. Une preuve courte, cadrée sur l'application et reliée au cas suffit souvent pour orienter le correctif.

Les captures et enregistrements peuvent contenir des données de compte ou de formulaire. Utilisez des données contrôlées, masquez les identifiants avant partage et appliquez une durée de conservation. Le rapport durable garde la condition, le résultat et la référence de preuve.

Une preuve de livraison doit aussi relier le résultat à la version, au profil et à la classe d'appareil approuvés. Si un parcours échoue, remettez le cas sur la dernière référence fiable avant d'essayer une autre modification. La comparaison reste alors exploitable pour le support et évite d'attribuer au profil une variation provenant de l'application ou du poste de travail.

Une matrice maintenable

Séparez une petite barrière de livraison d'une couverture planifiée plus large. La barrière contient les familles et parcours dont l'échec bloque la version. Les exécutions planifiées couvrent davantage de langues et de cas moins fréquents.

Chaque cas a un responsable, un résultat attendu, une source de données et une voie d'escalade. Une quarantaine reste temporaire, documentée et datée. N'acceptez pas silencieusement des captures variables ou des relances répétées.

Lorsqu'un cas devient instable, retirez-le de la barrière avant de modifier sa référence. Le responsable compare la dernière exécution fiable, la version et l'état initial, puis fixe une date de retour.

CI et infrastructure administrée

Le runner reçoit le même profil, navigateur, ressources et état applicatif que la référence approuvée. Distribuez-les par les contrôles habituels de secrets et d'artefacts. Ne changez pas de profil à chaque exécution sauf si la rotation constitue le test.

Le framework ne doit pas remplacer l'affichage du profil. La préparation de l'hôte relève de l'infrastructure. Mesurez la capacité avec vos pages : un tableau de bord multimédia et un formulaire simple n'ont pas le même coût. Commencez avec peu de concurrence, observez la marge et fixez une limite adaptée, puis revérifiez après les mises à niveau.

Quand choisir du matériel réel

Utilisez un appareil physique lorsque l'acceptation dépend d'une caméra, d'une radio, de la biométrie, d'une boîte de dialogue système, d'une application native, d'une politique administrée, de la batterie ou de la température. Le matériel convient aussi aux certifications qui l'exigent.

Les profils couvrent en amont la confidentialité, la mise en page, l'interaction et la régression. Le laboratoire peut alors se concentrer sur ce qui dépend vraiment de l'équipement.

Examiner les mises à niveau

Le navigateur, le profil, le framework et l'application peuvent modifier un test. Changez une couche à la fois lorsque possible. Exécutez d'abord la barrière de livraison et comparez avec la même famille et orientation.

Revérifiez consentement, permissions, récupération, fichiers, paiement et autres parcours traitant des données personnelles. Le refus doit toujours fonctionner et l'application ne doit pas demander davantage d'accès. Étiquetez chaque référence avec sa version et conservez-la selon la politique.

Commencez par un groupe limité qui représente les parcours les plus sensibles. Comparez réussite, durée, erreurs visibles et fermeture avec la référence. Si un écart apparaît, suspendez la promotion, revenez à la combinaison approuvée et modifiez une seule couche avant le nouvel essai.

Choisir le mode de déploiement

Les profils conviennent à une QA répétable sur téléphone, tablette et ordinateur, notamment en CI ou sur infrastructure administrée. Ils servent la confidentialité, l'adaptation, l'accessibilité, le support et la régression.

Le matériel convient aux exigences physiques ou système. Une simple simulation de largeur suffit au début d'une maquette lorsque seule la disposition compte. Beaucoup d'équipes combinent les trois approches.

Avant d'étendre la couverture, confirmez le responsable, l'autorisation, les données, la conservation, la capacité et l'escalade. Ces décisions comptent davantage que le nombre d'appareils affiché.

Questions courantes

Un profil peut-il couvrir tous les mobiles ?

Non. Il représente une famille et une condition. Choisissez une petite sélection selon l'usage, le support et les différences matérielles de présentation ou d'interaction.

Le framework doit-il fixer l'affichage ?

Laissez les substitutions désactivées lorsque le profil contrôle l'appareil. Une taille particulière devient un cas séparé et documenté.

Les familles peuvent-elles partager une session ?

Utilisez des instances distinctes. L'état, les preuves et les échecs restent ainsi attribuables au profil prévu.

Comment valider le tactile ?

Suivez des tâches représentatives avec automatisation approuvée et revue manuelle. Vérifiez l'accessibilité des commandes, le défilement, le focus, les dialogues et la récupération jusqu'au résultat attendu.

À quelle fréquence faut-il revoir les profils ?

Revoyez-les lorsque l'usage du produit change, que les engagements de support évoluent ou qu'une mise à jour du navigateur et de l'application modifie réellement le test. Une revue périodique avec le responsable évite aussi l'accumulation de cas inutilisés.

Cela remplace-t-il l'audit d'accessibilité ?

Non. Le profil fournit une condition. L'accessibilité exige sémantique, clavier, technologies d'assistance lorsque nécessaire, contraste, focus et expertise dédiée.

Que conserver après l'exécution ?

La preuve minimale avec profil, versions, parcours, langue, orientation et état. Masquez les données personnelles et appliquez la politique de conservation.

Conserver une référence documentée

Les tests d'appareil fonctionnent quand chaque cas possède un objectif, un profil approuvé et un résultat produit attendu. Cette discipline rend les preuves comparables entre développement, CI, support et livraison.

Téléchargez BotBrowser pour exécuter des profils approuvés ou consultez les fonctions de cohérence de plateforme avant le déploiement. Pour le mobile, lisez les tests de profils Android. La cohérence de l'écran et de la fenêtre traite la mise en page, et les profils multiplateformes présentent les choix d'hôte.