Effektives, browserübergreifendes Testen mit minimalem Aufwand

Cross-Browser-Tests sind zeitaufwändig und mühsam. Entwickler sind jedoch von Natur aus faul: Sie halten sich an das DRY-Prinzip, schreiben Skripte, um Dinge zu automatisieren, die wir sonst von Hand erledigen müssten, nutzen Bibliotheken von Drittanbietern; Faulheit macht uns zu guten Entwicklern .

Der traditionelle Ansatz zum „richtigen“ Cross-Browser-Testen besteht darin, in allen wichtigen Browsern zu testen, die von Ihrer Zielgruppe verwendet werden, und nach und nach zu den älteren oder obskureren Browsern überzugehen, um zu sagen, dass Sie sie getestet haben. Oder, wenn Zeit und Ressourcen knapp sind, testen Sie eine kleine Untergruppe von Ad-hoc-Browsern und hoffen, dass das Fehlen eines Fehlers Ihnen Vertrauen in die Integrität der Anwendung gibt. Der erste Ansatz verkörpert „gute“ Entwicklung, ist aber ineffizient, während der zweite Faulheit verkörpert, aber unzuverlässig ist.

Weiterführende Literatur zu SmashingMag:

• Noahs Übergang zu mobilen Usability-Tests
• Die Grundlagen der Testautomatisierung für Apps, Spiele und das mobile Web
• So erstellen Sie Ihren eigenen Front-End-Website-Testplan
• Wo sind die weltbesten Open Device Labs?

In den nächsten fünfzehn Minuten hoffe ich, Ihnen Stunden vergeudeter Mühe zu ersparen, indem ich eine Teststrategie beschreibe, die nicht nur weniger arbeitsintensiv ist, sondern auch effektiver beim Auffinden von Fehlern. Ich möchte eine realistische Teststrategie dokumentieren, die relevanter und wertvoller ist als einfach „alle Dinge testen!“, und dabei auf meine Erfahrung als Testentwickler bei BBC Visual Journalism zurückgreifen kann.

Kontext

Nebenbei sei darauf hingewiesen, dass wir in unserem Team mehr als nur manuelle Tests durchführen. Cross-Browser-Testing ist kein Ersatz für Unit-Tests (Jasmine/QUnit), Funktionstests (Cucumber) und gegebenenfalls automatisierte visuelle Regressionstests (Wraith). Tatsächlich sind automatisierte Tests auf lange Sicht billiger und ab einer bestimmten Größe Ihrer Anwendung unerlässlich.

Einige Fehler treten jedoch nur in bestimmten Browsern auf, und die Testautomatisierung ist noch nicht zuverlässig in die Domäne des browserübergreifenden Testens eingedrungen. Wie kann ein Computer wissen, dass Ihr automatisiertes Scroll-Ereignis gerade die Hälfte des Titels verdeckt hat, wenn es auf einem iPhone 4 angezeigt wird? Wie würde es wissen, dass das ein Problem ist? Bis die künstliche Intelligenz zu einem Punkt anwächst, an dem Computer verstehen, was Sie gebaut haben, und die Erzählung und Kunstfertigkeit, die Sie zu demonstrieren versuchen, zu schätzen wissen , wird es immer einen Bedarf an manuellen Tests geben. Als etwas, das manuell durchgeführt werden muss, sind wir es uns selbst schuldig, den Cross-Browser-Testprozess so effizient wie möglich zu gestalten.

Was ist Ihr Ziel?

Bevor Sie sich blindlings in Cross-Browser-Tests stürzen, entscheiden Sie, was Sie sich davon erhoffen. Cross-Browser-Testing kann mit zwei Hauptzielen zusammengefasst werden:

1. Entdecken von Fehlern Dies beinhaltet den Versuch, Ihre Anwendung zu beschädigen, um Fehler zu finden, die behoben werden können.
2. Plausibilitätsprüfung Dies beinhaltet die Überprüfung, ob die Mehrheit Ihres Publikums die erwartete Erfahrung macht.

Das Erste, was Sie aus diesem Artikel mitnehmen möchten, ist, dass diese beiden Ziele im Widerspruch zueinander stehen .

Einerseits weiß ich, dass ich die Erfahrung von fast 50 % unseres britischen Publikums verifizieren kann, indem ich einfach in Chrome (Desktop), Chrome (Android) und Safari (iOS 9) teste. Wenn es andererseits mein Ziel ist, Fehler zu finden, möchte ich meine Web-App auf die problematischsten Browser werfen, die wir aktiv unterstützen müssen: in unserem Fall IE8 und nativer Android-Browser 2.

