Menü
Zurück zur Blog-Übersichtsseite
Foto von einem Softwwareentwickler am Laptop

Fehler richtig und nachhaltig beheben


Hans-Joachim Daniels

3 Minuten

Kennst du es auch? Eine wichtige Funktion im Produktivsystem mag nicht so wie du willst, die Anwender:innen beschweren sich. "Ist ja klar!" denkt sich Entwickler:innen dann häufig, wenn sie die ersten Zeilen im Fehlerticket lesen. Schnell die betroffenen Zeilen geändert, die vorhandenen Tests laufen gelassen und freigeschaltet - "Das war ja einfach ...".

Denkste, immer noch Beschwerden. Nochwas geändert. Wieder keine Besserung. Nach der dritten Änderung ist das Problem immer noch da, aber es hat sich verändert. Das sorgt natürlich nicht für Zufriedenheit bei den Kund:innen.

Tipps, wie es in Zukunft besser geht, haben wir hier für dich zusammengefasst.

Erfassen 📝

  • Bugs sollten einfach bis automatisch gemeldet werden können

    • Top-Abschreckung: Sich extra in einem HelpDesk-System anmelden zu müssen

    • Nötigen Kontext automatisch sammeln

      • aufgelaufene Ausnahmen, Browser+Version, aktuelle Seite, …
    • Hilfestellung, welche Angaben vom Benutzer benötigt werden

  • In Anwendung integrierte Melden-Funktion

    • vorausgefüllter mailto:-Link

    • API-Aufruf an Ticket-System

  • Je besser die Angaben hier, desto weniger Vermutung ist auf Seite der Entwickler:innen nötig und desto schneller ist das Problem verstanden

2. Auswirkungen bewerten 🤔

  • Kosten/Schaden

    • für Betreiber:innen
    • für Kund:innen
  • Sicherheitsrelevant?

  • Anzahl betroffener Anwender:innen

  • Entscheidung, ob sofort (Systemausfall), gleich oder irgendwann zu beheben

    • fehlende Features können in der Tat wichtiger sein als Unschönheiten vorhandener Features

3. Orten 🧭

  • In welchem System wird der Fehler sichtbar?

  • Welches System verursacht den Fehler (und leidet nicht nur unter Falscheingaben)?

4. Nachstellen 🏚

  • Nicht alleine aufgrund einer Vermutung loslaufen!

  • Erst bei "doesn't work on my machine" (oder einer sonstigen kontrollierten Umgebung) weitermachen

  • Auf den Kern zum Nachstellen des Fehles reduzieren

    • Eingabewerte/ -Dokumente

    • Vorzustand, in dem der Fehler auftritt

    • Nur die Funktionen einbeziehen, die den Fehler verursachen

5. Testfall schreiben (rot) 🚨

  • Dieser Fehler hat es ja schon einmal geschafft, durch die bisherigen Tests durchzurutschen

  • Im aktuellen Release behobene, aber später wieder hochkommende Fehler nerven besonders, sollten nicht wieder auftauchen

  • Zu Beginn muss der Testfall fehlschlagen, der Fehler muss verlässlich auch im Testfall nachgestellt werden

  • Ausnahme: Wenn die Fehlerursache in Design oder Architektur der Software steckt, benötigte Daten fehlen oder aus sonstigem Grund größere Umbauten nötig sind. Dann zurück ans Reißbrett und nachdenken, Testfälle, bei denen der Aufruf wie gewünscht gar nicht geht, bekommt man nicht so leicht grün.

6. Fehlerbehebung 🛠

  • Die eigentliche Arbeit ...

  • Im Falle von Falscheingaben: diese besser abfangen

    • Löst nicht das Problem der aufgetretenen Falscheingabe, aber beugt Folgeschäden vor

    • Quellsystem des Fehlers suchen und auch dort beheben

  • Im Falle von Fehlern aufgerufener Systeme: diese besser abfangen

    • Grundsätzlich und überall sinnvoll!
  • Zweite Meinung einholen, verschlimmbessern ist peinlich

7. Testfall wird grün ✅

  • Die Belohnung fürs Schreiben des Tests 🎁

  • Die Sicherheit und das Gefühl, dass der Fehler wirklich behoben ist

  • Der gleiche Fehler wird nicht noch einmal “ins System kommen”, da mit diesem Testfall für die Zukunft abgedeckt

8. Ausliefern 🚀

  • Im Falle von Continuous Delivery ohne Verzug auf Produktion für zufriedene Benutzer:innen

  • Ansonsten zur Abnahme bereitstellen/integrieren 📦

9. Lernen 🧠

  • War dieser Fehler nur Symptom eines grundlegenden Problems?

    • Falsch verstandene Anforderung?

    • Technische Unterschiede, die immer wieder Reibung verursachen?

    • Wurde Code kopiert, anstatt ihn auszulagern?

  • Auch sonst: Könnte dieser Fehler anderswo ebenfalls vorhanden sein?

  • Ausprägung einer häufigeren Fehlerklasse, für die Bewusstsein geschaffen werden muss?

  • Schöner, aber seltener: Lässt sich diese Art Fehler auch anderswo automatisch abfangen?`

Montag, 25.07.2022

Diesen Artikel teilen über:




enpit GmbH & Co. KG

Marienplatz 11a
33098 Paderborn
+49 5251 2027791
Zum enpit-Newsletter anmelden
© 2024 – enpit GmbH & Co. KGDatenschutzerklärung | Impressum