Was ist Cross-Browser-Testing? Drei Engines, nicht zwanzig Browser

Cross-Browser-Testing heißt zu prüfen, ob Ihre Website in den Browsern funktioniert, die Ihre Besucher tatsächlich benutzen, und nicht in dem, der auf Ihrem Schreibtisch steht. Diese Definition ist unspektakulär und vollständig, und fast jeder Artikel zum Thema reicht Ihnen danach eine Tabelle mit dreißig Browser-und-Version-Kombinationen - und genau da fängt die Sache an, schiefzugehen.

Fangen Sie stattdessen bei den Engines an. Drei sind es, auf die es ankommt: Blink, das ist Chrome, Edge, Opera, Brave und der größte Teil des Rests; WebKit, das ist Safari überall und jeder Browser unter iOS, ganz gleich welcher Name darauf steht; und Gecko, das ist Firefox. Dass Chrome und Edge sich über Ihr Layout uneinig sind, ist selten, denn sie sind dieselbe Rendering-Engine mit unterschiedlichem Rahmen darum. Dass Chrome und Safari sich uneinig sind, ist gewöhnlich.

Dreißig Browser zu testen heißt größtenteils, Blink dreißigmal zu testen.

Was sich heute tatsächlich unterscheidet

Die Zeit der Vendor-Prefixe ist vorbei, und die Unterschiede, die geblieben sind, sind anderer Art. Vier Kategorien decken nahezu alle davon ab.

• Codecs und Medien. Die teuerste Kategorie, weil sie vollständig scheitert statt kosmetisch. Ein Video, das der Browser nicht dekodieren kann, ist kein Video in schlechterer Qualität; es ist eine Fehlermeldung.
• APIs, die eine Engine nicht ausgeliefert hat. Feature Detection ist die Antwort, und der Fehlerfall ist eine Funktion, die stillschweigend nichts tut, statt einer Seite, die falsch aussieht.
• Layout-Grenzfälle. Weniger als früher, aber die verbliebenen liegen meist in den neueren Teilen der Spezifikation, also genau dort, wo man nach dem Neuen greift.
• Release-Rhythmus. Safaris Engine wird zusammen mit dem Betriebssystem aktualisiert, also ist “das aktuelle Safari” eine Aussage darüber, wie kürzlich jemand seinen Mac oder sein Telefon aktualisiert hat.

Die Kategorien zu benennen lohnt sich, weil sie unterschiedliche Antworten brauchen. Codecs brauchen einen Fallback, der in der Seite ausgeliefert wird. Fehlende APIs brauchen Detection. Layout will angeschaut werden. Der Rhythmus braucht Ihre Analytics.

Ein durchgespieltes Beispiel, und es war unseres

Unsere Erweiterung nimmt Video in VP9 in einem WebM-Container auf. Safari hat keinen VP9-Decoder. Die Freigabeseite reichte dem Browser eine einzige Quelle, gebaut aus dem Typ der gespeicherten Datei, und ein HTML-Video-Element, dem eine einzige Quelle gegeben wird, die es nicht abspielen kann, wird nicht schlechter - es scheitert.

Eine Zeit lang zeigte ein Link, der an jemanden mit einem Mac ging, diesem Menschen also das Wort Error. Das ganze Versprechen des Produkts ist ein Link, den ein anderer Mensch öffnen kann, und für eine Engine war dieses Versprechen gebrochen.

Drei Dinge daran, wie das unentdeckt blieb, sind typisch für diese Kategorie, und darum ist es das Aufschreiben wert statt des stillen Behebens.

Was wir hatten

Automatisierte Tests, alle grün, alle in Chrome laufend. Nichts protokollierte einen Fehler, denn aus Sicht des Servers war nichts fehlgeschlagen - eine Datei wurde ausgeliefert, und der Browser konnte sie nicht verwenden

Was es gefunden hätte

Eine geteilte Aufnahme einmal in Safari öffnen. Kein Werkzeug nötig, und keine Suite hätte dafür existieren müssen

Erfahren hat es der Empfänger. Wer den Link geschickt hatte, erfuhr es nie, denn nichts sagt Ihnen, dass die Seite, die Sie geteilt haben, für den Menschen, mit dem Sie sie geteilt haben, nicht funktioniert hat. Das ist die bestimmende Eigenschaft von Fehlern über Engine-Grenzen hinweg: von dort, wo Sie stehen, sind sie unsichtbar.