Benutzer dieser beiden Browser machen einen schwindenden Prozentsatz unseres Publikums aus (derzeit etwa 1,5 %), was dazu führt, dass das Testen in diesen Browsern unsere Zeit schlecht nutzt, wenn unser Ziel die Plausibilitätsprüfung ist. Aber sie sind großartige Browser zum Testen, wenn Sie sehen möchten, wie verstümmelt Ihre ausgereifte Anwendung werden kann, wenn sie auf eine obskure Rendering-Engine geworfen wird.

Herkömmliche Teststrategien legen verständlicherweise mehr Wert auf das Testen in gängigen Browsern. Allerdings gibt es nur in den obskureren Browsern überproportional viele Fehler, die nach dem traditionellen Testmodell erst gegen Ende des Tests ans Licht kommen. Dann stehst du vor einem Dilemma …

Was tun Sie, wenn Sie spät in der Long-Tail-Testphase einen Fehler finden?

1. Ignorieren Sie den Fehler.
2. Beheben Sie den Fehler und hoffen Sie, dass Sie nichts kaputt gemacht haben.
3. Beheben Sie den Fehler und testen Sie erneut in allen zuvor getesteten Browsern.

In einer idealen Welt ist die letzte Option die beste, da nur so wirklich sicher sein kann, dass alle Browser noch wie erwartet funktionieren. Es ist jedoch auch ungeheuer ineffizient - und etwas, das Sie wahrscheinlich mehrmals tun müssten. Es ist das manuelle Testäquivalent einer Blasensortierung.

Wir befinden uns daher in einer Catch-22-Situation: Für maximale Effizienz möchten wir alle Fehler beheben, bevor wir mit dem browserübergreifenden Testen beginnen, aber wir können nicht wissen, welche Fehler vorhanden sind, bis wir mit dem Testen beginnen.

Die Antwort ist, klug zu sein, wie wir testen: unsere Ziele der Fehlersuche und Plausibilitätsprüfung durch inkrementelles Testen zu erreichen, in dem, was ich gerne den Drei-Phasen-Angriff nenne.

Drei-Phasen-Angriff

Stellen Sie sich vor, Sie befinden sich in einem Kriegsgebiet. Sie wissen, dass die bösen Jungs im Hauptquartier auf der anderen Seite der Stadt hocken. Ihnen stehen ein Spezialagent, ein erstklassiges Team kampferprobter Guerillas und eine große Gruppe leicht bewaffneter lokaler Milizen zur Verfügung. Sie starten einen dreiphasigen Angriff, um die Stadt zurückzuerobern:

1. Aufklärung Schicken Sie Ihren Spion in das feindliche Hauptquartier, um ein Gefühl dafür zu bekommen, wo sich die bösen Jungs verstecken könnten, wie viele von ihnen es gibt und wie der allgemeine Zustand des Schlachtfelds ist.
2. Raid Schicken Sie Ihr Crack-Team direkt ins Herz des Feindes und eliminieren Sie die Mehrheit der Bösewichte in einem wilden Überraschungsangriff.
3. Räumung Schicken Sie die örtliche Miliz los, um die verbleibenden Bösewichte auszuschalten und das Gebiet zu sichern.

Dieselbe militärische Strategie und Disziplin können Sie auch in Ihre Cross-Browser-Tests einbringen:

1. Reconnaissance Führen Sie explorative Tests in einem gängigen Browser auf einem Entwicklungscomputer durch. Bekomme ein Gefühl dafür, wo sich die Käfer verstecken könnten. Beheben Sie alle aufgetretenen Fehler.
2. Raid Manuelles Testen auf einer kleinen Handvoll problematischer Browser, die wahrscheinlich die meisten Fehler zeigen. Beheben Sie alle aufgetretenen Fehler.
3. Clearance Sanity überprüft, ob die beliebtesten Browser unter Ihrem Publikum gelöscht sind, um die erwartete Erfahrung zu erzielen.

