Umgang mit Fehlern in mobilen Web-Applikationen

Tests sind ein wichtiger Teil der Softwareentwicklung, hierbei bildet die Entwicklung von Apps keine Ausnahme. In diesem Artikel erfahren Sie, welche Arten von Tests zur Verfügung stehen und wie man Fehlermeldungen verständlich für die Nutzer aufbereitet.

Für moderne Portale und andere Web-Anwendungen spielen mobile Web-Applikationen eine immer größer werdende Rolle. Eine Applikation dieser Art soll hierbei die Anwendung überall und optisch angemessen verfügbar machen. Bei älteren Anwendungen hat dies meist zur Folge, dass eine neue Web-Applikation entwickelt werden muss. Hierbei steht die Projektleitung meist vor der Entscheidung, ob eine mobile Applikation zum Beispiel mit einem Framework wie Ionic erstellt wird. Andererseits besteht aber auch die Möglichkeit, eine neue Anwendung nach dem Prinzip „Mobile First“ zu entwickeln. Damit kann auch gleich die aktuelle Webseite ersetzt werden.

In diesem Artikel liegt das Hauptaugenmerk auf Apps, welche mit einem Framework, wie zum Beispiel Ionic, entwickelt wurden. Damit arbeiten auch andere Frameworks (Angular) im Hintergrund, welche das Testen vereinfachen können. Bei Anwendungen mit entsprechend hoher Komplexität kommt es immer wieder vor, dass Fehler nicht während des Entwicklungs- und Testprozesses erkannt und in der produktiven Umgebung an den Endnutzer weitergegeben werden. Damit diese aber für Endnutzer verständlich sind, ist eine gewisse Vorverarbeitung des Fehlers empfehlenswert. Unter dem Punkt „Umgang mit Fehlern in produktiven Umgebungen“ erläutere ich die Art der Fehleraufbereitung genauer. Selbstverständlich sollte versucht werden, dass ein Fehler gar nicht erst entsteht, hierfür spielen Systemtests sowie End-to-End-Tests eine große Rolle.

Testen in der Softwareentwicklung

Das Thema “testen” ist ein wichtiger Teil der Softwareentwicklung, hierbei bildet die Entwicklung von Apps keine Ausnahme. Grob kann man automatisierte Tests in zwei Kategorien unterteilen:

  • Systemtests, welche aus Unittests bestehen. Damit sind Logikeinheiten und alle Serviceaufrufe testbar.
  • Die zweite Kategorie sind die End-to-End-Tests, welche unter anderem für Oberflächentests verantwortlich sind. Zusätzlich gibt es hierbei immer noch die Möglichkeit manuelle Tests mit Geräten zu verwirklichen.

Die Unittests ermöglichen auf granularer Ebene einzelne Serviceaufrufe sowie den Test der Logikelemente in einer App. Hierbei ist zu beachten, dass wenn ein Backend angebunden ist, dieser auch über Tests verfügt, damit in einem Fehlerfall die Fehlerquelle leichter ermittelt werden kann. Bei dieser Art von Test sollte für kleinere Logikeinheiten ein Test angelegt und alle vorhandenen sowie vorangegangenen Tests ausgeführt werden. Damit kann gewährleistet werden, dass die getesteten Logikeinheiten wie gewünscht funktionsfähig sind und es keine Interaktion mit anderen Einheiten gibt. Andere Fehlerfälle, wie keine oder eine langsame Internetverbindung, sollten ebenfalls getestet werden.

Mit den End-to-End-Tests steht den Entwicklern die Möglichkeit zur Verfügung, auch das Frontend zu testen. Vereinfacht wird das durch Tools wie Selenium, die ein vorprogrammiertes Klickverhalten erzeugen. Dabei versucht man, ein möglichst Endnutzer nahes Eingabemuster nachzustellen.  Bei der Erstellung solcher Muster sollte beachtet werden, dass die Entwicklersicht bezüglich der Prozesse systemorientiert ist. Daher ist es empfehlenswert für solche Tests einige Endnutzer sowie geschulte Tester einzubinden. Dadurch wird die Qualität von Tests erhöht und es wird eine größere Bandbreite an Interaktionsmöglichkeiten abgedeckt. Folglich ist dann natürlich auch die Aussagekraft der Tests höher. Zusätzlich ist es empfehlenswert, diese Tests für jedes neue Frontend-Element anzulegen und diese regelmäßig durchlaufen zu lassen, um sicherzustellen, dass sie noch wie gewünscht arbeiten. Denn bereits kleinere Änderungen, zum Beispiel in der HTML Struktur, können leicht zu Fehlern in den Tests führen, ohne, dass diese aufgrund eines Fehlverhaltens fehlschlagen. Wie ein solcher Test beispielsweise aussehen kann, ist in der folgenden Abbildung zu sehen.

