Geräte- und Browser-Tests in der Praxis

Dieser Artikel ergänzt die Browser- und Geräte-Testliste um Erkenntnisse und Rückmeldungen aus der Praxis — von Leser:innen und aus eigenen Projekten.

„Damit öffnest du die Büchse der Pandora"

Ein berechtigter Einwand gegen das Testen auf echten Geräten: Es steht schnell eine Menge Hardware auf dem Tisch, um die man sich kümmern muss — und dann stellt sich auch noch die Frage nach Browser-Version, Android-Version und so weiter.

Eine Alternative ist das Android SDK, mit dem sich gewünschte Geräte gut simulieren lassen (inklusive BrowserSync und DevTools) — vergleichbar mit Xcode auf dem Mac. Alles lässt sich damit nicht testen, aber es ist allemal besser, als gar keine Android-Tests zu machen.

Und ja: Mit zwei Android-Geräten deckt man nur einen sehr kleinen Teil der Android-Welt ab. Aber solange du Layouts auf einem durchschnittlichen Smartphone und Tablet testest, kannst du guten Gewissens behaupten, für den Durchschnitt zu entwickeln. Das macht auch Diskussionen mit Kund:innen einfacher: „Ich habe das Layout gemäß unseres Leistungsverzeichnisses mit einem iPhone und einem Samsung getestet und kann sagen, dass der Fehler dort nicht auftaucht" ist eine deutlich bessere Antwort als „Ich habe leider kein Android-Gerät".

Statistiken als Anhaltspunkt

Vor der Entwicklung lohnt ein Blick in die Statistiken der bestehenden Website. Sie können zwar täuschen — etwa wenn viele Mitarbeiter:innen mit alten Geräten die Website besuchen. Dennoch sind sie ein wichtiger Anhaltspunkt, welche Geräte und Auflösungen genauer betrachtet werden sollten. Ein Beispiel: Privat sind Tablets zum abendlichen Surfen beliebt, in den Statistiken vieler Projekte spielen sie hingegen (fast gar) keine Rolle.

Fallstrick 1: Dropdown-Menüs unter iOS und Android

Ein Problem, das überrascht hat: die unterschiedliche Handhabung von Dropdown-Menüs. Unter iOS lassen sich Dropdowns so per CSS gestalten, dass der erste Tap das Submenü öffnet und erst der zweite Tap den Link des Hauptmenüpunkts ausführt. Unter Android öffnet der erste Tap immer den Menüpunkt — das Submenü lässt sich erst öffnen, wenn der Hauptmenüpunkt aktiv ist (also ein <strong> statt einem <a> ist).

Ist der Hauptmenüpunkt aber eine interne Weiterleitung, kann es passieren, dass man das Submenü nie zu sehen bekommt. Deswegen öffnet sich das Submenü in LASR auf Tablets per JavaScript.

Fallstrick 2: Scrollbare mobile Navigation

Bei einer mobilen Navigation sollte overflow-y: auto; sicherstellen, dass ein Menü mit vielen Punkten scrollbar ist. Unter iOS funktionierte diese Lösung — unter Android waren die untersten Menüpunkte aber nicht erreichbar, weil Abstände innerhalb des Containers anders berücksichtigt wurden. Erst mit anders verteilten Abständen und Anpassungen an der Positionierung war das komplette Menü auch unter Android erreichbar.

Bemerkenswert dabei: Ob der Fehler in Chrome am Mac aufgefallen wäre, ist fraglich. Mit einem Android-Gerät in der Hand — und weniger Platz auf dem Display durch den Browser-Rand — fiel er dagegen sehr schnell auf.

Der Aufwand lohnt sich

Die ganze Testerei und die entsprechenden Optimierungen erfordern ein robustes Nervenkostüm, keine Frage. Aber gerade wer für Agenturen arbeitet, die das Layout ebenfalls testen, hat nur zwei Optionen: möglichst viele Fehler selbst finden und ausbessern — oder warten, bis sie als Tickets zurückkommen. Augen zu und Daumen drücken ist keine Option.