Egal, ob Sie auf dem Schlachtfeld sind oder Geräte testen, die Phasen beginnen mit minimalem Zeitaufwand und wachsen, wenn der Betrieb stabiler wird. Sie können nur so viel Aufklärungsarbeit leisten – Sie sollten in sehr kurzer Zeit in der Lage sein, einige Fehler zu erkennen. Der Raid ist intensiver und zeitaufwändiger, liefert aber sehr lohnenswerte Ergebnisse und stabilisiert das Schlachtfeld erheblich. Die Räumungsphase ist die mühsamste von allen, und Sie müssen immer noch bei Verstand bleiben, falls ein unentdeckter Bösewicht aus dem Nichts auftaucht und Ihnen Schaden zufügt – aber es ist ein notwendiger Schritt, um zuversichtlich behaupten zu können, dass das Schlachtfeld ist jetzt sicher.

Die ersten beiden Schritte unseres dreiphasigen Angriffs erfüllen unser erstes Ziel: die Fehlererkennung . Wenn Sie sich sicher sind, dass Ihre Anwendung robust ist, sollten Sie mit Phase drei des Angriffs fortfahren, indem Sie die minimale Anzahl von Browsern testen, die dem Surfverhalten der Mehrheit Ihrer Zielgruppe entsprechen, und Ziel Nummer zwei erfüllen: Plausibilitätsprüfung. Sie können dann mit quantitativ gestützter Gewissheit sagen, dass Ihre Anwendung für X % Ihres Publikums funktioniert.

Aufbau: Kenne deinen Feind

Gehen Sie nicht leichtfertig in den Krieg. Bevor Sie mit dem Testen beginnen, sollten Sie herausfinden, wie Benutzer auf Ihre Inhalte zugreifen.

Finden Sie Ihre Zielgruppenstatistiken heraus (von Google Analytics oder einem anderen Tool, das Sie verwenden) und erhalten Sie die Daten in einer Tabelle in einem Format, das Sie lesen und verstehen können. Sie möchten in der Lage sein, jede Kombination aus Browser und Betriebssystem mit einem zugehörigen Prozentsatz des Gesamtmarktanteils zu sehen.

Browser-Nutzungsstatistiken sind nur dann nützlich, wenn sie einfach verwendet werden können: Sie möchten nicht mit einer langen, entmutigenden Liste von Browser/Betriebssystem/Gerät-Kombinationen konfrontiert werden, die Sie testen müssen. Außerdem ist das Testen aller möglichen Kombinationen vergebliche Mühe. Wir können unser Webentwickler-Wissen nutzen, um unsere Statistiken heuristisch zu konsolidieren.

Vereinfachen Sie Ihre Browser-Nutzungsstatistiken

Als Webentwickler kümmern wir uns nicht besonders darum, auf welchem ​​Betriebssystem der Desktop-Browser läuft – es ist sehr selten, dass ein Browser-Fehler auf ein Betriebssystem zutrifft und nicht auf das andere – deshalb führen wir die Statistiken für Desktop-Browser über alle Betriebssysteme hinweg zusammen.

Es ist uns auch egal, ob jemand Firefox 40 oder Firefox 39 verwendet: Die Unterschiede zwischen den Versionen sind vernachlässigbar und die Aktualisierung der Versionen ist kostenlos und oft automatisch. Um unser Verständnis der Browserstatistiken zu erleichtern, führen wir Versionen aller Desktop-Browser zusammen – außer IE. Wir wissen, dass die älteren Versionen von IE sowohl problematisch als auch weit verbreitet sind, daher müssen wir ihre Nutzungszahlen verfolgen.

Ein ähnliches Argument gilt für tragbare OS-Browser. Die Version von mobilem Chrome oder Firefox ist uns nicht besonders wichtig, da diese regelmäßig und einfach aktualisiert werden – daher führen wir die Versionen zusammen. Aber auch hier kümmern wir uns um die verschiedenen Versionen von IE, also protokollieren wir ihre Versionen separat.

Die OS-Version eines Geräts ist irrelevant, wenn wir über Android sprechen; Wichtig ist die Version des verwendeten nativen Android-Browsers, da dies ein notorisch problematischer Browser ist. Andererseits ist es sehr relevant, welche Version von iOS auf einem Gerät läuft, da Safari-Versionen untrennbar mit dem Betriebssystem verbunden sind. Dann gibt es eine ganze Reihe von nativen Browsern für andere Geräte: Diese machen einen so kleinen Prozentsatz unseres Gesamtpublikums aus, dass auch ihre Versionsnummern zusammengeführt werden.

Schließlich haben wir eine neue Welle von Browsern, die schnell an Popularität gewinnen: In-App-Browser, die hauptsächlich auf Social-Media-Plattformen implementiert werden. Dies ist immer noch Neuland für uns, daher möchten wir alle In-App-Browserplattformen und ihre jeweiligen Betriebssysteme auflisten.