Testen auf Fehler in der SoftwareentwicklungZusätzlich zu den automatisierten Tests, welche die Systemtests sowie die End-to-End-Tests beinhalten, wird meistens noch ein manueller Test durch einen Entwickler oder Tester durchgeführt. In diesem Fall ist das insofern wichtig, als dass dadurch Fehler, die zum Beispiel mit bestimmten Geräten zusammenhängen oder nur im Auslieferungspaket existieren, entdeckt werden können. Da diese Tests aber sehr viel Zeit in Anspruch nehmen, ist es nicht empfehlenswert bei jedem Minor-Release manuelle Tests durchzuführen. Meist werden Tests auch während des Entwicklungsprozesses ausgeführt. Mehr zu diesem Thema gibt es unter „Remotedebugging vor und nach dem Entwicklungsprozess“.

Remotedebugging vor und nach dem Entwicklungsprozess

Remotedebugging ist neben den automatisierten Tests eine wichtige Hilfe für Entwickler. Hierbei können die Entwickler oder Tester neu erstellte Logikeinheiten auf einem Gerät testen. Dabei erhalten sie dank des Debugging-Prozess weiterhin alle Logausgaben. Die Fehlersuche wird erleichtert und Fehler können im Vorfeld leichter behoben werden. Nach der Fertigstellung der Entwicklung ist es durch diese Art des Debuggings weiterhin möglich Fehler nachzustellen und dadurch zu lösen. Hierbei unterliegt man aber meist der Einschränkung, dass nicht ausnahmslos alle Geräte geprüft werden können. Wenn für einen bestimmten Fehler kein passendes Gerät vorhanden ist, kann es sich als schwer herausstellen einen gerätespezifischen Fehler nachzustellen. Um eine Lösung eines solchen Fehlers zu vereinfachen, ist der Umgang mit Fehler in produktiven Umgebungen essenziell.

Umgang mit Fehlern in produktiven Umgebungen

Trotz ausgiebiger und granularer Tests kann es in produktiven Umgebungen zu Fehlern kommen. Die Ursache kann eine Vielzahl von Faktoren haben, wie zum Beispiel:

  • eine schlechte Internetverbindung,
  • Fehlkonfigurationen,
  • falsche Bedienung,
  • Interaktionen mit anderen Apps oder
  • Probleme mit einem Antivirenprogramm.

Fehler lassen sich in zwei Kategorien unterteilen: Auf der einen Seite in technische Fehler, welche zum Beispiel den Zugriff auf das Backendsystem verhindern. Auf der anderen Seite fachliche Fehler. Diese können entstehen, wenn eine App beispielsweise eine Zuweisung von Daten zulässt, die das Backend nicht erlaubt. Konkret kann ein Szenario wie folgt aussehen: Ein Nutzer legt in einer Rechteverwaltung ein neues Recht an, welches nach dem Vier-Augen-Prinzip geprüft werden muss. Sollte es nun in der App möglich sein, dass die anlegende Person auch die genehmigende Person ist, würde das Backend den Fehler übermitteln. Aufgrund fehlender Fachlichkeit kann die Aktion nicht ausgeführt werden. Diese Fehler können für den Nutzer unterschiedlich dargestellt werden. Ein technischer Fehler kann mit einem Fehlercode versehen werden, der den Ursprung genauer darlegen kann. Ein fachlicher Fehler kann dem Nutzer hingegen direkt vermitteln, aus welchem Grund ein Fehler aufgetreten ist. Im folgenden Abschnitt wird auf beide Möglichkeiten genauer eingegangen.

