Construisez votre matrice de navigateur à partir du risque, pas d'une case à cocher

Votre suite de tests dispose d'une liste déroulante de navigateur. Quelqu'un sélectionne tout. La CI ralentit, les pannes se multiplient et personne ne peut expliquer quelles configurations protègent l'entreprise. Une grande matrice semble prudente, mais elle peut toujours manquer le flux mobile utilisé par les clients pour terminer leur inscription.

Commencez par le risque, puis choisissez les configurations qui l'exposent. Ce guide utilise les projets Playwright, sa documentation du navigateur et son guide d'émulation pour créer une petite matrice de navigateur lisible. Le visuel qui l'accompagne est un tableau de planification illustratif et non un rapport de support mesuré.

Séparez trois décisions

La première décision est le moteur du navigateur : Chromium, Firefox ou WebKit. La seconde est la configuration de l'appareil : fenêtre d'affichage, agent utilisateur, toucher et autres paramètres émulés. La troisième est la preuve matérielle : un appareil réel et son comportement réel de navigateur. Ils sont liés mais non interchangeables.

Playwright documente la prise en charge de Chromium, Firefox et WebKit, ainsi que les canaux de marque Chromium tels que Chrome et Edge. Sa version WebKit ne porte pas la marque Safari. Un résultat WebKit vert doit donc être décrit comme une preuve WebKit, et non comme une affirmation selon laquelle chaque version de Safari sur chaque iPhone a réussi.

Les préréglages de périphérique fournissent des paramètres émulés. Ils permettent d'appliquer une mise en page étroite ou une interface utilisateur tactile, mais ils ne transforment pas un ordinateur de bureau en périphérique physique. Conservez des vérifications sur les appareils réels pour détecter les risques tels que les interactions avec la plate-forme que la configuration émulée n'établit pas.

Cartographier un parcours en fonction du risque qu'il comporte

Pour le tableau de démonstration, l'inscription dépend d'une présentation de formulaire étroite et d'un lien de confirmation. Les paramètres de facturation contiennent la saisie de la date et le formatage des paramètres régionaux. Le téléchargement d'un document peut dépendre des capacités du navigateur et du comportement des autorisations. Ce sont différentes raisons de choisir une configuration de test.

Demandez à votre équipe les exigences en matière de navigateurs pris en charge et les preuves d'audience actuelles. S'il n'en existe pas, enregistrez un choix provisoire et sa date d'examen au lieu d'inventer des pourcentages clients. Un ingénieur QA peut diriger cette conversation avec le produit et le support ; le choix ne doit pas être caché dans un fichier runner que personne ne lit.

L'artefact exploitable est un registre matriciel : le parcours, le risque, le projet sélectionné, la raison pour laquelle il est sélectionné, les preuves extérieures à l'émulation et le propriétaire. Ajoutez une configuration uniquement lorsque le grand livre indique ce qu'il achète. Supprimez le travail redondant uniquement lorsque les exigences de support et l'examen des risques le permettent.

Faites en sorte que les noms des projets disent ce qu'ils exécutent

Un projet Playwright regroupe des tests avec la même configuration. Cette petite configuration illustre trois points de vue distincts et garde les noms honnêtes :

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  projects: [
    { name: 'chromium-desktop', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox-desktop', use: { ...devices['Desktop Firefox'] } },
    { name: 'webkit-phone-emulation', use: { ...devices['iPhone 13'] } }
  ]
});

Installez les binaires du navigateur correspondants dans votre environnement de test. Exécutez un projet nommé avec npx playwright test --project=webkit-phone-emulation. Ces noms décrivent la configuration et non une garantie du produit. Le code est un point de départ pour votre propre politique de support, et non une matrice universelle recommandée.

Playwright exécute les projets configurés par défaut. Son guide de projets montre également comment les groupes peuvent utiliser différents répertoires de tests. Cela permet à une équipe de diffuser une fumée ciblée sur plusieurs moteurs tout en conservant un ensemble plus large ailleurs. Évitez d'abandonner silencieusement un parcours critique pour votre entreprise simplement parce qu'un parcours à grande échelle n'est pas pratique.

Diagnostiquer une différence au lieu de supprimer la configuration

Si un test réussit dans un projet et échoue dans un autre, vérifiez si le produit, le contrat de test ou l'environnement diffère. Une fenêtre d'affichage étroite peut déplacer l'action suivante sous la ligne de flottaison. Les paramètres régionaux peuvent modifier le format de date. Une fonctionnalité du navigateur peut se comporter différemment. Une collision de données partagées ne constitue pas du tout une preuve du navigateur.

Gardez le résultat attendu stable là où le contrat de produit est stable. N'écrivez pas une assertion distincte simplement pour accepter un résultat cassé dans un moteur. Lorsque le produit diffère intentionnellement, documentez ce comportement et faites en sorte que le test le vérifie explicitement.

Examinez les preuves d'échec par nom de projet et conservez la configuration avec le résultat. Une capture d'écran sans sa fenêtre d'affichage, son moteur et ses paramètres pertinents peut être difficile à interpréter. Conservez ces détails dans le rapport de test, et non dans une supposition faite lors du triage.

Où s'inscrit l'exploration générée

AnyTest décrit l'exploration d'une application Web et la création de tests de bout en bout pour une évaluation humaine. Les parcours générés peuvent vous aider à identifier les flux qui méritent d'être protégés, mais ils n'établissent pas la couverture des navigateurs/appareils de votre déploiement. Demandez les configurations d'exécution réellement prises en charge avant de faire cette réclamation.

Pour un ingénieur de QA, une matrice axée sur les risques évite que le temps de révision limité soit consommé par une duplication inexpliquée. Pour une équipe plus grande, cela donne aux propriétaires de domaines de produits un vocabulaire commun. Le résultat utile est un ensemble de configurations que vous pouvez défendre, avec des limites connues et un suivi visible, plutôt que la liste la plus longue qu'un écran de paramètres autorise.