Bevor eine neue Website oder auch nur ein neues Feature einer bestehenden Website online geht, findet eine Phase der Qualitätssicherung (QS) statt. Dabei gibt es online reichlich Checklists, die einem die wichtigsten Punkte auflisten, die es dabei zu beachten gibt (z.B. webdevchecklist.com, frontendtest.com, launchlist.net). Diese Listen sind ein großartiger Ausgangspunkt, aber es wird einem dabei schnell klar, dass der eine oder andere Punkt für das aktuelle Projekt gar nicht relevant ist und umgekehrt gibt es neue spezifische Anforderungen, die überprüft werden müssen. Im Idealfall sollte sich die eigene Checklist eigentlich schon durch ein umfassendes Konzept ergeben.

Das Tool der Wahl, um seine Checklist abzuarbeiten, ist dabei zweitrangig. Egal ob ein darauf spezialisierter Service wie launchlist.net, Excel oder eine der unzähligen Listenapps zum Einsatz kommt, man kommt nicht daran vorbei, eine vorgegebene Liste zu überarbeiten und diese, je nach Projekt, wieder neu zu evaluieren. In diesem Artikel geht es aber nicht um die ultimative Checklist für den Website Launch, sondern um einen allgemeinen Blick auf die Bereiche der Frontend-Qualitätssicherung und weshalb dabei Erfahrung über ein weites Spektrum an Gebieten notwendig ist.

Funktion

Zuerst geht es natürlich darum, die grundsätzliche Funktionalität sicher zu stellen. Vieles davon lässt sich automatisiert testen: Funktionieren alle Links, ist der HTML- und CSS-Code valide? Diese Automatisierung erschlägt einen oft mit einer langen Liste an vermeintlich schwerwiegenden Fehlern. Ohne Programmiererfahrung könnte man hier nicht mehr tun, als diese zurück an die Entwicklungsabteilung zu geben. Doch es ist weit sinnvoller, wenn z.B. Folgefehler erkannt und entsprechend zusammengefasst werden. Außerdem ist valider Code nicht immer gewünscht bzw. möglich: Browserhacks sind zwar seltener geworden, aber die Verwendung diverser JavaScript Frameworks oder die Einbindung externer APIs lassen einen 100 Prozent validen Code oft nicht zu oder der Aufwand steht einfach gar nicht dafür. Das sind wiederum Fälle, die man als Programmierer erkennen kann, und damit nicht extra die Entwicklungsabteilung quälen muss. Beim Blick auf den Sourcecode stößt man leider oft auf Probleme, die man an dieser Stelle nicht beheben wird können. Semantisch sinnvoller HTML-Code sollte z.B. eine Voraussetzung sein, aber spätestens wenn irgendein Freelancer darauf gepfiffen hat, sollte man sich daran erinnern, dass es so etwas wie Coding Guidelines geben sollte.

Meiner Erfahrung nach verbringt man beim Funktionstest die meiste Zeit damit, interaktive Elemente zu testen. Während man vor 5 Jahren oft noch damit beschäftigt war, die Einschränkungen von IE6 zu umgehen, bieten aktuell die Limitationen von Mobilgeräten ähnliche Herausforderungen und dementsprechend hat sich der Fokus verschoben. Mit interaktiven Elementen meine ich alles vom einfachen Drop-Down-Menü über ein Kontaktformular bis hin zu komplexeren Webanwendungen mit authentifizierten Usern. Wichtig beim Testen ist dabei nicht nur, den Normalfall durchzuspielen, sondern gezielt Edgecases zu probieren.

Ob man jetzt seine eigene Sammlung an VMs und Geräten hat oder lieber einen entsprechenden Service (u.a. crossbrowsertesting.com, saucelabs.com, browserstack.com, spoon.net) beansprucht – beides hat Vor- und Nachteile – ist eigentlich egal und vor allem eine Frage der Anforderungen. Ein paar konkrete Tipps zum Testen von komplexeren Webanwendungen:

  • Domain mit Catch-All E-Mail-Adresse einrichten. So lassen sich einfach mehrere "User" anlegen und zum Beispiel eine Anmeldung kann problemlos mehrmals durchgespielt werden.
  • States definieren, auf welche eine Anwendung gestellt werden kann. Also z.B. Highscore zurücksetzen oder Gewinnspiel ist abgelaufen. Idealerweise kann ich das als Tester selbst einstellen, ohne, dass ich dafür erneut in die Entwicklung zurück muss.
  • Die Dinge unter der Oberfläche nicht vergessen, z.B. Monitoring- und Tracking-Einbindung.

Design

Um die Qualitätssicherung für den Designbereich durchzuführen, muss man kein Designprofi sein, aber ein gewisses Vorwissen in diesem Bereich ist schon notwendig. Mir geht es dabei nicht darum, dass ein Design pixelperfekt von der Vorlage übernommen wird, solange die Umsetzung dem grundsätzlichen Look treu bleibt. Das betrifft vor allem solche Bereiche, für die es keine explizite Designvorlage gibt. Was passiert, wenn ein Textfeld größer werden muss, als ursprünglich gedacht? Wie verhält sich das Design bei ungewöhnlichen Auflösungen? Dabei geht es nicht nur um verschiedene Devices. Browserfenster werden schließlich nicht immer maximiert betrachtet. Gerade solche Edgecases werden beim Design und später in der Umsetzung oft vergessen und machen den qualitativen Unterschied aus.

Content

