Qu'est-ce que le cross browser testing ? Trois moteurs, pas vingt navigateurs

Le cross browser testing consiste à vérifier que votre site fonctionne dans les navigateurs que vos visiteurs utilisent vraiment, et non dans celui qui est posé sur votre bureau. Cette définition est sans éclat et complète, et presque tous les articles sur le sujet vous tendent ensuite un tableau de trente combinaisons navigateur-version, et c’est là que la pratique commence à mal tourner.

Partez plutôt des moteurs. Il y en a trois qui comptent : Blink, c’est-à-dire Chrome, Edge, Opera, Brave et l’essentiel du reste ; WebKit, c’est-à-dire Safari partout et tous les navigateurs sur iOS quel que soit le nom inscrit dessus ; et Gecko, c’est-à-dire Firefox. Que Chrome et Edge soient en désaccord sur votre mise en page est rare, parce qu’ils sont le même moteur de rendu avec une enveloppe différente. Que Chrome et Safari soient en désaccord est ordinaire.

Tester trente navigateurs, c’est surtout tester Blink trente fois.

Ce qui diffère réellement aujourd’hui

L’époque des préfixes constructeurs est révolue, et les différences qui restent sont d’une autre nature. Quatre catégories couvrent presque toutes.

• Codecs et médias. La catégorie la plus coûteuse, parce qu’elle échoue complètement plutôt que cosmétiquement. Une vidéo que le navigateur ne sait pas décoder n’est pas une vidéo dégradée ; c’est un message d’erreur.
• Les API qu’un moteur n’a pas livrées. La détection de fonctionnalités est la réponse, et le mode de défaillance est une fonctionnalité qui ne fait silencieusement rien, plutôt qu’une page qui s’affiche mal.
• Les cas limites de mise en page. Moins nombreux qu’autrefois, mais ceux qui restent se trouvent plutôt dans les parties récentes de la spécification, exactement là où l’on se saisit de la nouveauté.
• La cadence de publication. Le moteur de Safari se met à jour avec le système d’exploitation, donc “le dernier Safari” est une affirmation sur la date à laquelle quelqu’un a mis à jour son Mac ou son téléphone.

Il vaut la peine de nommer ces catégories parce qu’elles appellent des réponses différentes. Les codecs demandent une solution de repli livrée dans la page. Les API manquantes demandent de la détection. La mise en page demande qu’on la regarde. La cadence demande vos statistiques.

Un exemple détaillé, et c’était le nôtre

Notre extension enregistre la vidéo en VP9 dans un conteneur WebM. Safari n’a pas de décodeur VP9. La page de partage tendait au navigateur une source unique construite à partir du type du fichier stocké, et un élément vidéo HTML auquel on donne une seule source qu’il ne sait pas lire ne se dégrade pas : il échoue.

Pendant un temps, un lien envoyé à quelqu’un sur Mac lui affichait donc le mot Error. Toute la promesse du produit tient dans un lien qu’une autre personne peut ouvrir, et pour un moteur cette promesse était rompue.

Trois choses dans la façon dont cela est passé inaperçu sont typiques de la catégorie, et c’est pourquoi cela mérite d’être écrit plutôt que corrigé en silence.

Ce que nous avions

Des tests automatisés, tous au vert, tous exécutés dans Chrome. Rien n'a journalisé d'erreur, parce que du point de vue du serveur rien n'avait échoué : un fichier a été servi, et le navigateur n'a pas pu s'en servir

Ce qui l'aurait détecté

Ouvrir un enregistrement partagé dans Safari, une fois. Aucun outillage nécessaire, et aucune suite n'aurait eu besoin d'exister

C’est le destinataire qui l’a découvert. Celui qui avait envoyé le lien ne l’a jamais su, parce que rien ne vous dit que la page que vous avez partagée n’a pas fonctionné pour la personne avec qui vous l’avez partagée. C’est la propriété qui définit les défaillances entre moteurs : elles sont invisibles depuis l’endroit où vous vous tenez.

Le correctif a consisté à encoder une copie H.264 à côté de chaque envoi et à proposer les deux sources, puis à enregistrer directement en MP4 là où le navigateur le permet.

Par où commencer, et ce n’est pas une matrice

Deux données décident de votre liste, et aucune des deux n’est une supposition.

Vos statistiques. Pas les parts de marché mondiales. Les navigateurs qu’utilisent vos visiteurs, dans vos pays, sur vos pages. Un outil B2B en Allemagne et un site grand public au Brésil donnent des réponses différentes, et toutes deux diffèrent des chiffres mondiaux que cite chaque article comparatif.

Votre suivi d’erreurs. Les erreurs groupées par navigateur vous diront où les choses cassent déjà, ce qui est une meilleure priorisation que n’importe quelle supposition sur l’endroit où elles pourraient casser.

De là, une forme qui tient : un smoke test sur les trois moteurs, et des tests approfondis sur vos deux principaux. Le smoke test est la même idée qu’ailleurs - la page se charge-t-elle, peut-on se connecter, peut-on aller au bout du seul parcours qui compte - et le faire sur Safari et Firefox attrape en quelques minutes toute la catégorie des codecs et des API manquantes.

Énoncez la matrice à voix haute dans votre plan de test, y compris ce qui est hors périmètre. “Nous ne testons pas Firefox sur Android” est une décision quand c’est écrit et un accident quand ça ne l’est pas.

Ce que les outils couvrent et ce qu’ils ne couvrent pas

Les services commerciaux vous louent des machines équipées de navigateurs, ce qui résout le vrai problème : vous ne pouvez pas faire tourner Safari sous Linux ni avoir toutes les versions d’iOS sur votre bureau. Cela vaut le prix quand vous en avez besoin.

Ce qu’ils ne résolvent pas, c’est de savoir quoi regarder. Une capture de votre page dans douze navigateurs, ce sont douze captures que quelqu’un doit comparer, et c’est le problème que les tests de régression visuelle existent pour automatiser - et cette suite a le même angle mort, parce qu’elle ne vérifie que les navigateurs dont vous lui avez parlé.

L’automatisation, quelle qu’elle soit, se débrouille aussi mal avec la défaillance qui compte le plus ici. Une vidéo qui ne se lit pas, une police qui ne se charge pas, un champ de date qui s’affiche comme une zone de texte sur un moteur : tout cela passe n’importe quelle assertion sur le DOM, parce que le DOM va bien. C’est le rendu qui ne va pas.

Les signalements sont l’autre moitié

Aussi bonne que soit la matrice, un moteur, une version, un appareil que vous n’avez pas testé produira un bug pour une personne réelle. La question est de savoir si vous l’apprenez.

C’est l’argument pour rendre le signalement facile depuis là où chacun se trouve, et pour que le signalement porte le navigateur et la version sans demander à celui qui signale de les connaître. “Ça ne marche pas sur mon téléphone” coûte une journée. “Safari 26.1 sur iOS, sur l’enregistrement la zone vidéo est vide, la console dit que la source n’est pas prise en charge” coûte un après-midi, et la différence tient entièrement à ce que le signalement portait, pas à ce que son auteur savait.

Ce qui est la limite honnête de cet article : le cross browser testing réduit l’écart, et les signalements qui arrivent des navigateurs que vous n’avez pas couverts sont la façon dont vous apprenez où l’écart subsiste. Ni l’un ni l’autre ne se remplacent, et une équipe qui n’en fait qu’un seul n’a que la moitié du tableau.