Software-Testing ist die Disziplin, gezielt zu prüfen, ob Software so funktioniert, wie sie soll, und dabei Fehler zu finden. Gute Tests setzen eine klare Auftragsklärung voraus: Was wird getestet, und was soll dabei herauskommen? Fehler sind kein Makel, sondern Lernquelle, aus der sowohl Produktqualität als auch Entwicklungsprozesse wachsen.
Das Wichtigste in Kürze
- Auftragsklärung ist die Grundvoraussetzung für sinnvolles Testen: Wer nicht klärt, was getestet werden soll und welches Ergebnis erwartet wird, löst am Ende ein anderes Problem als das ursprüngliche.
- Fehler, die spät im Projekt auffallen, kosten deutlich mehr, weil dann Entwicklung, Konzeption und Tests neu aufgerollt werden müssen.
- Ein zentraler Skill von Testern ist Relevanzerkennung: das schnelle Erfassen, was in einem unbekannten System wichtig ist und worauf der Fokus gelegt werden muss.
- Aus Fehlern zu lernen bedeutet zweierlei: Produktfehler verbessern die Software direkt, Prozessfehler zeigen, wo der Ablauf selbst hakt, und beide Arten werden zu selten systematisch nachbetrachtet.
Softwaretesten ist für Aussenstehende ein blinder Fleck
Viele Menschen wissen nicht, dass es Softwaretesten überhaupt gibt. Sie stellen sich vor, Software werde entwickelt, dann sei sie da und laufe einfach. Dass dazwischen Teams und Spezialisten sitzen, die prüfen, ob die Software wirklich funktioniert, fällt aus diesem Bild komplett heraus.
Wer mit der IT nichts zu tun hat, denkt bei Software meist an Programmierer oder Entwickler, oft begleitet vom Klischee des Nerds. Das Testen taucht in dieser Vorstellung gar nicht auf. Es ist ein Expertentum, das im Hintergrund arbeitet und unsichtbar bleibt.
Dabei steckt darin echte Expertise. Es geht nicht nur darum zu prüfen, ob etwas läuft, sondern auch darum, Fehler zu finden, die richtigen Fragen zu stellen und die passenden Tests zu schreiben. Diese Arbeit ist anspruchsvoll, auch wenn sie von aussen kaum wahrgenommen wird.
Warum die Auftragsklärung über den Erfolg entscheidet
Bevor getestet wird, muss klar sein, was getestet werden soll. Genau dieser Schritt wird in der Softwareentwicklung häufig übersprungen. Es wird geprüft, Anforderungen werden abgehakt, aber das Warum bleibt diffus.
Im Coaching gibt es dafür ein eingespieltes Vorgehen. Ein Klient kommt mit einem Anliegen, erzählt seine Geschichte, und dann folgt ein grosser Abschnitt, der Auftragsklärung heisst. Dort wird festgelegt, was überhaupt das Problem ist, wohin der Weg führen soll und woran sich Erfolg messen lässt. Dieselbe Logik trägt beim Testen: Was wollen wir nachweisen, und was soll am Ende dabei herauskommen?
Fehlt diese Klärung, wird einfach drauflos getestet. Probleme tauchen dann spät auf, oft erst gegen Ende eines Projekts. Genau dann wird es teuer, denn Dinge müssen neu entwickelt oder neu konzipiert werden.
Diese ganze Qualitätsprüfung hat ja das Ziel, irgendwelche Dinge nachzuweisen, und die müssen schon früh klar sein.
Richard Seidl
Der Landkartenwechsel: wenn am Ende das falsche Problem gelöst wird
Ein Landkartenwechsel beschreibt im Coaching den Moment, in dem unbemerkt die Ebene gewechselt wird und am Ende ein anderes Problem gelöst ist als das vereinbarte. Das Ergebnis kann sympathisch klingen und trotzdem den Auftrag verfehlen.
Ein Beispiel macht das greifbar. Ein Klient will abnehmen, das Ziel wird sauber definiert: wie viel, bis wann, woran er es merkt. Wenn am Ende des Prozesses nicht das Wunschgewicht steht, sondern die Erkenntnis “Ich kann mich so lieben, wie ich bin”, dann wurde die Ebene gewechselt. Der ursprüngliche Auftrag bleibt offen, und das Problem taucht mit hoher Wahrscheinlichkeit wieder auf.
Übertragen auf Softwareprojekte heisst das: Wer die Auftragsklärung schludert, riskiert, dass spät im Projekt auffällt, dass am eigentlichen Ziel vorbeigearbeitet wurde. Je sauberer der Auftrag am Anfang geklärt ist, desto kleiner ist dieses Risiko.
Relevanz erkennen ist die Kernkompetenz guter Tester
Gute Tester erkennen schnell, was relevant ist und worauf sich der Fokus richten muss. Sie betreten einen unbekannten Raum, durchschauen Strukturen und Abläufe und wissen, worauf es ankommt, auch wenn das Feld für sie neu ist.
Das lässt sich mit der Orientierung an einem grossen, fremden Flughafen vergleichen. Während die einen noch die Anzeigetafel suchen, sind die anderen schon auf dem Weg in die richtige Richtung. Diese Fähigkeit, Relevanz unmittelbar zu erkennen, trägt sich in viele Situationen, auch ins Gespräch, wo schnell klar wird, was zur Sache gehört und was nicht.
Eine zweite Stärke ist das Erkennen von Mustern und Algorithmen. Tester durchschauen Systeme und ihre Architektur und übertragen klassische Fehlerfallen, die sie aus Erfahrung kennen, auf neue Kontexte. Daraus entstehen die richtigen Fragen.
Talent ist nur das Sahnehäubchen, der Rest ist Praxis
Talent allein macht keinen guten Tester. Es ist, wie bei jeder Spitzenleistung, nur der kleinere Teil. Beim Sport sind es Training und Disziplin, beim Testen sind es vor allem Praxis und Erfahrung.
Wer sich schnell in ein Thema einarbeitet, schöpft das oft weniger aus Erinnerung als aus einem trainierten Zugriff. Ein paar Seiten überfliegen, das Muster erfassen, das Thema erklären: Das gelingt, weil über Jahre viel getestet und viel gelöst wurde. Diese Routine ersetzt das auswendige Wissen.
Wer sich zusätzlich interdisziplinär austauscht, erweitert seinen Erfahrungsschatz über das eigene Fach hinaus. Geschichten aus anderen Domänen liefern neue Perspektiven, die sich auf die eigene Arbeit übertragen lassen.
Fehler sind Helfer, nicht Makel
Menschen lernen am meisten aus Fehlern. Ein Kind lernt laufen, indem es hinfällt und wieder aufsteht, ohne den Sturz als Versagen zu werten. Im Lauf des Erwachsenwerdens und in unserer Gesellschaft kippt diese Haltung oft: Fehler werden zu Makeln, die nicht passieren dürfen.
Beim Testen verbessert die Auseinandersetzung mit Fehlern direkt die Qualität. Es lohnt sich, Energie in die Ursache zu stecken, statt Workarounds zu bauen. Wer nur drüberpatcht, statt sauber zu verstehen, was schiefläuft, verlagert das Problem nur.
Das Photoshop-Beispiel zeigt diesen Mechanismus aus Nutzersicht. Über Jahre wurde die Software immer voluminöser und träger, weil Funktionen scheinbar nur draufgesetzt statt sauber durchgearbeitet wurden. Schlankere Konkurrenzprogramme liefen plötzlich flott und leicht. Wer Fehler und Wartbarkeit ernst nimmt, vermeidet diesen Weg.
Produktfehler und Prozessfehler brauchen unterschiedliche Antworten
Beim Lernen aus Fehlern lohnt es sich, zwei Arten zu unterscheiden. Beide werden oft nur ins Backlog-Archiv geschoben und kaum nachbetrachtet, dabei steckt in beiden viel Lernpotenzial.
| Fehlerart | Was gemeint ist | Was hilft |
|---|---|---|
| Produktfehler | Echte Fehler in der Software | Nachbessern und Tests verbessern, um früher draufzukommen |
| Prozessfehler | Stellen, an denen der Ablauf hakt | Retrospektiven, Ursachen ansehen, Prozess verbessern |
Die Agilität hat in den letzten Jahren gezeigt, wie wertvoll der Blick auf Prozessfehler ist. Retrospektiven decken auf, wo es im Vorgehen klemmt, und machen den nächsten Durchlauf besser.
Bei beiden Fehlerarten geht es um dieselbe Frage: Wo kommen die Fehler her, und wie lassen sie sich künftig vermindern? Ganz aufhalten wird man sie nie, aber besser werden geht immer.
Der Trade-off zwischen neuen Features und wartbarer Software
In Projekten gibt es einen ständigen Konflikt: Neues schaffen gegen das Bestehende pflegen. Der Markt und die Kunden wollen neue Funktionen, gleichzeitig muss die Software wartbar bleiben.
Die eigentliche Aufgabe ist, zwischen beidem eine Balance zu halten. Wer die Wartbarkeit vernachlässigt, sitzt irgendwann auf einem Moloch, der nicht mehr gut funktioniert. Genau dieses Muster lässt sich in vielen Unternehmen beobachten.
Was Tester von der realen Nutzung lernen, lässt sich nicht vorab planen
Manche Erkenntnisse entstehen erst, wenn der Anwender die Software zum ersten Mal benutzt. Dann zeigt sich, wo er klickt und was er tut, und das ganze Projektteam staunt über Dinge, an die vorher niemand gedacht hat.
Die häufige Reaktion darauf ist ein Reflex: Alles muss spezifiziert, alles genau festgelegt werden. Dieser Weg führt selten weiter. Sinnvoller ist es, früher in die Interaktion zu gehen und zu beobachten, was der Anwender tatsächlich mit der Software macht.
Aus solchen Situationen lässt sich mehr lernen als aus jeder Detailplanung. Mit noch so viel Zeit und Budget lässt sich nicht vorausdenken, welches Gerät, welche Eingabe oder welchen Umweg ein Anwender wählt. Der Vergleich zur Kindererziehung passt: Man kann nicht vorab jeden möglichen Fehler durchspielen, man hält den Rahmen und geht mit den Fehlern um, wenn sie auftreten.