Nachdem wir unser Domänen-Expertenwissen genutzt haben, um verwandte Statistiken zusammenzuführen, grenzen wir die Liste weiter ein, indem wir alle Browser entfernen, die weniger als 0,05 % unseres Publikums ausmachen (Sie können diesen Schwellenwert gerne an Ihre eigenen Anforderungen anpassen).

Desktop-Browser

Tragbare Browser

In-App-Browser

Wenn Sie fertig sind, sollte Ihre Tabelle ungefähr so ​​aussehen (ignorieren Sie die Spalte „Priorität“ vorerst – dazu kommen wir später):

Jetzt haben Sie also Ihre vereinfachte Tabelle, die die wichtigsten Browser aus der Sicht des Webentwicklers zeigt, wobei jeder mit einem Prozentsatz des Gesamtmarktanteils verknüpft ist. Bitte beachten Sie, dass Sie diese Tabelle auf dem neuesten Stand halten sollten; Eine Aktualisierung einmal im Monat sollte ausreichen.

Sie sind jetzt bereit für den Drei-Phasen-Angriff.

1. Reconnaissance: Finden Sie browserunabhängige Fehler

Lange bevor Sie überhaupt daran denken, ein Gerät zum Testen herauszuholen, tun Sie das Einfachste, was Sie können: Öffnen Sie Ihre Web-App in Ihrem bevorzugten Browser. Wenn Sie kein kompletter Masochist sind, ist dies wahrscheinlich Chrome oder Firefox, die beide stabil sind und moderne Funktionen unterstützen. Das Ziel dieser ersten Phase ist es, browserunabhängige Fehler zu finden.

Browserunabhängige Fehler sind Implementierungsfehler, die nichts mit dem Browser oder der Hardware zu tun haben, die für den Zugriff auf Ihre Anwendung verwendet werden. Angenommen, Ihre Webseite geht online und Sie erhalten obskure Fehlerberichte von Leuten, die sich darüber beschweren, dass Ihre Seite auf ihrem HTC One im Querformat schlecht aussieht. Sie verschwenden viel Zeit damit, herauszufinden, welche Version welchen Browsers verwendet wurde, verwenden den USB-Debug-Modus von Android und suchen in StackOverflow nach Hilfe und fragen sich, wie um alles in der Welt Sie das beheben sollen. Ohne Ihr Wissen hat dieser Fehler nichts mit dem Gerät zu tun: Ihre Seite sieht vielmehr bei einer bestimmten Ansichtsfensterbreite fehlerhaft aus, was zufällig die Bildschirmbreite des betreffenden Geräts ist.

Dies ist ein Beispiel für einen browserunabhängigen Fehler, der sich fälschlicherweise als browserspezifischer oder gerätespezifischer Fehler manifestiert hat. Sie wurden auf einen langen und verschwenderischen Weg geführt, wobei Fehlerberichte wie Lärm wirken und die Grundursache des Problems verschleiern. Tun Sie sich selbst einen Gefallen und fangen Sie solche Fehler gleich zu Beginn ein, mit viel weniger Aufwand und etwas mehr Voraussicht.

Indem wir die browserunabhängigen Fehler beheben, bevor wir überhaupt mit dem browserübergreifenden Testen beginnen, sollten wir insgesamt mit weniger Fehlern konfrontiert werden. Ich nenne das gerne den Effekt des schmelzenden Eisbergs . Wir schmelzen die Käfer weg, die unter der Oberfläche verborgen sind, und bewahren uns vor dem Absturz und dem Ertrinken im Ozean – und wir merken nicht einmal, dass wir das tun.

Nachfolgend finden Sie eine kurze Liste der Dinge, die Sie in Ihrem Entwicklungsbrowser tun können, um browserunabhängige Fehler zu entdecken:

• Versuchen Sie, die Größe zu ändern, um die Reaktionsfähigkeit anzuzeigen. Gab es irgendwo einen irren Haltepunkt?
• Vergrößern und verkleinern. Wurden die Hintergrundpositionen Ihres Bild-Sprites schief geschlagen?
• Sehen Sie, wie sich die Anwendung verhält, wenn JavaScript deaktiviert ist. Erhalten Sie immer noch den Kerninhalt?
• Sehen Sie, wie die Anwendung mit deaktiviertem CSS aussieht. Ist die Semantik des Markups noch sinnvoll?
• Versuchen Sie, sowohl JavaScript als auch CSS zu deaktivieren. Machen Sie eine akzeptable Erfahrung?
• Versuchen Sie, mit der Anwendung nur über Ihre Tastatur zu interagieren. Ist es möglich zu navigieren und alle Inhalte zu sehen?
• Versuchen Sie, Ihre Verbindung zu drosseln und sehen Sie, wie schnell die Anwendung geladen wird. Wie hoch ist die Seitenlast?

