Einleitung
Warum ist es eigentlich so schwer, Tests für Software zu schreiben? Mir ist es früher immer schwergefallen, weil ich nicht wusste, wie ich meine Tests schreiben soll und was genau ich überhaupt testen soll. Inzwischen bin ich zu dem Schluss gekommen, dass Tests schreiben eigentlich ziemlich einfach ist. Es geht vor allem darum zu verstehen, was man testen sollte – und um ein bisschen Übung. Die Kurzfassung dieses Artikels: Teste einfach die Interaktionen, die deine Nutzer mit deiner Software haben. Lies weiter, um mehr zu erfahren.
Warum überhaupt Tests?
Eine berechtigte Frage. Warum sollten wir zusätzlichen Code schreiben, nur um sicherzustellen, dass anderer Code funktioniert? Erhöht das nicht die Menge an Code, die wir pflegen müssen? Jetzt haben wir unseren Anwendungscode PLUS eine Menge Testcode. Das kann sich widersinnig anfühlen.
Wenn wir aber lernen, was wir testen sollten, merken wir schnell, dass der Testcode ziemlich kurz und auf den Punkt ist.
Wofür sind Tests gut?
Wenn ich einen Test schreibe, denke ich über die Anwendungsfälle nach, die mein Code abdecken muss, und darüber, unter welchen Umständen er funktionieren soll – und wann nicht. Ein Test ist also eigentlich eine Spezifikation dessen, was unser Code tun muss. Im Idealfall müsste sich ein Entwickler darüber gar keine Gedanken machen, aber meiner Erfahrung nach ist das in der Praxis selten so. Die meisten Stakeholder haben schlicht nicht das technische Verständnis, um alle Randfälle zu bedenken, die in einem Stück Software auftreten können. Also wird das unsere Aufgabe als Entwickler – ebenso wie, es den Stakeholdern zu vermitteln.
Sobald wir die Anwendungsfälle für unseren Code festgelegt haben, können wir sie ziemlich einfach in Code übersetzen. Das hat den großen Vorteil, dass wir über die Anwendungsfälle nachdenken, bevor wir überhaupt Code schreiben. Ein noch größerer Vorteil: Weil diese Spezifikation direkt in der Codebasis neben unserem Code liegt, haben auch Entwickler, die später ins Team kommen, noch eine Referenz dafür, wofür der Code gedacht ist. Das gibt neuen Teammitgliedern deutlich mehr Sicherheit, wenn sie Code in Produktion bringen. Die Spezifikation neben dem Code, den sie beschreibt, ist genau der richtige Ort – denn dort wird jeder neue Entwickler nachsehen (und sollte es auch), wenn er verstehen will, warum eine Software so funktioniert, wie sie funktioniert.
Wie lerne ich, Tests zu schreiben?
Wie bei jeder neuen Fähigkeit ist es am Anfang schwer, bis man den Dreh raushat und einige der typischen Probleme selbst erlebt hat. Die Lernkurve kann steil sein, mit einigen Höhen und Tiefen. Aber am Ende, das verspreche ich dir, bist du ein besserer Entwickler. Wenn du persönliche Tipps zu deinen konkreten Fragen möchtest, buch gern ein Einzelcoaching bei mir. Du erreichst mich über das Kontaktformular.
Die wichtigste Frage ist aus meiner Sicht: Was sollte ich testen? Dazu gibt es viele Quellen, aber im Kern lautet die Frage: Was erwarten meine Nutzer von meiner Anwendung oder Software? Nutzer kann dabei jeder sein, der deine Software verwendet – auch andere Software, die deine Software nutzt (APIs), zählt als Nutzer. Denn letztlich schreiben wir den Code für sie. Also sollten wir unsere Tests so schreiben, wie unsere Nutzer den Code später tatsächlich verwenden.
Was sollte ich testen?
Ein Beispiel: Nehmen wir eine Einkaufslisten-App. Was sind die wichtigsten Anwendungsfälle für ihre Nutzer? Aus meiner Sicht möchte ich eine Liste von Artikeln führen, die meine Einkaufsliste bilden. Idealerweise kann auch meine Partnerin oder mein Partner Artikel auf derselben Liste hinzufügen oder abhaken. Wenn das der Kern unserer Software ist, müssen wir Folgendes testen:
- Es gibt mindestens 2 Nutzer, die Artikel zu einer Checkliste hinzufügen und abhaken können. Man soll auch Artikel abhaken können, die ein anderer Nutzer mit Zugriff hinzugefügt hat.
Unsere Tests lassen sich so formulieren:
- Nachdem Nutzer A Artikel zu einer Checkliste hinzugefügt hat,
- soll Nutzer B die hinzugefügten Artikel auf seiner Checkliste sehen.
- Nachdem Nutzer B einen oder mehrere Artikel abgehakt hat,
- soll Nutzer A die abgehakten Artikel nicht mehr auf seiner Checkliste sehen.
Dieser einfache Test prüft genau die Kernfunktion, für die unsere Software gebaut wurde.
Es gibt ein paar Randfälle, die man testen könnte, aber nicht unbedingt muss. Ein Beispiel ist die Offline-Nutzung: Was passiert, wenn Nutzer A offline ist und Äpfel auf die Einkaufsliste setzt – und Nutzer B gleichzeitig ebenfalls Äpfel hinzufügt, während A noch offline ist? Ich würde sagen, das ist ein Randfall, der für die Kernfunktion der App nicht entscheidend ist.
Das muss man für jeden Anwendungs- und Randfall einzeln abwägen. Meine Faustregel lautet: Wie wahrscheinlich ist es, dass deine Nutzer die App nicht mehr verwenden, wenn diese Funktion nicht funktioniert? Ist die Wahrscheinlichkeit hoch, ist das vermutlich ein guter Kandidat für einen Test.
Nutzt nur ein kleiner Teil der Nutzer diese Funktion überhaupt, lässt du sie wahrscheinlich besser weg. Das ist das einfache Pareto-Prinzip: Teste die Kernfunktionen, die 80 % deiner Software ausmachen – das sollte nur etwa 20 % der Zeit kosten, um die Tests zu schreiben und zu pflegen.
Klingt kompliziert? Du willst keine Zeit investieren, um gute, wertorientierte Tests zu lernen? Hol mich in dein Team oder buch ein Einzelcoaching, damit du den nächsten Schritt machst.
Fazit
Gute Softwaretests zu schreiben und zu pflegen trägt entscheidend dazu bei, hochwertige Software auszuliefern. Am Anfang wirkt das Schreiben von Tests oft abschreckend und widersinnig, weil mehr Code gepflegt werden muss. Wenn wir uns aber darauf konzentrieren, was die Nutzer von der Software erwarten, können wir die Tests so gestalten, dass sie wirklich die Kernfunktionen absichern. Je vertrauter uns diese Denkweise wird, desto weniger fühlt sich Testen wie eine lästige Pflicht an – und desto selbstverständlicher wird es Teil der Softwareentwicklung.
Nicht jede Funktion muss getestet werden. Wir sollten uns vor allem auf die Kernfunktionen konzentrieren, die die meisten Nutzer verwenden. So folgen wir dem Pareto-Prinzip und schreiben Tests für die wichtigsten Funktionen, ohne dafür viel Zeit aufzuwenden.
Und denk daran: Unsicherheit sollte dich nicht aufhalten. Hol dir ruhig professionelle Unterstützung, wenn du noch Zweifel hast, wie du gute Tests schreibst. Ein Einzelcoaching oder zusätzliche Unterstützung im Team kann genau das fehlende Puzzleteil sein.
Kontakt
Ich freue mich über dein Feedback und über deine Fragen oder Anmerkungen. Schreib mir gern an website[@]meerkat-software-solutions.com. Ich freue mich darauf, dich auf deinem Weg zu besseren Softwaretests zu unterstützen.
