Ihre Website oder mobile Anwendung erstickt unter Bugs und Sie wissen nicht, was Sie tun sollen? In diesem Artikel erklären wir Ihnen die verschiedenen Ursachen, die zu Anomalien führen, und welche Techniken Sie einsetzen können, um sie möglichst zu verhindern.
Es war einmal ein Bug, und dann noch einer, und es geht immer weiter und weiter, das ist erst der Anfang, okay, okay. Keine Woche vergeht, ohne dass Sie einen neuen Fehler auf Ihrer Website oder in Ihrer mobilen Anwendung entdecken. Und ganz ehrlich, Sie sind nicht weit davon entfernt, sich die Haare zu raufen. Sie wissen nicht mehr, wie Sie damit umgehen sollen. Lassen Sie es sich gesagt sein: Eine Website oder eine mobile Anwendung ohne Anomalien gibt es nicht. Es ist ein Mythos. Oder zumindest eine Seltenheit. Und obwohl es utopisch ist, Fehler auf Web- und Mobilplattformen vollständig auszurotten, gibt es derzeit neue Techniken, um die Anzahl der Fehler zu minimieren. Doch lassen Sie uns zunächst einmal verstehen, woher sie in erster Linie kommen.
Was sind die Ursachen von Bugs?
Eine nicht funktionierende Schaltfläche, eine schlechte Darstellung, ein 404-Fehler, ein Verbindungsproblem: Anomalien auf Websites oder in mobilen Anwendungen können aus einer Vielzahl von Gründen entstehen. Angefangen beim menschlichen Faktor. Denn in dem Moment, in dem Web- oder Mobilplattformen von Menschen entwickelt werden, können Fehler passieren. Aber hier sind einige häufige Ursachen, die zu Fehlern führen können:
>> Die Regressionen :
Regressionen treten immer dann auf, wenn eine Änderung des Codes Auswirkungen auf den bestehenden Code hat. Wenn z. B. eine neue Funktion implementiert wird und diese das Verhalten von zuvor vorhandenen Funktionen stört, liegt ein Rückschritt vor, da ein Fehler eingeführt wurde.
Aber was sind die Gründe für eine Regression? Es kann daran liegen, dass der Code schlecht architektonisch aufgebaut ist, dass es eine schlechte Fehlerbehandlung gibt, ein schlechtes Versionsverwaltungssystem, ein schlechtes Korrekturlesen vor dem Mergen, schlechte (oder gar keine) Entwicklungspraktiken oder dass Teams zu unabhängig arbeiten, so dass die Module, an denen sie arbeiten, sich gegenseitig beeinflussen können.
>> Ein Mangel an Tests :
Ist Testen gleichbedeutend mit Zweifeln? Manche würden Ihnen sagen, dass dies der Fall ist, aber das wäre sehr anmaßend. Denn wenn die Software oder Anwendung nicht von Beginn des Entwicklungszyklus bis zur Produktionsfreigabe (und auch danach) gründlich getestet wurde, dann besteht eine sehr, sehr, sehr (es gibt nie zu viele sehr) hohe Wahrscheinlichkeit, dass Fehler in der Produktion auftauchen. Und müssen wir wirklich noch einmal daran erinnern, welche Auswirkungen ein Fehler auf einen Endbenutzer haben kann?
Achtung: Testen ist gut (sogar sehr, sehr, sehr gut), aber man muss auch gut testen. Und dazu gehört, dass man die richtigen Tests auswählt und sie auch am richtigen Ort durch führt. Dies ist übrigens eines der wichtigsten Prinzipien des Testens: Tests zeigen, dass Fehler vorhanden sind, aber sie zeigen nicht, dass es keine gibt. Deshalb ist es wichtig, gut und am richtigen Ort zu testen, um die kritischsten Fehler zu finden, und das auf effiziente Weise. Der Test ist der unverzichtbare Messindikator für die Anwendungsqualität.
>> Ein Mangel an Kommunikation :
Ist mangelnde Kommunikation die Ursache allen Übels in der Welt? Das ist gut möglich und eines ist sicher: Es verursacht viele Fehler. Denn wie wir alle wissen, führt mangelnde Kommunikation zwischen Teams zu Missverständnissen, Vermutungen, aber auch zu Missverständnissen. Und im Rahmen der Web- oder Mobilentwicklung spielt sich die ganze Herausforderung der Kommunikation bereits in der Spezifikationsphase ab .
Spezifikationen dienen dazu, die Vision der Personen zu beschreiben, die sie erstellen. Zum Beispiel hat das Business einen Bedarf und der Product Owner wird die Spezifikationen verfassen. Dann entwickeln die Entwickler die Spezifikationen und die Tester testen die Entwicklungen der Spezifikationen. Und wenn es Lücken in der Kommunikation zwischen diesen verschiedenen Personen gibt, wenn nicht alle effektiv miteinander kommunizieren, um das Produkt zu entwickeln, und wenn jede Schicht abgeschottet ist, entsteht ein Tunneleffekt, der bis zu kritischen Anomalien führen kann, und der Endbenutzer bekommt die Zeche.
Aber wie kann man diese Bugs dann verhindern?
In einem früheren Artikel haben wir bereits einige Tipps zur Vermeidung und Begrenzung von Bugs besprochen, wobei wir vor allem voll auf Qualität setzen.
>> TDD (Test Driven Development) :
Test-Driven Development, auf Deutsch testgetriebene Entwicklung, ist eine Entwicklungsmethode, bei der die Tests geschrieben werden, bevor der Code geschrieben wird. Aber was heißt das? Im Grunde schreibt man zuerst einen Test, führt ihn aus und bestätigt dann, dass der Test fehlgeschlagen ist, da die Funktionalität noch nicht implementiert wurde. Dann entwickelt man die Funktionalität und führt den Test erneut durch, bis er erfolgreich ist, etc.
Warum funktioniert diese Methode gegen Bugs? Weil, wenn Tests bereits vor der Entwicklung einer Funktion oder eines Produkts erstellt werden, die Wahrscheinlichkeit, dass diese Funktion oder dieses Produkt ihre Endbenutzer erreicht, ohne getestet worden zu sein, erheblich verringert wird. Mehr noch: Regelmäßiges Testen führt dazu, dass Fehler früher erkannt und somit vor der Produktion behoben werden können.
Beachten Sie jedoch, dass TDD immer noch sehr stark auf Unit-Tests ausgerichtet ist und eine vorgelagerte Arbeit zur Definition von Tests erfordert, was in einem dringenden Projekt manchmal kompliziert umzusetzen ist.
>> BDD (Behavior-Driven Development) :
Behavior-Driven Development ist eine andere Methode als TDD und fördert die Kommunikation und Zusammenarbeit zwischen allen Projektbeteiligten (Entwicklern, Qualitätsingenieuren, Vertriebsmitarbeitern, Testern usw.). Dadurch wird sichergestellt, dass das gesamte Team ein gemeinsames Verständnis davon hat, wie sich die Anwendung verhalten soll. Und das äußert sich vor allem in Tests, die in einer für alle verständlichen Sprache geschrieben werden, bevor die Entwicklung der Funktion oder des Produkts beginnt. Mithilfe dieser BDD-Methode können Fehler schon früh in der Entwicklung festgestellt und somit verhindert werden.
>> Continuous integration / Continuous testing :
Beginnen wir am Anfang. Der CI-Ansatz, aka Continuous integration, also kontinuierliche Integration, ist eine Methode, bei der neuer, von Entwicklern geschriebener Code während des gesamten Entwicklungszyklus so früh und so häufig wie möglich (mindestens einmal pro Tag) in den Quellcode einer Anwendung integriert wird. Bei jeder Änderung des Quellcodes werden automatisierte Tests durchgeführt (daher Continuous Testing), um zu überprüfen, dass dadurch keine Regressionen erzeugt wurden und dass die neuen Funktionen korrekt implementiert wurden.
Dies gewährleistet eine kontinuierliche Überwachung, während des gesamten Lebenszyklus der Anwendungen und stellt insbesondere sicher, dass alle Regressionen sofort nach ihrer Einführung erkannt werden. Das spart viel Zeit und Mühe, die sonst z. B. für die Suche nach den Änderungen aufgewendet werden müssten, die die Regression ausgelöst haben.
Dies erfordert hingegen eine sehr hohe Investition in die Automatisierung aller Arten von Tests (Unit-Tests, Integrationstests, Systemtests, End-to-End-Tests...).
>> Achtung: Diese Entwicklungstechniken funktionieren nicht unbedingt für jeden. Es hängt von Ihrer Struktur, der Dynamik Ihres Teams, dem Projektkontext, Ihrer Teststrategie usw. ab. Mit all diesen Präventionstechniken sind Sie dennoch nicht davor gefeit, einen Fehler zu übersehen (Null Fehler gibt es nicht), aber Sie sollten die kritischsten Fehler, die die größten Auswirkungen haben, nicht übersehen.
Schlussfolgerung
Kurz gesagt: Um besser mit Fehlern umgehen zu können, muss man sie vor allem auf spüren können, und das erfordert einfach die Einführung von testbasierten Ansätzen. Wie bereits erwähnt, reicht es jedoch nicht aus zu testen, man muss auch gut testen, und das geht nur mit einer lebendigen Dokumentation durch Tests, insbesondere durch automatisierte Tests. Aber das wird Gegenstand eines späteren Artikels sein ;)