Fehlermeldungen direkt dem Nutzer anzeigen

Der erste Berührungspunkt mit einem Fehler ist für den Endnutzer meistens die angezeigte Fehlermeldung. Fehler, die keine Meldung ausgeben, sollten generell vermieden werden, da diese eher zur Unzufriedenheit eines Nutzers beitragen. So kann es sich beispielsweise als schwer erweisen, wenn ein Nutzer nur die Meldung „Fehler 901“ erhält. Meist werden solche Fehler dann auch nur als Fehler gemeldet. Im Idealfall unterstützt die Fehlerbeschreibung den Endnutzer, so dass für ihn verständlich ist, weshalb der Fehler aufgetreten ist. Zusätzlich kann diese dem Nutzer eine mögliche Lösung anbieten.

Der Umgang mit technischen Fehlern stellt hierbei eine besondere Herausforderung dar. Diese sind meist für den Nutzer unverständlich. Fehler dieser Art können zum Beispiel durch Fehler in einem Backendsystem entstehen. Die mitgelieferte Fehlermeldung des Servers, wie „Internal Server Error“, ist hierbei für den Nutzer nicht nützlich bzw. nicht aussagekräftig. Um mit diesen Fehlern umzugehen empfiehlt es sich dem Nutzer eine Klartextmeldung zu übermitteln, dass ein technischer Fehler aufgetreten ist und dieser nach Möglichkeit einem Admin gemeldet werden soll. Damit dieser das Problem leichter analysieren kann, ist eine technische Fehlernummer sehr hilfreich. Anhand von festgelegten Antworten kann durch ein solches Vorgehen auch direkt eine Handlungsmaßnahme an den Nutzer zurückgegeben werden.

Im Gegensatz zum Umgang mit technischen Fehlern ist der Umgang mit fachlichen Fehlern einfacher. Aber um diese unterscheiden zu können, müssen die entsprechenden Fachlichkeiten in den Systemen abgedeckt sind. Wenn das der Fall ist, kann das entsprechende System dem Endnutzer auch eine aussagekräftige Mitteilung liefern. Diese sollte eine konkrete Handlungsanweisung und entsprechende Begründung beinhalten, weshalb eine Aktion nicht durchgeführt werden konnte. Da die Fachlichkeiten aber bereits validiert sein sollten, sollten solche Fehler auch nur in den wenigstens Fällen auftauchen. Meist entstehen Fehler solcher Art wegen fehlenden Abfragen oder eines nicht Erfolgen von Abschaltmechanismen. Das kann zum Beispiel der Fall sein, wenn ein Eingabefeld nicht deaktiviert wird. Fehler dieser Art sind meistens eine Unannehmlichkeit für die Nutzer, haben aber nicht zwangsläufig eine einschneidende Auswirkung auf den produktiven Betrieb.

Fehlermeldung an das Backendsystem schicken

Eine sehr praktische Möglichkeit Fehler zu melden und zu tracken ist diese an das entsprechende Backend zu schicken. Diese Methode bietet sich sehr für technische Fehler an, da diese meist nicht nur anhand der Fehlermeldung identifiziert werden können. Damit dieser identifiziert werden kann, ist es empfehlenswert so viele Informationen wie möglich an das Backend zu übermitteln. Natürlich muss man hierbei den Datenschutz und das Thema Sicherheit beachten. Deshalb sollte es vermieden werden Nutzerinformationen wie zum Beispiel den Loginnamen an das Backend als Klartext zu übermitteln. Je nach Fehlermeldung kann es auch sinnvoll sein die mitgelieferte Meldung und den Stacktrace zu verschlüsseln. Auch die Ausgabe im Backendlog muss entsprechend für solche Fehlermeldungen gestaltet werden. Werden diese Meldungen, die von einer App kommen, mit allen anderen Informationen geloggt, kann es je nach Verhalten des Logging dazu führen, dass Informationen verloren gehen, wenn alte Serverlogs gelöscht werden. Empfehlenswert ist ein separates Log für mobile Fehlermeldungen. So können diese an einem zentraleren Ort aufbewahrt und eingesehen werden. Zu beachten ist hierbei, dass nicht jeder Fehler ans Backend geschickt werden kann. Fehler, die aufgrund einer nicht vorhandenen Verbindung zum Server entstehen, können auf diese Art nicht verarbeitet werden. Für diese Art von Problem empfiehlt es sich eine Fehlermeldung als E-Mail aufzubereiten.

