Bug-Fixing für Mobile Apps richtig planen

Jedes Softwareprodukt, sei es eine Web-, Mobil- oder Desktop-Anwendung, steht beim Nutzer erstmal unter Verdacht Bugs oder Issues aufzuweisen. In der Tat Software ist nie ganz fehlerfrei. Dennoch tun App-Developer und App-Anbieter gut daran möglichst alle Issues & Bugs gründlich auszumerzen, um eine einwandfreie Digital Experience anzubieten. Je nach Softwareprodukt ist die Behebung von Bugs in Production allerdings nicht einfach und in den meisten Fällen teuer.

Vor der Veröffentlichung einer App

Bevor ein App-Entwicklungsteam eine native mobile Anwendung in den App Store bringt, muss diese intensiv getestet werden, um den Bedarf an Hotfixes auf ein Minimum zu reduzieren. Ein weiterer Ansatz ist die Prüfung der App durch Beta-Tester oder externe Testanbieter, um frühzeitig Feedback zu erhalten. Doch wie wir alle wissen, lauern die wirklich gemeinen Bugs in der freien Wildbahn auf den echten Smartphones der Kunden und meist in Szenarien, die nur in der realen Nutzerwelt existieren.

Die „Mobile Bug Matrix“

Wie entscheidet man, bei welchen App-Bug sich ein Hotfix lohnt? In den letzten Jahren bin ich vielen Teams begegnet, die sich genau diese Frage gestellt haben. Einige Teams versuchten, jeden Bug in Production zu beheben und waren am Ende nur noch mit Bug-Fixing für die veröffentlichte App beschäftigt, während die Entwicklung neuer Features ausblieb. Es gilt daher, richtig abzuwägen, ob ein Hotfix notwendig ist oder ob mit der Fehlerbehebung noch bis zum nächsten Release gewartet werden kann.

Um Teams diese Entscheidung zu erleichtern, habe ich die „Mobile Bug Matrix“ entwickelt. Die Matrix hat zwei Achsen. Die x-Achse repräsentiert die Kritikalität/das Ausmaß für den Benutzer und die y-Achse die Kritikalität/das Ausmaß aus Sicht des Unternehmens.

Daraus ergeben sich drei mögliche Szenarien. Im Folgenden habe ich für jedes Szenario ein Fehlerbeispiel aufgeführt:

1. Hotfix: In diesem Bereich sind die Auswirkungen für das Unternehmen und den Benutzer am größten. Tritt ein solcher Fehler in der Live-App auf, sollte er schnellstmöglich behoben werden.
   Fehlerbeispiel: Der Login der App funktioniert nicht mehr.
2. Next Release: Bugs dieser Kategorie haben entweder für das Unternehmen oder für den Benutzer größere Auswirkungen. Der Fehler ist nicht so gravierend, dass direkt ein Hotfix durchgeführt werden muss. Er sollte aber mit dem nächsten Release behoben werden.
   Fehlerbeispiel: UI-Elemente der App befinden sich an der falschen Stelle.
3. Upcoming Sprints: Diese Probleme müssen behoben werden, aber es besteht weder von Seiten des Unternehmens noch von Seiten des Benutzers große Eile. Fehler dieser Kategorie können dem Backlog hinzugefügt und in künftigen Sprints gelöst werden.
   Fehlerbeispiel: Falsche Übersetzungen oder Tippfehler.

Zu klärende Fragen

Im Gespräch mit den verschiedenen Stakeholdern der App wird es unterschiedliche Meinungen dazu geben, wie kritisch der gefundene Bug ist und in welche Kategorie er passt. Um mühsame Diskussionen zu vermeiden und leichter entscheiden zu können, ob ein Hotfix notwendig ist, hilft es, sich die folgenden Fragen zu stellen:

1. Wie viele Benutzer sind von dem Fehler betroffen?
2. Sinkt unsere App-Aktivität?
3. Sinkt das Vertrauen in das Unternehmen?
4. Bringt dieser Bug rechtliche Probleme mit sich?
5. Verlieren wir Geld aufgrund des Bugs?
6. Ist das Problem auf den unterstützten Geräten und Betriebssystem-Versionen reproduzierbar?
7. Welcher Bereich der App ist betroffen?
8. Können wir die Funktion vom Backend aus deaktivieren?

Wenn ein Team entschieden hat, ob es lohnt, einen Hotfix durchzuführen, ist der bestehende Software-Entwicklungsansatz anzuwenden:

1. die Fehlerursache finden
2. den Fehler beheben
3. und zur Absicherung einige automatisierte Tests durchführen.

Ist die Entwicklung abgeschlossen, muss ein Software- oder Beta-Tester überprüfen, ob der Fehler erfolgreich behoben wurde. Darüber hinaus müssen Regressionstests durchgeführt werden, um sicherzustellen, dass der Bugfix keine zusätzlichen Probleme verursacht hat. Zu guter Letzt muss die gesamte Testautomatisierungs-Suite ausgeführt werden. Die Ergebnisse sollten grün sein.

Einen Workflow für das Team finden

Die Mobile Bug Matrix kann also dabei helfen zu entscheiden, ob eine sofortige Fehlerbehebung notwendig ist. Jedes Team sollte einen Workflow definieren, um in solchen Situationen entscheiden zu können, wie mit kritischen oder unkritischen Bugs im Produktionssystem umgegangen wird. Es muss stets sorgfältig abgewogen werden, ob ein Hotfix durchgeführt oder bis zum nächsten Release gewartet wird, denn in der Regel lassen sich App-Bugs weder schnell noch kostengünstig beheben. Zu den Entwicklungs- und Testkosten gesellt sich die Wartezeit für die Prüfung und Aufnahme in den App Store. Erst dann kann der Fix für die Kunden live gehen. Das nächste geplante App-Release hingegen ist vielleicht schon in Sichtweite.