Bevor Sie mit Phase 2 fortfahren, müssen Sie die Fehler beheben, auf die Sie gestoßen sind. Wenn wir die browserunabhängigen Fehler nicht beheben, werden wir später nur viele falsche browserspezifische Fehler melden.

Faul sein. Beheben Sie die browserunabhängigen Fehler. Dann können wir zur zweiten Phase des Angriffs übergehen.

2. Raid: Testen Sie zuerst in Hochrisiko-Browsern

Wenn wir Fehler beheben, müssen wir darauf achten, dass unsere Korrekturen nicht noch mehr Fehler einführen. Wenn Sie unser CSS optimieren, um die Auffüllung in Safari zu korrigieren, kann die Auffüllung in Firefox beschädigt werden. Die Optimierung dieses Teils von JavaScript für eine reibungslosere Ausführung in Chrome könnte es im IE vollständig beschädigen. Jede Änderung, die wir vornehmen, birgt Risiken.

Um wirklich sicher zu sein, dass neue Änderungen die Erfahrung in keinem der Browser, in denen wir bereits getestet haben, beeinträchtigt haben, müssen wir zurückgehen und in denselben Browsern erneut testen. Um Doppelarbeit zu minimieren, müssen wir daher klug vorgehen, wie wir testen.

Statistische Analyse der Fehlerverteilung

Betrachten Sie die folgende Tabelle, in der das Kreuzsymbol bedeutet, dass der Browser den Fehler hat.

Angenommen, wir testen unsere Inhalte in aufsteigender Reihenfolge des Risikos: Browser mit niedrigem Risiko, Browser mit mittlerem Risiko, Browser mit hohem Risiko. Wenn es Ihnen hilft, dies zu visualisieren, können diese Browser Google Chrome, IE 9 bzw. IE 6 zuordnen.

Beim ersten Testen des Low-Risk-Browsers (Chrome) würden wir Fehler Nr. 2 finden und beheben. Wenn wir zum Browser mit mittlerem Risiko wechseln, ist Fehler Nr. 2 bereits behoben, aber wir entdecken einen neuen Fehler: Nr. 4. Wir ändern unseren Code, um den Fehler zu beheben – aber wie können wir sicher sein, dass wir jetzt nicht etwas im Low Risk-Browser kaputt gemacht haben? Wir können uns nicht ganz sicher sein, also müssen wir zurückgehen und in diesem Browser erneut testen, um sicherzustellen, dass alles noch wie erwartet funktioniert.

Jetzt gehen wir zum Hochrisiko-Browser über und finden die Fehler Nr. 1, Nr. 3 und Nr. 5, die eine erhebliche Überarbeitung erfordern, um sie zu beheben. Was müssen wir tun, wenn diese behoben sind? Gehen Sie zurück und testen Sie die Browser mit mittlerem und niedrigem Risiko erneut. Das ist viel Doppelarbeit. Insgesamt sechs Mal mussten wir unsere drei Browser testen.

Betrachten wir nun, was passiert wäre, wenn wir unsere Inhalte in absteigender Reihenfolge des Risikos getestet hätten.

Auf Anhieb fanden wir die Fehler Nr. 1, Nr. 3, Nr. 4 und Nr. 5 im Hochrisiko-Browser. Nachdem wir diese Fehler behoben hatten, gingen wir direkt zum Medium-Risk-Browser und entdeckten Fehler Nr. 2. Wie zuvor hat dieser Fix möglicherweise indirekt etwas beschädigt, sodass es notwendig ist, zum High Risk-Browser zurückzukehren und erneut zu testen. Schließlich testen wir im Low-Risk-Browser und entdecken keine neuen Fehler. In diesem Fall haben wir unsere drei Browser bei insgesamt vier verschiedenen Gelegenheiten getestet, was eine große Zeitersparnis darstellt, die erforderlich ist, um die gleiche Anzahl von Fehlern effektiv zu entdecken und zu beheben und das Verhalten der gleichen Anzahl von Browsern zu validieren .