Fehlermeldung als E-Mail aufbereiten

Für das Senden von Fehlern per E-Mail gelten auf den ersten Blick erst einmal ähnliche Regeln wie für Fehler, die in das Backendsystem geschickt werden. Vorweg ist es allerdings wichtig festzulegen auf welche Art die E-Mail versendet werden soll. Hier kann zwischen einem direkten Versand ohne den Nutzer miteinzubinden oder einer automatisierten, vorgefertigten E-Mail unterschieden werden. Der Weg über die vorgefertigte E-Mail ist hierbei aus verschiedenen Gründen zu bevorzugen. Nicht zuletzt aus dem Grund, dass ein Endnutzer vor dem Versand die automatisch generierten Informationen ergänzen kann. Der größte Vorteil liegt hier am Informationsgehalt der E-Mail, welcher in diesem Fall auch vom Nutzer abhängig ist. Hierbei kann schon ein kleiner Text hilfreich sein, der dem Versender mitteilt, dass er gerne weitere Informationen ergänzen kann. Diese Art der Fehlerübermittlung bietet auch Vorteile für die Lösung von Problemen und bietet sich vor allem bei Fehlern an, bei denen das Backendsystem nicht erreichbar ist. Beispielsweise sind Login Fehler, die nur auf bestimmten Geräten auftauchen, schwer nachvollziehbar und nicht auf dem Backendlog einsehbar, wenn es sich um einen Verbindungsfehler handelt. Des Weiteren eignet sich diese Art der Fehlerverarbeitung hervorragend, um Fehler zu übermitteln, die in der App nur durch eine bestimmte Bedingung entstehen.

Zusammenfassend kann man sagen, dass dies die flexibelste Variante der Fehleraufbereitung darstellt, da diese auch vom Nutzer leicht individualisiert werden kann. Dennoch sollte man weitestgehend hierauf verzichten, da ein Endnutzer, der zum Beispiel bei jeder Fehlermeldung die Möglichkeit aufgezeigt bekommt doch bitte alle Daten und zusätzliche Informationen anzugeben, im schlimmsten Fall die App komplett ablehnt und nicht mehr nutzt. In der folgenden Abbildung ist dargestellt, wie man dem Endnutzer den Versand der E-Mail anbieten kann.

myoperations Frontend FehleranzeigeFazit

Zusammenfassend sollte man festhalten, dass es natürlich am besten ist, wenn Fehler nicht entstehen. Da dies aber aufgrund von Komplexität oder aus zeitlichen Gründen nicht immer möglich ist, sollte man Fehler gut aufbereiten. Fachliche Fehler sind hierbei sicher das einfachste Beispiel, da diese gut aufzubereiten sind und man eine verständliche Meldung an den Endnutzer weitergeben kann. Aber auch technische Fehler müssen behandelt werden und nachvollziehbar sein. Dies ist nur möglich, wenn ein solches Problem für die Entwicklung einsehbar ist. Hierfür bietet sich am besten das Protokoll des Backendsystems an, da hier bereits andere Fehler beschrieben werden. In Ausnahmefällen ist es auch sinnvoll, eine automatisierte E-Mail zu verfassen, die der Betroffene um weitere Informationen anreichern kann. Da dies aber auch Einschnitte in den Workflow der App bedeutet, sollte diese Möglichkeit nur sehr selten verwendet werden. Nur wenn es keine weitere Möglichkeit gibt, einen Fehler nachzustellen oder die benötigten Informationen zu erhalten, sollte zu diesem Mittel gegriffen werden. Der wichtigste Punkt im Umgang mit Fehlermeldungen ist, dass der Endnutzer für ihn sinnvolle Informationen erhält, es aber auch für Entwickler und Tester möglich ist, diese nachzustellen. Das funktioniert am besten mit einer Kombination von angezeigten Fehlermeldungen sowie einem Backendlogging.

Diesen Beitrag kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.