Die Entscheidung, welche Browser, Geräte und Versionen eine Anwendung unterstützt, scheint eine technische Aufgabe zu sein. Ihre Folgen betreffen jedoch Produkt, Geschäft und Betrieb. Eine zu breite Liste kann Entwicklungs- und Testkapazitäten binden; eine zu restriktive Auswahl kann wichtige Nutzer ausschließen oder gegenüber Kunden eingegangene Verpflichtungen verletzen.
Die Lösung besteht weder darin, jeder Neuerscheinung hinterherzulaufen, noch darin, aus Gewohnheit eine Version festzulegen. Stattdessen sollte dokumentiert werden, welche Umgebungen unterstützt werden, mit welchem Maß an Verlässlichkeit und unter welchen Bedingungen die Entscheidung überprüft wird. Eine solche Matrix macht aus einer wiederkehrenden Diskussion eine gemeinsame Entscheidungsgrundlage.
Kompatibilität ist eine Produkt- und Betriebsentscheidung
Eine kompatible Umgebung ist nicht einfach eine Umgebung, in der sich die Anwendung öffnen lässt. Entscheidend ist auch, ob die wichtigsten Funktionen zuverlässig arbeiten, ob die Nutzererfahrung akzeptabel ist und ob das Team Probleme erkennen und beheben kann. Die Entscheidung sollte deshalb die tatsächliche Nutzung und die Wartungskapazitäten widerspiegeln – nicht nur eine technische Präferenz.
Ermitteln Sie zunächst, welche Folgen ein Fehler hätte. Bei einem internen Werkzeug kann eine vorübergehende Alternative ausreichen; bei einem Kaufvorgang oder einer für die Arbeit kritischen Anwendung können die Auswirkungen größer sein. Auch vertragliche Verpflichtungen, Sicherheitsrichtlinien oder Barrierefreiheitsanforderungen können vorgeben, welche Umgebungen berücksichtigt werden müssen.
Legen Sie fest, wer die Matrix vorschlägt, prüft und freigibt. Das Produktteam kann Anforderungen und Nutzergruppen priorisieren, die Technik Machbarkeit und Risiken bewerten und Support sowie Geschäftsfunktionen Vorfälle und Verpflichtungen gegenüber Nutzern einbringen. Gibt es keine verantwortliche Instanz, nehmen Ausnahmen oft zu, ohne dass jemand ihre Kosten übernimmt.
Erst Belege sammeln, dann Versionen auswählen
Ausgangspunkt ist der Nutzungskontext. Ermitteln Sie, welche Browser und Geräte Nutzer für relevante Aufgaben einsetzen – nicht nur, welche im allgemeinen Datenverkehr am häufigsten vorkommen. Unterscheiden Sie beispielsweise zwischen Anmeldung, Abschluss eines wichtigen Vorgangs und dem Aufrufen von Inhalten. Eine selten genutzte Umgebung kann für einen Kunden oder einen bestimmten Prozess unverzichtbar sein.
Berücksichtigen Sie mehrere Informationsquellen:
- Nutzungsanalysen: Ermitteln Sie verfügbare Angaben zu Browsern, Betriebssystemen, Bildschirmgrößen und Nutzungsmustern. Interpretieren Sie die Daten vorsichtig: Sie können Nutzer ausschließen, die einer Messung nicht zustimmen oder den Ladevorgang nicht abschließen.
- Support und Vertrieb: Prüfen Sie wiederkehrende Vorfälle, von Kunden genannte Anforderungen und bestehende Vereinbarungen. Unterscheiden Sie eine einzelne Anfrage von einer durch Belege gestützten Anforderung.
- Technische Anforderungen: Dokumentieren Sie Abhängigkeiten des Produkts, benötigte Browserfunktionen, Sicherheitsrichtlinien und Einschränkungen verwalteter Geräte.
- Teamkapazität: Schätzen Sie den Aufwand für Entwicklung, Tests, Diagnose und Wartung. Eine zusätzliche Umgebung bedeutet mehr, als sie lediglich in eine Liste aufzunehmen.
Wenn Daten fehlen, halten Sie dies als Unsicherheit fest. Sie können den Bedarf durch Gespräche, Supportaufzeichnungen oder einen begrenzten Test überprüfen. Leiten Sie aus fehlenden Belegen nicht ab, dass niemand diese Umgebung nutzt.
Kriterien und Supportstufen festlegen
Definieren Sie Kriterien, die sich einheitlich anwenden lassen. Dazu können Umfang und Bedeutung der Nutzung, die Kritikalität der Aufgaben, die Kompatibilität mit benötigten Technologien, Sicherheitsrisiken, Kundenanforderungen und der Aufwand für die Testpflege gehören. Diese Kriterien müssen nicht zu einer einzigen Punktzahl zusammengefasst werden: Eine vertragliche Verpflichtung kann beispielsweise schwerer wiegen als die Nutzungshäufigkeit.
Eine Einteilung in drei Stufen ist hilfreich:
- Garantierter Support: Die Umgebung ist Teil des veröffentlichten Leistungsversprechens. Die wichtigsten Funktionen werden getestet und reproduzierbare Fehler nach dem regulären Produktprozess bearbeitet.
- Validiert: Das Team hat eine festgelegte Auswahl an Abläufen geprüft, verspricht jedoch weder eine vollständige Abdeckung noch eine gleichwertige Priorisierung bei jedem Problem. Geben Sie an, was validiert wurde und welche Einschränkungen bekannt sind.
- Nicht unterstützt: Das Team testet die Umgebung nicht und gewährleistet ihre Funktionsfähigkeit nicht. Falls die Anwendung dennoch zugänglich ist, weisen Sie darauf hin, ohne den Eindruck zu erwecken, die Nutzung werde abgedeckt.
Vermeiden Sie unklare Formulierungen wie „kompatibel mit allen modernen Browsern“. Nennen Sie Browser und Versionen oder legen Sie ein überprüfbares Kriterium für die unterstützten Versionen fest. Wenn der Support auf aktuellen Versionen beruht, definieren Sie, wie dieser Zeitraum berechnet wird und wo die Regelung veröffentlicht ist. Präzise Angaben verhindern, dass Nutzer und Teams ein Versprechen unterschiedlich auslegen.
Die Kosten für ältere Umgebungen abwägen
Die Unterstützung älterer Versionen kann Behelfslösungen, zusätzliche Testkombinationen und die Bearbeitung von Fehlern erfordern, die in aktuellen Umgebungen nicht auftreten. Aber auch die Einstellung des Supports hat Kosten: betroffene Nutzer, unterbrochene Abläufe, verlorener Zugang sowie Kommunikations- oder Migrationsaufwand. Vergleichen Sie beide Seiten, statt den geringeren Wartungsaufwand automatisch als Vorteil zu betrachten.
Gründe für eine erneute Prüfung können eine dauerhaft geringe Nutzung, das Fehlen bekannter Anforderungen, erhebliche Sicherheitsmängel, Einschränkungen notwendiger Änderungen oder ein unverhältnismäßiger Testaufwand sein. Kein einzelner Hinweis reicht für sich allein aus. Prüfen Sie, ob die Daten die betroffene Nutzergruppe abbilden und ob es eine praktikable Alternative gibt, etwa ein aktualisiertes Gerät, einen anderen Browser oder einen mit dem Kunden vereinbarten Übergang.
Ermitteln Sie vor dem Ende des Supports, welche Aufgaben möglicherweise nicht mehr funktionieren, wie viele und welche Nutzer betroffen sein könnten, welche internen Abhängigkeiten bestehen und wann die Änderung erfolgen soll. Legen Sie fest, ob es eine Vorankündigung, eine Anlaufstelle für Fragen oder eine befristete Ausnahme gibt. Jede Ausnahme sollte eine verantwortliche Person, eine Begründung, einen Geltungsbereich und einen Überprüfungstermin haben. Andernfalls wird daraus leicht ein unbegrenzter Supportfall.
Die Matrix prüfen und verständlich kommunizieren
Die Matrix muss den tatsächlich durchgeführten Tests entsprechen. Legen Sie für jede Umgebung mit garantiertem Support fest, welche kritischen Abläufe geprüft werden und wann: vor einer Veröffentlichung, gegebenenfalls durch automatisierte Tests sowie manuell, wenn das Verhalten dies erfordert. Es ist nicht nötig, jede mögliche Kombination aus Gerät, Version und Konfiguration zu testen. Erklären Sie aber, welche Abdeckung gewählt wurde und welche Risiken nicht abgedeckt sind.
Priorisieren Sie Abläufe mit wichtigen Auswirkungen: Anmeldung, Hauptfunktion, Formulare, gegebenenfalls Zahlungen und die Fehlerbehebung. Prüfen Sie außerdem die Darstellung auf relevanten Bildschirmgrößen, die Tastaturnavigation und Meldungen zu nicht verfügbaren Funktionen. Analyse- und Leistungstools können Hinweise liefern, ersetzen jedoch weder Funktionsprüfungen noch die Untersuchung von Vorfällen.
Veröffentlichen Sie die Matrix an einem für Nutzer und interne Teams leicht zugänglichen Ort. Nennen Sie das Aktualisierungsdatum, die Supportstufen, bekannte Einschränkungen, empfohlene Alternativen und eine Kontaktmöglichkeit, über die Probleme gemeldet werden können. Kann eine nicht unterstützte Umgebung auf die Anwendung zugreifen, erklären Sie, dass ihre Funktion nicht gewährleistet ist. Stellen Sie einen Warnhinweis nicht als Bestätigung dar.
Praxistemplate und regelmäßige Überprüfung
Eine hilfreiche Matrix lässt sich intern als Tabelle pflegen und in der Nutzerdokumentation zusammenfassen. Halten Sie mindestens Folgendes fest:
- Umgebung: Browser oder Anwendung, Betriebssystem, Gerät und Version oder Aktualisierungsregel.
- Supportstufe: garantiert, validiert oder nicht unterstützt.
- Belege und Risiken: beobachtete Nutzung, bekannte Anforderungen, Einschränkungen und geprüfte Abläufe.
- Verantwortliche: Person oder Team, das die Entscheidung pflegt und Vorfälle koordiniert.
- Überprüfungsbedingung: vereinbarter Termin oder eine Änderung, die eine Neubewertung auslöst, etwa eine neue Abhängigkeit, ein Vorfall oder eine Kundenanforderung.
Überprüfen Sie die Matrix in einem vereinbarten Rhythmus und außerdem bei wesentlichen Änderungen. Sie muss nicht mit jeder neuen Version angepasst werden. Bewerten Sie vor einer Aktualisierung die Auswirkungen, erforderlichen Tests, Kommunikation und Alternativen. Halten Sie anschließend die Begründung der Entscheidung fest, damit der nächste Überprüfungszyklus nicht bei null beginnt.
Das Ergebnis ist kein Versprechen, dass die Anwendung auf jedem Gerät fehlerfrei funktioniert. Es ist eine klare Festlegung, in welche Umgebungen das Team Aufwand für Prüfung und Wartung investiert, welche Unsicherheiten es akzeptiert und wie es auf veränderte Anforderungen reagiert. Diese Klarheit ermöglicht angemessene Entscheidungen und verringert unangenehme Überraschungen.