Es kann auf Entwickler unter Druck stehen, zuerst in den beliebtesten Browsern zu testen und sich gegen Ende unserer Tests zu den weniger verbreiteten Browsern vorzuarbeiten. Beliebte Browser sind jedoch wahrscheinlich Browser mit geringem Risiko.

Sie wissen, dass Sie einen bestimmten Browser mit hohem Risiko unterstützen müssen, also räumen Sie diesen Browser gleich zu Beginn aus dem Weg. Verschwenden Sie keine Mühe mit dem Testen von Browsern, die weniger Fehler verursachen, denn wenn Sie zu Browsern wechseln, die mehr Fehler verursachen, müssen Sie nur zurückgehen und sich diese risikoarmen Browser erneut ansehen.

Das Beheben von Fehlern in schlechten Browsern macht Ihren Code in guten Browsern widerstandsfähiger

Oft werden Sie feststellen, dass die Fehler, die in diesen problematischen Browsern auftreten, das unerwartete Ergebnis von schlechtem Code Ihrerseits sind. Möglicherweise haben Sie ein div ungeschickt so gestaltet, dass es wie eine Schaltfläche aussieht, oder ein setTimeout gehackt, bevor Sie ein willkürliches Verhalten auslösen. Für beide Probleme gibt es bessere Lösungen. Indem Sie die Fehler beheben, die die Symptome von schlechtem Code sind, beheben Sie wahrscheinlich Fehler in anderen Browsern, bevor Sie sie überhaupt sehen. Da ist wieder dieser Effekt des schmelzenden Eisbergs .

Indem Sie nach Funktionsunterstützung suchen, anstatt anzunehmen, dass ein Browser etwas unterstützt, beheben Sie diesen schmerzhaften Fehler in IE8, aber Sie machen Ihren Code auch robuster gegenüber anderen rauen Umgebungen. Indem Sie dieses Image-Fallback für Opera Mini bereitstellen, fördern Sie die Verwendung der progressiven Verbesserung und als Nebenprodukt verbessern Sie Ihr Produkt sogar für Benutzer von Browsern, die den Senf abschneiden. Beispielsweise kann ein mobiles Gerät seine 3G-Verbindung verlieren, wenn nur die Hälfte der Assets Ihrer Anwendung heruntergeladen wurde: Der Benutzer erhält jetzt eine sinnvolle Erfahrung, die er vorher nicht hatte.

Seien Sie jedoch vorsichtig: Wenn Sie nicht aufpassen, kann das Beheben von Fehlern in obskuren Browsern Ihren Code verschlechtern . Widerstehen Sie der Versuchung, den User-Agent-String zu erschnüffeln, um beispielsweise Inhalte bedingt an bestimmte Browser zu liefern. Das könnte den Fehler beheben, ist aber eine völlig unhaltbare Praxis. Setzen Sie nicht die Integrität guten Codes aufs Spiel, um ungeschickte Browser zu unterstützen.

Identifizieren problematischer Browser

Was ist also ein Hochrisiko-Browser? Die Antwort ist etwas vage und hängt von den Browserfunktionen ab, die Ihre Anwendung verwendet. Wenn Ihr JavaScript indexOf verwendet, kann es in IE 8 brechen. Wenn Ihre App position: fixed verwendet, sollten Sie es in Safari unter iOS 7 überprüfen.

Kann ich verwenden ist eine unschätzbare Ressource und ein guter Ausgangspunkt, aber dies ist einer der Bereiche, die wiederum aus Erfahrung und der Intuition der Entwickler resultieren. Wenn Sie regelmäßig Web-Apps einführen, wissen Sie, welche Browser immer wieder Probleme melden, und Sie können Ihre Teststrategie entsprechend verfeinern.

Das Hilfreiche an Fehlern, die Sie in problematischen Browsern finden, ist, dass sie sich oft ausbreiten. Wenn es einen Fehler in IE9 gibt, besteht die Möglichkeit, dass der Fehler auch in IE8 existiert. Wenn etwas auf Safari auf iOS 7 unkonventionell aussieht, sieht es auf iOS 6 wahrscheinlich noch ausgeprägter aus. Sehen Sie hier ein Muster? Die älteren Browser sind in der Regel die problematischen. Das sollte Ihnen helfen, eine ziemlich gute Liste problematischer Browser zu erstellen.