Dass der richtige Content auf der Website sein muss, mag selbstverständlich klingen. Aber es geht hier nicht nur darum, dass die Rechtschreibung überall passt und nicht doch irgendwo auf ein Lorem Ipsum oder Platzhalterbilder vergessen wurde. Viel öfter wird auf den Content vergessen, der unter der Oberfläche sein muss. Also Content, der für die automatisierte Verarbeitung durch andere wichtig ist und nicht sofort zu sehen ist, wenn man die Website im Browser betrachtet: Open Graph Tags, Meta-Description, robots.txt, Favicons für verschiedene Devices. Alles Dinge, die man von der klassischen Suchmaschinenoptimierung kennt.

Usability

Websites können funktionieren und keine Fehler haben, aber trotzdem unbrauchbar sein. Formulare zum Beispiel, die umständlich auszufüllen sind, haben sicher die meisten von uns schon davon abgehalten, etwas online zu reservieren oder einen Newsletter zu abonnieren. Komplexe Prozesse müssen natürlich schon zu Beginn eines Projekts auf ihre einfache Bedienung hin konzipiert und im Idealfall durch Prototypen überprüft und angepasst werden. Eine QS in der finalen Phase ist normalerweise der falsche Zeitpunkt, Konzepte noch einmal komplett über den Haufen zu werfen, aber kleine Anpassungen sind auch in dieser Phase noch möglich. Können Links und Buttons noch etwas vergrößert und damit touch-freundlicher gemacht werden? Sind Fehlermeldungen verständlich genug? Gerade durch Textänderungen können komplizierte Vorgänge noch verständlicher gemacht werden. Der Input einer Person, die mit dem Projekt ansonsten noch keinen Kontakt hatte, zeigt hier oft Probleme auf und kann sehr hilfreich sein.

Neben Usability ist Accessability, also Barrierefreiheit ein wichtiges Thema, das man in der QS ebenfalls testen sollte. Das meiste davon ist automatisiert möglich. Die Erfahrung zeigt, dass es dann eher an der Betreuung hakt, wenn es darum geht, dass neuer Content laufend barrierefrei aufbereitet wird.

Performance

Performanceoptimierung sollte mittlerweile Teil einer Frontendpipeline sein, die sich darum kümmert, dass Bilder optimiert, Code minified und Requests reduziert werden. Auf der anderen Seite ist eine angepasste Auswahl der Hostingumgebung und Serverkonfiguration notwendig. Beides kann automatisiert getestet werden. Hier ist technisches Knowhow unumgänglich, um Testergebnisse entsprechend zu interpretieren. Je nach Projekt ist aber nicht jede mögliche Optimierung auch unbedingt sinnvoll.

Security

Auch die Überprüfung auf mögliche Sicherheitsschwachstellen einer Website ist meist ein automatisierter Prozess. Bei Funktionen aber, die ein höheres Risiko mit sich bringen könnten (z.B. Benutzerauthentifizierung für einen privaten Userbereich oder Dateiuploads für einen Contest) ist zusätzlich ein manuelles Code Audit von einem Senior Developer, der nicht direkt an der Programmierung beteiligt gewesen ist, sinnvoll.

Automatisierung

Automatisierung nimmt dem Tester viel Arbeit ab und hilft, auf keine Aspekte zu vergessen. Automatisierte Tests bringen aber oft auch eine Fülle an Informationen und vermeintlichen Fehlern mit, die erst sondiert werden müssen. Wie erwähnt findet diese Sondierung idealerweise bereits beim Tester und nicht erst beim Developer statt. Ein Developer sollte sich darauf konzentrieren können, guten Code zu schreiben, und nicht ständig der Projektleitung erklären müssen, wieso dieser Fehler eigentlich gar keiner ist und im speziellen Fall eine vorgeschlagene Optimierung gar keinen Sinn macht. Automatisierung scheitert aktuell auch noch an einigen Aufgaben. Mittlerweile können komplexe Interaktionsabfolgen auf einer Vielzahl von verschiedenen Browsern simuliert werden. Die Dokumentation von Darstellungsproblemen erfolgt meistens über den Vergleich von Screenshots. Beim Test von Animationen oder z.B. Scrolleffekten tut man sich hier aber schwer. Videoergebnisse sind mittlerweile möglich, aber eine manuelle Kontrolle fällt auch hier noch nicht weg.

Feedback Loop

Das Ergebnis der Qualitätssicherung ist eine Liste von Fehlern und Empfehlungen, in der einen oder anderen Form. Das soll aber kein Einbahnsystem von der QS zurück zur Entwicklung sein. Behobene Fehler müssen erneut überprüft werden und es muss abgewogen werden, welche zusätzlichen Tests womöglich wiederholt werden sollen. Für eine einfache Website mag hier ein umfangreiches Bugtracking-System übertrieben sein, aber irgendeine Art von Taskmanagement, über das Verantwortlichkeiten klar zugeordnet werden können, ist auf jeden Fall notwendig, sobald mehrere Personen involviert sind.

Organisatorische Fragen

Während eine Checkliste zur Frontend-QS vor dem Launch wichtig ist, um mit einer perfekten Onlinepräsenz zu starten, liegt der vielleicht wichtigste Teil für die Qualität einer Website danach bei einer fortlaufenden Betreuung. Das ist nicht unbedingt Teil der QS-Abteilung, aber es schadet nicht, spätestens zu diesem Zeitpunkt noch einmal darauf hinzuweisen, dass alle Zuständigkeiten mit dem Kunden abgeklärt sind:

  • Ist eine Kundenschulung notwendig?
  • Wer übernimmt die laufende Wartung? Gibt es eine komplette Redaktion und Redaktionspläne?
  • Wer übernimmt die laufende technische Betreuung? Wie schnell müssen Updates eingespielt werden und wie werden diese getestet?
  • Welche Art von Systemmonitoring ist notwendig? Was passiert bei Ausfällen?
  • Wie sieht es mit Tracking und laufender Analyse aus?