Du hast Wochen in dein Setup gesteckt. Die Emby- oder Jellyfin-Bibliothek wird gescannt, die Nextcloud-Apps sind installiert, die Website lädt auf deinem Laptop. Dann öffnet ein Freund sie auf einem Fernseher, einem Handy und in einem Browser – und irgendetwas funktioniert „manchmal“ nicht. Genau das ist der Moment, in dem sich eine unabhängige Prüfung lohnt.
Dieses Tutorial zeigt, wie wir ein QA-Audit bei Qualitätssicherung durchführen – geschrieben so, dass du dieselben Prüfungen selbst machen oder die Liste abgeben und ein paar Stunden Testing einkaufen kannst. Das Ergebnis ist immer dasselbe: ein schriftlicher Bericht darüber, was getestet wurde, was gefunden wurde und was zuerst zu beheben ist. Betrachte es als Website-Test-Checkliste und Medienserver-Checkliste in einem Durchgang. Wenn du deine Website testen willst, hilft dir dieser Ablauf, systematisch statt nach Bauchgefühl vorzugehen.
Was du zuerst brauchst
- Eine Staging-Kopie oder ein ruhiges Zeitfenster auf dem Live-System. Zum Audit gehört ein Probelauf des Updates auf einer Kopie deines Servers, eine Kopie ist also ideal – ein Abend mit wenig Traffic funktioniert aber auch.
- Die Liste der Dinge, die zählen: welche Clients die Leute tatsächlich nutzen (Fernseher, Handys, Browser, Client-Apps), welche Benutzer und Berechtigungen es gibt, welche Ports ins Internet offen sind.
- Zugang für den Tester: ein Admin-Konto auf dem Medienserver oder der Nextcloud-Instanz und ein normales Benutzerkonto, denn Berechtigungen gehören zum Test.
- Ein Weg, uns den Umfang mitzuteilen: das Kontaktformular, ein Ticket oder Telegram. Du bekommst kostenlos einen schriftlichen Kostenvoranschlag mit Umfang und Stunden, bevor irgendetwas gekauft wird.
Stunden kaufst du auf der Produktseite mit einem Minimum von einer Stunde; sie werden in 15-Minuten-Schritten verbraucht. Nicht verbrauchte Stunden bleiben 12 Monate in deinem Konto.
Schritt 1: Den Umfang festhalten
Bevor irgendetwas angefasst wird, einigt ihr euch darauf, was geprüft wird. Das Audit umfasst Software (Testplan, manuelle und automatisierte Tests, Fehlerberichte mit Schritten zur Reproduktion), Medien- und Mailserver (Emby, Jellyfin, Nextcloud oder mailcow: Konfiguration, Benutzer und Berechtigungen, Sicherheit, Leistung, Transcoding, Mailzustellung und Sicherungen), Geräte (Fernseher, Handys, Browser, Client-Apps: Kompatibilität, Untertitel, Tonspuren, Transcoding und Fernzugriff), Websites (Barrierefreiheit, SEO und Leistung mit Lighthouse und manuellen Prüfungen) sowie Änderungen (Probelauf von Updates, Test der Wiederherstellung von Sicherungen, Last- und grundlegende Sicherheitstests).
Wähle die Teile aus, die zu dir passen. Ein Jellyfin-Betreiber mit einer kleinen Website braucht eine andere Mischung als ein Nextcloud-Admin. Ein kurzer schriftlicher Umfang hält die Stunden fokussiert und macht den Abschlussbericht leichter lesbar.
Schritt 2: Die Wiedergabematrix aufbauen
Das ist der Kern einer Medienserver-Prüfung. Erstelle eine Tabelle mit deinen Clients als Zeilen und den Dingen, die kaputtgehen können, als Spalten.
Vorschlag für die Zeilen:
- Wohnzimmer-Fernseher mit der nativen App
- Handy (mindestens ein Android- und ein iOS-Gerät)
- Desktop-Browser
- Jede weitere Client-App, auf die deine Nutzer angewiesen sind
Vorschlag für die Spalten:
- Direkte Wiedergabe einer typischen Datei
- Transcoding einer Datei, die der Client nicht abspielen kann (prüfe, ob tatsächlich transkodiert wird statt zu scheitern)
- Untertitel: eingebettet und extern, und ob sie synchron bleiben
- Tonspuren: Wechsel zwischen ihnen mitten in der Wiedergabe
- Fernzugriff von außerhalb deines Netzwerks
Fülle jede Zelle mit bestanden oder fehlgeschlagen und einer einzeiligen Notiz. Die Fehlschläge listet der Bericht auf, jeweils mit Schritten zur Reproduktion und einer Schweregrad-Einstufung. Jage nicht jeder Kombination nach; eine repräsentative Stichprobe pro Client reicht, um die üblichen Verdächtigen zu erwischen.
Bei Emby und Jellyfin gehören Konfiguration und Berechtigungen in denselben Durchgang: Prüfe, dass ein normaler Benutzer keine Bibliotheken oder Admin-Bereiche sieht, die er nicht sehen soll, und dass die Transcoding-Einstellungen zu dem passen, was deine Hardware leisten kann.
Schritt 3: Die Sicherheitsexposition prüfen
Hier gibt es in kleinen Setups am häufigsten Überraschungen. Bleib auf der Konfigurationsebene: welche Ports aus dem Internet erreichbar sind, ob Zertifikate gültig sind und erneuert werden, welche Konten existieren und ob noch Standard- oder ungenutzte Admin-Konten aktiv sind. Bei Nextcloud sind Benutzer und Berechtigungen Teil der Medienserver-Prüfung; bei mailcow wird zusätzlich die Mailzustellung geprüft.
Grundlegende Sicherheitstests gehören zum Service, du musst also keine Exploits selbst ausprobieren. Was hilft, ist eine einfache Bestandsaufnahme: Liste jeden Dienst auf, den du exponierst, warum er exponiert ist und wer ihn erreichen können soll. Alles, was du nicht begründen kannst, wandert zurück hinter die Firewall oder das VPN. Wenn du das Audit selbst machst, ist diese Bestandsaufnahme allein oft schon einen Nachmittag wert.
Schritt 4: Leistung, SEO und Barrierefreiheit für die Website
Wenn du auch eine Website betreibst, umfasst das Audit Prüfungen für Barrierefreiheit, SEO und Leistung mit Lighthouse plus manuellen Prüfungen, mit Prioritäten. Führe Lighthouse auf einer repräsentativen Seite aus, nicht nur auf der Startseite, und notiere die drei Ergebnisse, die dir am wichtigsten sind. Manuelle Prüfungen fangen ab, was Lighthouse nicht kann: Tastaturnavigation, lesbarer Kontrast, aussagekräftiger Linktext, sinnvolle Überschriften.
Halte diesen Abschnitt im Bericht kurz und sachlich. „Largest contentful paint ist auf der Preisseite langsam, Bild ist unkomprimiert“ ist nützlicher als eine Wand voller Scores. Korrekturen können wir als individuelle Entwicklung übernehmen, oder dein eigenes Team erledigt sie anhand des Berichts.
Schritt 5: Das Update proben und eine Sicherung wiederherstellen
Ein Probelauf des Updates auf einer Kopie deines Servers beantwortet die Frage „Bricht die nächste Version meine Plugins oder Clients?“ bevor du es auf die harte Tour erfährst. Ein Test der Wiederherstellung von Sicherungen beantwortet die unangenehmere Frage: Lässt sich die Sicherung wirklich wiederherstellen? Beides gehört zum Service und beides gehört als bestanden oder fehlgeschlagen mit Notizen in den Bericht.
Lasttests sind ebenfalls möglich, wenn du einen Ansturm von Nutzern erwartest, etwa nachdem du einen Link veröffentlicht hast.
Schritt 6: Einen Bericht erstellen, mit dem du arbeiten kannst
Der Bericht ist das Ergebnis. Bestehe auf dieser Struktur, egal ob du ihn selbst schreibst oder unseren bekommst:
- Was getestet wurde, mit Umfang und den verwendeten Clients.
- Befunde, jeweils mit Schweregrad, Schritten zur Reproduktion und, wo sinnvoll, einem Screenshot.
- Was zuerst zu beheben ist, geordnet nach Schweregrad und Aufwand.
- Was bestanden hat, damit du weißt, was du nicht anfassen musst.
Der Schweregrad macht einen Bericht nützlich. Ein fehlgeschlagener Login für normale Nutzer ist nicht dasselbe wie ein Untertitel-Versatz auf einem Fernseher. Stufe ehrlich ein und halte die Liste kurz genug, um sie abzuarbeiten.
Schritt 7: Beheben, dann erneut testen
Korrekturen werden im Rahmen des Service erneut getestet. Diesen Schritt lassen die Leute aus: Eine Korrektur, die nicht überprüft wurde, ist eine Hoffnung, keine Korrektur. Führe die fehlgeschlagenen Zellen der Wiedergabematrix erneut aus, prüfe die geschlossenen exponierten Ports noch einmal und lass Lighthouse erneut über die geänderten Seiten laufen. Stunden werden in 15-Minuten-Schritten verbraucht, ein kurzer erneuter Test ist also günstig.
Tipps und Fehlerbehebung
- „Manchmal funktioniert es nicht“ ist ein Symptom, kein Bug. Notiere den Client, die Datei, die Uhrzeit und was du gesehen hast. Diese Notiz ist der Anfang einer Reproduktion.
- Teste mit einem normalen Benutzerkonto, nicht nur als Admin. Die meisten Berechtigungsprobleme verstecken sich dort.
- Teste möglichst nicht auf dem Live-Server zu Stoßzeiten; Transcoding-Tests und Lasttests konkurrieren mit echten Zuschauern.
- Halte den Umfang klein. Eine Stunde fokussiertes Testing ist besser als eine vage Anfrage „prüft mal alles“.
- Schreib den Bericht unterwegs. Schritte eine Woche später zu rekonstruieren kostet Stunden.
- Nutze die Wissensdatenbank und die FAQ für Einrichtungsfragen vor dem Audit, damit die Stunden in Testing statt in Konfigurationsgrundlagen fließen.
Fazit
Bei einem QA-Audit geht es nicht darum, Fehler in deiner Arbeit zu finden; es geht darum, „manchmal funktioniert es nicht“ durch eine Liste zu ersetzen, die du der Reihe nach abarbeiten kannst. Baue die Wiedergabematrix, erfasse, was du exponierst, lass Lighthouse über die Seiten laufen, die zählen, probiere das Update und die Wiederherstellung und pack alles in einen kurzen Bericht mit Schweregraden. Wenn du das lieber von jemandem Unabhängigen machen lässt: Umfang und Kostenvoranschlag sind kostenlos, und die Stunden liegen bei dir. Starte bei Qualitätssicherung.