Untermauern Sie diese jedoch mit Nutzungsstatistiken. IE 6 ist zum Beispiel ein sehr problematischer Browser, aber wir machen uns nicht die Mühe, ihn zu testen, weil sein Gesamtmarktanteil zu gering ist. Die Zeit, die für die Behebung von IE6-spezifischen Fehlern aufgewendet wird, wäre die Mühe für die kleine Anzahl von Benutzern, deren Erfahrung verbessert werden würde, nicht wert.

Es sind nicht immer die älteren Browser, die Sie in der Raid-Phase testen möchten. Wenn Sie beispielsweise ein experimentelles 3D-WebGL-Canvas-Projekt mit Bild-Fallback haben, erhalten ältere Browser nur das Fallback-Bild, sodass wir wahrscheinlich nicht viele Fehler finden werden. Was wir stattdessen tun möchten, ist, unsere Wahl des problematischen Browsers basierend auf der vorliegenden Anwendung zu ändern. In diesem Fall könnte IE9 ein guter Browser zum Testen sein, da es die erste Version von IE ist, die Canvas unterstützt.

Moderne Proxy-Browser (z. B. Opera Mini) können auch eine gute Wahl für einen Raid-Test sein, wenn Ihre Anwendung CSS3-Funktionen wie Farbverläufe oder Rahmenradius verwendet. Ein häufiger Fehler besteht darin, weißen Text auf einem nicht unterstützten Farbverlauf zu rendern, was zu unlesbarem Weiß-auf-Weiß-Text führt.

Verwenden Sie bei der Auswahl Ihrer problematischen Browser Ihre Intuition und versuchen Sie vorherzusehen, wo sich die Fehler verstecken könnten.

Diversifizieren Sie Ihre problematischen Browser

Browser und Browserversionen sind nur ein Teil der Gleichung: Auch die Hardware spielt eine wichtige Rolle. Sie sollten Ihre Anwendung auf verschiedenen Bildschirmgrößen und unterschiedlichen Pixeldichten testen und versuchen, zwischen Hoch- und Querformat zu wechseln.

Es kann verlockend sein, verwandte Browser zusammen zu gruppieren, da die Aufwandskosten vermeintlich reduziert werden. Wenn Sie VirtualBox bereits zum Testen von IE8 geöffnet haben, scheint jetzt ein guter Zeitpunkt zu sein, um auch in IE9, IE10 und IE11 zu testen. Wenn Sie sich jedoch in der Anfangsphase des Testens Ihrer Web-App befinden, sollten Sie dieser Versuchung widerstehen und stattdessen drei oder vier Browser-Hardware-Kombinationen wählen, die sich deutlich voneinander unterscheiden, um eine möglichst große Abdeckung über die Gesamtheit zu erhalten Bug Space, wie Sie können.

Obwohl diese von Projekt zu Projekt variieren können, hier sind meine aktuellen problematischen Browser der Wahl:

• IE 8 auf einer Windows XP-VM;
• nativer Android-Browser 2 auf einem Android-Tablet der Mittelklasse;
• Safari auf einem iPhone 4 mit iOS 6;
• Opera mini (nur wirklich testenswert bei Inhalten, die ohne JavaScript funktionieren sollen, wie z. B. Datapics).

Faul sein. Finden Sie so viele Fehler wie möglich, indem Sie Ihre App auf die problematischsten unterstützten Browser und Geräte werfen. Wenn diese Fehler behoben sind, können Sie mit der letzten Phase des Angriffs fortfahren.

3. Freigabe: Plausibilitätsprüfung

Sie haben Ihre App jetzt in den härtesten Browsern getestet, die Sie unterstützen müssen, und hoffentlich die meisten Fehler gefunden. Aber Ihre Anwendung ist noch nicht ganz fehlerfrei. Ich bin immer wieder überrascht, wie unterschiedlich selbst die neuesten Versionen von Chrome und Firefox denselben Inhalt wiedergeben. Sie müssen noch einige Tests durchführen.

Es ist die alte 80:20-Regel. Bildlich gesprochen haben Sie 80 % der Fehler behoben, nachdem Sie 20 % der Browser getestet haben. Jetzt möchten Sie die Erfahrung von 80 % Ihres Publikums überprüfen, indem Sie andere 20 % der Browser testen.

Priorisierung der Browser