Die Lösung bestand darin, neben jedem Upload eine H.264-Kopie zu kodieren und beide Quellen anzubieten, und danach direkt MP4 aufzuzeichnen, wo der Browser es zulässt.

Wo man anfängt, und das ist keine Matrix

Zwei Eingaben entscheiden über Ihre Liste, und keine davon ist geraten.

Ihre Analytics. Nicht der weltweite Marktanteil. Die Browser, die Ihre Besucher benutzen, in Ihren Ländern, auf Ihren Seiten. Ein B2B-Werkzeug in Deutschland und eine Verbraucherseite in Brasilien haben verschiedene Antworten, und beide unterscheiden sich von den weltweiten Zahlen, die jeder Vergleichsartikel zitiert.

Ihr Error Tracking. Nach Browser gruppierte Fehler sagen Ihnen, wo bereits etwas kaputtgeht, und das ist eine bessere Priorisierung als jede Vermutung darüber, wo etwas kaputtgehen könnte.

Daraus ergibt sich eine brauchbare Form: auf allen drei Engines einen Smoke Test, und auf Ihren zwei größten tief testen. Der Smoke Test ist derselbe Gedanke wie überall sonst - lässt sich die Seite laden, kann man sich anmelden, lässt sich der eine Ablauf abschließen, auf den es ankommt - und ihn auf Safari und Firefox zu machen fängt die ganze Kategorie aus Codecs und fehlenden APIs in Minuten ab.

Sagen Sie die Matrix in Ihrem Testplan ausdrücklich, einschließlich dessen, was außerhalb des Umfangs liegt. “Wir testen Firefox unter Android nicht” ist eine Entscheidung, wenn es aufgeschrieben ist, und ein Versehen, wenn nicht.

Was die Werkzeuge abdecken und was nicht

Die kommerziellen Dienste vermieten Ihnen Maschinen mit Browsern darauf, und das löst das tatsächliche Problem, dass Sie Safari nicht unter Linux laufen lassen und nicht jede iOS-Version auf Ihrem Schreibtisch haben können. Dafür zu bezahlen lohnt sich, wenn Sie es brauchen.

Was sie nicht lösen, ist zu wissen, worauf man schauen muss. Ein Screenshot Ihrer Seite in zwölf Browsern sind zwölf Screenshots, die jemand vergleichen muss, und genau dieses Problem soll Visual Regression Testing automatisieren - und diese Suite hat denselben blinden Fleck, denn sie prüft nur die Browser, von denen Sie ihr erzählt haben.

Automatisierung jeder Art ist außerdem schlecht in dem Fehler, auf den es hier am meisten ankommt. Ein Video, das nicht abspielt, eine Schrift, die nicht lädt, ein Datumsfeld, das auf einer Engine als Textfeld gerendert wird: all das besteht jede Behauptung über das DOM, denn das DOM ist in Ordnung. Es ist das Rendering, das es nicht ist.

Die Meldungen sind die andere Hälfte

Wie gut die Matrix auch ist, irgendeine Engine, irgendeine Version, irgendein Gerät, das Sie nicht getestet haben, wird für einen echten Menschen einen Fehler hervorbringen. Die Frage ist, ob Sie davon erfahren.

Das ist das Argument dafür, es leicht zu machen, von dort aus zu melden, wo jemand gerade ist, und dafür, dass die Meldung den Browser und die Version mitbringt, ohne dass der Meldende sie kennen muss. “Auf meinem Handy geht es nicht” kostet einen Tag. “Safari 26.1 unter iOS, in der Aufnahme ist der Videobereich leer, die Konsole sagt, die Quelle werde nicht unterstützt” kostet einen Nachmittag, und der Unterschied liegt vollständig darin, was die Meldung mitbrachte, nicht darin, was der Meldende wusste.

Und das ist die ehrliche Grenze dieses Artikels: Cross-Browser-Testing verkleinert die Lücke, und die Meldungen, die aus den Browsern kommen, die Sie nicht abgedeckt haben, sind die Art, wie Sie erfahren, wo die Lücke noch ist. Keines ersetzt das andere, und ein Team, das nur eines davon tut, hat ein halbes Bild.