Der einfache und offensichtliche Ansatz besteht nun darin, zu „traditionellen“ Cross-Browser-Tests zurückzukehren, indem jeder Browser in absteigender Reihenfolge seines Marktanteils angegangen wird. Wenn Chrome Desktop zufällig den höchsten Anteil des Browseranteils Ihrer Zielgruppe ausmacht, gefolgt von Safari auf iOS 8, gefolgt von IE11, dann ist es sinnvoll, in dieser Reihenfolge zu testen, oder?

Das ist ein weitgehend faires System, und ich möchte diesen Schritt nicht zu kompliziert machen, wenn Ihre Ressourcen bereits ausgelastet sind. Tatsache ist jedoch, dass nicht alle Browser gleich sind. In meinem Team gruppieren wir Browser nach einem Entscheidungsbaum, der die Browsernutzung, die einfache Aktualisierung und die Frage berücksichtigt, ob der Browser der Standard des Betriebssystems ist oder nicht.

Bisher sollte Ihre Tabelle eine Spalte für den Browser und eine Spalte für seinen Marktanteil haben; Sie brauchen jetzt eine dritte Spalte, die angibt, in welche Priorität der Browser fällt. Um ehrlich zu sein, hätte diese Priorisierungsarbeit vor dem Start des dreiphasigen Angriffs erfolgen sollen, aber für die Zwecke dieses Artikels war es sinnvoller, sie hier zu beschreiben, da die Prioritäten erst in der Klärungsphase wirklich benötigt werden.

Hier ist unser Entscheidungsbaum:

Wir haben unseren Entscheidungsbaum so gestaltet, dass P1-Browser etwa 70 % unserer Zielgruppe abdecken. P1- und P2-Browser zusammen decken ungefähr 90 % unserer Zielgruppe ab. Schließlich bieten uns die P1-, P2- und P3-Browser eine nahezu vollständige Zielgruppenabdeckung. Unser Ziel ist es, in allen P1-Browsern zu testen, gefolgt von P2, gefolgt von P3, in absteigender Reihenfolge des Marktanteils.

Wie Sie in der Tabelle weiter vorne in diesem Artikel sehen können, haben wir nur eine Handvoll P1-Browser. Die Tatsache, dass wir die Erfahrungen von über 70 % unserer Zielgruppe so schnell überprüfen können, bedeutet, dass wir kaum eine Entschuldigung dafür haben, diese Browser nicht erneut zu testen, wenn sich die Codebasis ändert. Während wir zu den P2- und P3-Browsern hinuntergehen, müssen wir immer größere Anstrengungen unternehmen, um die Erfahrung einer immer kleiner werdenden Zielgruppengröße zu verifizieren, also müssen wir realistischere Testideale für die Browser mit niedrigerer Priorität festlegen. Als Richtlinie:

• P1 . Wir müssen diese Browser einer Plausibilitätsprüfung unterziehen, bevor wir uns von der Anwendung abmelden. Wenn wir kleine Änderungen an unserem Code vornehmen, sollten wir diese Browser erneut auf Plausibilität prüfen.
• P2 . Wir sollten diese Browser auf Plausibilität prüfen, bevor wir uns von der Anwendung abmelden. Wenn wir große Änderungen an unserem Code vornehmen, sollten wir diese Browser erneut auf Plausibilität prüfen.
• P3 . Wir sollten diese Browser einmal auf Plausibilität überprüfen, aber nur, wenn wir Zeit haben.

Vergessen Sie nicht die Notwendigkeit, Ihre Hardware zu diversifizieren. Wenn Sie in der Lage sind, auf einer Vielzahl unterschiedlicher Bildschirmgrößen und auf Geräten mit unterschiedlichen Hardwarefunktionen zu testen, während Sie dieser Liste folgen, tun Sie dies.

Zusammenfassung: der Drei-Phasen-Angriff

Sobald Sie sich die Mühe gemacht haben , Ihren Feind zu kennen ( Ihre Publikumsstatistiken zu vereinfachen und Browser in Prioritäten zu gruppieren ), können Sie in drei Schritten angreifen:

1. Reconnaissance : exploratives Testen auf Ihrem bevorzugten Browser, um browserunabhängige Fehler zu finden .
2. Raid : Testen auf Ihren problematischsten unterstützten Browsern auf einer Vielzahl von Hardware, um die meisten Fehler zu finden .
3. Freigabe : Überprüfung der Erfahrung Ihrer Anwendung auf den am weitesten verbreiteten und strategisch wichtigen Browsern, um mit quantitativ gestützter Gewissheit zu sagen, dass Ihre Anwendung funktioniert .