Kontext beim Testen umfasst alles, was bestimmt, wie gutes Testen in einer konkreten Situation aussieht: Bedingungen, Menschen, Werkzeuge, Prozesse und das, was noch niemand weiß. Weil sich dieser Kontext ständig verschiebt, ist „Es kommt darauf an“ keine Ausrede, sondern die einzig ehrliche Antwort. Kontextgetriebenes Testen setzt genau hier an: Es gibt gute Praktiken im jeweiligen Kontext, aber keine Best Practices, die überall passen. Wer neugierig bleibt, nach dem Warum hinter Werkzeugen und Prozessen fragt und Veränderung als Chance sieht, kann am meisten für echte Qualität tun.
Das Wichtigste in Kürze
- „Es kommt darauf an“ ist in komplexen Umgebungen die einzig ehrliche Antwort, weil der Kontext nie feststeht und während der Arbeit laufend neue, unbekannte Faktoren auftauchen.
- Entschiedene Bescheidenheit heißt, klar zu wissen, was man nicht weiß und wo man die Antwort findet. Für Tester ist das mehr wert als vorgespielte Gewissheit.
- Nach dem Zweck eines Werkzeugs, eines Prozesses oder einer Entscheidung zu fragen, gehört zur Aufgabe von Testern, denn ungeprüfte Annahmen führen zu falschen Lösungen.
- Gewinner sammeln mehr Fehlschläge als Verlierer: Wer im Unbekannten handelt, lernt dabei. Wer nichts tut, hat nichts, worauf er aufbauen kann.
- Tester, die sich aus der KI-Debatte heraushalten, riskieren, dass Menschen ohne Verständnis für Softwarequalität ihr Handwerk durch Werkzeuge ersetzen.
Kontext beim Testen: Warum „Es kommt darauf an“ keine Ausrede ist
Auf fast jede Testfrage lautet die ehrliche Antwort: „Es kommt darauf an.“ Das ist kein Ausweichen. Solange das ganze Bild noch nicht sichtbar ist, gibt es keine genauere Antwort. Kontext beim Testen ist deshalb der Ausgangspunkt jeder Entscheidung, und darauf baut kontextgetriebenes Testen auf.
Ausführlicher heißt die Antwort: „Es kommt auf den Kontext an.“ Eine Testerin kann eine Einschätzung geben, gestützt auf Erfahrung, frühere Projekte und das, was sie gelesen hat. Die eigentliche Antwort bleibt aber offen, bis der Kontext verstanden ist.
Iterative Arbeit verschärft das. Unterwegs entsteht, was heute noch niemand kennt. Kontext steht nie fest. Sinnvoll ist deshalb nur eines: flexibel und pragmatisch bleiben und so gut informiert sein, wie die Arbeit es gerade verlangt.
Schwierig ist, „Es kommt darauf an“ zu sagen, ohne dass es nach Drückebergerei klingt. Kontext als echten Wert zu vertreten statt als Entschuldigung, verkauft sich schlechter, als schnell und selbstbewusst das Falsche zu tun.
Entschiedene Bescheidenheit: Sei dir sicher, was du nicht weißt
Für Tester in einem Umfeld, das sich ständig ändert, zählt eine Eigenschaft besonders: entschiedene Bescheidenheit. Du stehst klar dazu, wie viel du nicht weißt, und weißt zugleich genau, wo du diese Lücken schließen kannst.
Neugier und kritisches Denken gelten als die klassischen Eigenschaften im Testen. Entschiedene Bescheidenheit gehört gleichrangig dazu. Du bist dir über die Grenzen deines Wissens im Klaren und weißt, was du lesen, wen du fragen und wann du nachhaken solltest.
Dazu passt ein vorsichtiger Optimismus. Veränderungen in der Branche lösen meist Angst vor dem Unbekannten aus, und ein Teil dieser Angst ist berechtigt. Im Unbekannten stecken aber auch Chancen. Es ist besser, bei einer Veränderung vorne mit dabei zu sein, als abzuwarten und sie nur als Bedrohung zu sehen.
Sich im Unbekannten wohlzufühlen, widerspricht der klassischen Denkweise, die einen gut vermessenen Weg und ein bekanntes Ziel schätzt. Mit dem Unbekannten souverän umzugehen, müssen Tester heute bewusst lernen.
Tester sind auf Katastrophen trainiert, und das hat seinen Preis
Viele sind zum Testen gekommen, weil sie Risiken und Probleme gut erkennen. Genau dieser Instinkt kann sich gegen sie wenden.
Wer nur als Überbringer schlechter Nachrichten gilt, wird schnell zum Neinsager: negativ, teuer, im Meeting ungern gesehen. Dieser Ruf belastet die Zusammenarbeit mit anderen Disziplinen im Team.
Den Blick vom Scheitern auf den gemeinsamen Erfolg zu lenken, ist weder leicht noch naheliegend. So gewinnt ein Team aber gemeinsam, statt in verschiedene Richtungen zu ziehen.
Wie veränderst du eine Haltung, ohne sie zu verordnen?
Du kannst nicht zu Leuten gehen und ihnen eine neue Haltung befehlen. Der Weg führt über die einzelnen Menschen, mit denen du arbeitest.
Geh zurück zum Kontext. Finde heraus, was eine Kollegin oder ein Kollege will, was ihr oder ihm wichtig ist, was sie meiden und wo im Alltag der Druck sitzt. Mit diesem Wissen kannst du ein Problem benennen und es als Chance darstellen statt als Vorwurf.
Allein solltest du das selten angehen. Vor einem wichtigen Gespräch hilft ein Realitätscheck mit jemandem, dem du vertraust. So prüfst du, ob du die Lage richtig einschätzt, auch wenn du dafür manche Details weglassen musst.
Einen Plan laut auszusprechen, bringt oft mehr, als ihn im Kopf kreisen zu lassen. Ergänze ihn um den Satz der entschiedenen Bescheidenheit: „Ich weiß hier nicht alles, aber ich sehe, wo wir besser werden können, und ich glaube, das schaffen wir gemeinsam.“ So eine Formulierung lädt andere zum Mitmachen ein.
Software entsteht mit Menschen, nicht an ihnen vorbei
Als Insel kommst du nicht weit. Die eigene Karriere fühlt sich an wie die eigene Geschichte, doch in den Geschichten der anderen bist du nicht die Hauptfigur. Wachstum entsteht in der Zusammenarbeit.
Dass Softwaretesten eine soziale Tätigkeit ist, gilt auch dann noch, wenn KI immer mehr Teile der Arbeit durchdringt. Soziale Interaktion bleibt der Kern dessen, was Erfolg möglich macht.
Deshalb lohnt sich der Perspektivwechsel: Frag eine Kollegin zuerst, was ihr wichtig ist und was sie braucht. Bau die Beziehung auf, bevor du das Thema ansprichst, das du klären willst.
Soft Skills sind schwerer zu lernen als Hard Skills
Soft Skills lernen sich schwer, weil sie Selbstreflexion verlangen. Du musst dein eigenes Verhalten auseinandernehmen. Wie ein Werkzeug oder eine Technik lassen sie sich nicht aneignen.
Chris Armstrong nennt The Five Love Languages von Gary Chapman als Ausgangspunkt, den er auf Engineering-Teams übertragen hat: Aus Liebe wird Wertschätzung. Entwicklerinnen, Leute aus dem Kundenservice und technische Redakteure ticken unterschiedlich und lassen sich von unterschiedlichen Dingen motivieren.
“Softwaretesten ist eine soziale Tätigkeit. Soziale Interaktion ist nach wie vor der Kern dessen, was wir für unseren Erfolg brauchen.”
(Chris Armstrong)
Auch in der Art, sich zu konzentrieren, unterscheiden sich Menschen. Manche denken im großen Ganzen, andere im kleinsten Detail. Manche reagieren gereizt, wenn man sie aus tiefer Konzentration reißt, und finden danach nur schwer zurück. Wer diese Unterschiede nicht versteht, arbeitet nicht gut mit anderen zusammen. Remote-Arbeit nimmt zudem viele soziale Signale weg, die früher geholfen haben.
Einfluss hängt nicht an der Hierarchie. Wer sich als Tester im Team für Qualität einsetzt und neue Ideen einbringt, hat bereits Einfluss. Ihn gut zu nutzen heißt: stilleren Kollegen Zeit und Raum geben und Menschen respektvoll behandeln, statt mit dem Finger auf sie zu zeigen und den Plan zu verkünden.
Warum „die Person, die Fragen stellt“ eine gute Beschreibung von QA ist
Wer nie fragt, warum es etwas gibt, setzt womöglich die falsche Technologie ein, ohne es je zu merken. Nach Zweck und Vorgeschichte eines Werkzeugs, eines Prozesses oder einer Entscheidung zu fragen, ist Teil der Arbeit.
Sinnvolle Fragen ziehen sich durch den ganzen Technologie-Stack. Warum haben wir dieses Werkzeug gewählt? Wie kam es zu der Entscheidung? Wird es bald abgekündigt? Trägt es die geplante Architektur? Gibt es für das Frontend-Framework, das das Team tatsächlich nutzt, eine größere Auswahl an Werkzeugen?
Kontext zu verstehen, ist keine einmalige Aufgabe. Es hört nie auf. Stillstand ist die einzige Entscheidung, die verlässlich falsch ist, denn alles, was über Strategien, Roadmaps oder Best Practices veröffentlicht wird, ist in dem Moment, in dem es erscheint, schon auf dem Weg, zu veralten.
Das gilt auch für die eigenen Strategien, Standards und Praktiken. Sie sollten zu dem passen, was du heute weißt, und beweglich genug bleiben für das, was als Nächstes kommt.
Respektvoll fragen, warum ein Werkzeug gewählt wurde
Zu jemandem zu gehen, der die Entscheidung getroffen hat, und die Werkzeugwahl zu hinterfragen, ist tatsächlich schwer. Die meisten Menschen erzählen aber gern, wie sie die Sache sehen, wenn man sie richtig fragt.
Auf die Formulierung kommt es an. „Das war eine miese Entscheidung, was ist denn hier los?“ wirft dich um mehrere Schritte zurück, erst recht, wenn dein Gegenüber das Werkzeug eingeführt hat. Der Blick auf den gemeinsamen Erfolg hält den Respekt aufrecht.
Ohne die Frage fehlt dir der Kontext, und ohne Kontext kannst du keine passende Lösung anbieten. Manchmal lautet die ehrliche Antwort „Ich weiß es nicht“. Mit KI wird diese Antwort häufiger werden.
Keine Entscheidung zu treffen, ist schlimmer als eine Absage oder ein Fehlschlag. Auf etwas Unbekanntem lässt sich nichts aufbauen. Auf ständigem Wandel legt niemand ein Fundament.
Gewinner scheitern öfter als Verlierer
Wer etwas versucht, ins Unbekannte geht und experimentiert, sammelt mehr Fehlschläge als jemand, der stillhält. Die Fehlschläge sind der Preis der Bewegung.
Das reicht bis in den Testentwurf. Trau keinem Test, den du nie hast fehlschlagen sehen. Ein fehlschlagender Test gibt dir die Sicherheit, dass er wirklich etwas prüft. Reiner Erfolg ohne jeden Aussetzer sollte dich misstrauischer machen als ein Fehlschlag, aus dem du etwas lernst.
KI ist eine grüne Wiese, und darin liegt die Chance
Für das Testen ist KI weitgehend eine grüne Wiese. Es gibt etwas Literatur und etwas Forschung, aber Arbeitsweisen, Qualitätsmerkmale und Methoden müssen sich erst in der Praxis herausbilden.
Die Skepsis ist verständlich. Sie erinnert an den Boom der Testautomatisierung vor 10 bis 15 Jahren. Und ja: Was Tester heute tun, wird sich ändern. Der Wandel kommt so oder so. Die Chance liegt darin, ihn mitzugestalten.
Halten sich Tester heraus, baut jemand ohne Verständnis für das Handwerk ein Werkzeug, verkauft es an jemanden, der die Arbeit selbst nicht macht, und verspricht Zeitersparnis und rundum optimierte Abläufe. Die Tester stehen dann daneben und sagen „Aber nein, das verstehe ich nicht“, weil sie nur ihre Arbeit gemacht haben, statt die Entwicklung mitzuprägen.
Die Qualität von Prompts und von GPT-Ergebnissen gehört künftig zum Werkzeugkasten. Die Alternative: Softwarequalität rutscht auf die unterste Stufe, und Tester können nicht mehr erklären, warum, außer mit „Ich hab’s ja gesagt“.
Was Qualität bedeutet, verschiebt sich weiter
Qualität definieren die Nutzer, und diese Definition bleibt in Bewegung. Was eine Generation an Medien konsumiert, kann für die nächste furchtbar aussehen und trotzdem genau die Wünsche und Bedürfnisse seines Publikums treffen.
Den Nutzern ist egal, wie Qualität zustande kommt. Testern nicht, weil sie für die richtigen Menschen die beste Arbeit abliefern wollen, auf die sie stolz sein können. Das Zusammenspiel von Verifikation und Validierung bleibt. Der Arbeitsalltag wird völlig anders aussehen.
Wenn KI-gestütztes Programmieren in den kommenden Monaten und Jahren deutlich mehr Software hervorbringt, wird die Frage drängender, wer sie testet und wer sich für ihre Qualität einsetzt. Selbst das Testen der Tests gehört dann dazu.
Wie priorisierst du, wenn du alles hinterfragen könntest?
Nimm dir zuerst wenige Themen vor. Ohne Grenzen erkundest du endlos, und nichts wird ausgeliefert. Starte deshalb mit einer kleinen Zahl von Hypothesen aus den ersten Gesprächen.
Angenommen, du vermutest ein Problem mit der Release-Qualität. Geh der Sache nach. Sprich mit den Leuten, die es wissen müssten: dem Kundenservice, den Verantwortlichen für Pipeline oder DevOps, den Testern. Lies die Logs. Rede nicht nur mit Menschen, sondern verschaff dir Zugang zu den Werkzeugen und schau dir die Belege selbst an.
Eine Discovery-Phase liefert greifbare Ergebnisse, nicht nur Gespräche: Arbeitshypothesen für den Realitätscheck, Beobachtungen, eine Bewertung des Technologie-Stacks, offene Warum- und Wie-Fragen und Problembeschreibungen von den wichtigsten Beteiligten. Was läuft gut? Was nervt jeden Tag?
Eine brauchbare Definition von Qualität lautet: unnötige Reibung entfernen. Manche Reibung ist nötig. Die Aufgabe besteht darin, das zu finden, was ohne Grund im Weg steht. Diese Reibung kann in Pipelines, Prozessen, der Kultur oder der Technologie selbst stecken.
Das Vorgehen gleicht dem Testen. Du würdest keinen End-to-End-Test schreiben, ihn nie laufen lassen, einchecken und für erledigt erklären. Niemand sollte so einem Test trauen. Wenn du den Kontext einer Organisation erschließt, geh genauso vor: Annahmen mit Menschen prüfen, dort langsamer werden, wo es nötig ist, und gezielt Fehler provozieren, um zu sehen, was hält und wo es bricht.
Dieselbe Regel gilt für KI-gestütztes Testen. Arbeite mit Plan, Hypothese, Ziel und Abnahmekriterien. Geh die Schritte durch, prüfe die Ergebnisse und lass sie gegenlesen. Bewerte deine eigene Arbeit nie selbst.
Häufig gestellte Fragen
Was sollte ein Tester sagen, wenn jemand eine definitive Antwort will, der Kontext aber noch nicht klar ist?
„Das kommt darauf an“ ist die ehrliche Antwort, keine Ausflucht. Ein Tester kann eine Meinung äußern, die auf Erfahrung, früheren Fällen und Literatur basiert, aber die eigentliche Antwort bleibt offen, bis der Kontext verstanden ist. Iteratives Arbeiten verdeutlicht das: Es tauchen Faktoren auf, die zu Beginn niemand kennt. Daher ist es sinnvoll, flexibel, pragmatisch und so gut informiert zu bleiben, wie es die aktuelle Arbeit erfordert.
Welche Qualitäten sind für Tester in sich ständig verändernden Umgebungen am wichtigsten?
Entschiedene Bescheidenheit geht Hand in Hand mit Neugier und kritischem Denken. Das bedeutet, sich bewusst zu sein, wie viel man nicht weiß, und gleichzeitig zu wissen, was man lesen, wen man fragen und wann man fragen muss. Dazu gehört auch vorsichtiger Optimismus. Die Angst vor dem Unbekannten ist verständlich, doch an der Spitze eines Wandels zu stehen ist besser, als abzuwarten und ihn als Bedrohung zu betrachten.
Warum haben Tester letztendlich den Ruf, negativ zu sein?
Viele Tester fühlen sich zu dieser Rolle hingezogen, weil sie gut darin sind, Risiken und Probleme zu erkennen, und genau dieser Instinkt wirkt sich nun gegen sie aus. Ein Tester, der nur als Quelle von Katastrophen gesehen wird, wird zur unerwünschten Person, zum Kostenfaktor, zu demjenigen, den niemand im Raum haben will. Dieser Ruf untergräbt die Zusammenarbeit mit funktionsübergreifenden Teams. Der Wechsel vom Blick auf das Scheitern zum Blick auf den gemeinsamen Erfolg ist das Gegengewicht.
Wie sprichst du ein Problem bei einem Kollegen an, ohne dass es wie ein Vorwurf klingt?
Verstehe zuerst die Person: Was ihr wichtig ist, was sie vermeidet, wo die täglichen Druckpunkte in ihrer Arbeit liegen. Dann benenne das Problem und stelle es als Chance dar. Ein Abgleich mit einem vertrauenswürdigen Kollegen vor dem Gespräch hilft dir, deine Einschätzung der Situation zu testen. Den Plan laut auszusprechen ist sinnvoller, als ihn nur im Kopf hin und her zu wälzen.
Warum sind Soft Skills schwieriger zu erlernen als technische Fähigkeiten?
Sie erfordern Selbstreflexion und eine Analyse deines tatsächlichen Verhaltens, also etwas, das kein Tool und keine Technik von dir verlangt. Menschen unterscheiden sich auch darin, wie sie sich konzentrieren: Manche betrachten das große Ganze, andere beschäftigen sich mit kleinsten Details, und manche werden stark aus der Bahn geworfen, wenn sie aus ihrer tiefen Konzentration gerissen werden. Bei der Remote-Arbeit fehlen viele der sozialen Signale, die diese Unterschiede früher sichtbar gemacht haben.
Ist es die Aufgabe eines Testers, zu hinterfragen, warum ein bestimmtes Tool ausgewählt wurde?
Ja. Ohne diese Frage bleibst du ohne Kontext, und ohne Kontext kannst du keine korrekte Lösung anbieten. Sinnvolle Fragen sind zum Beispiel, wie das Tool ausgewählt wurde, ob es ausgemustert wird und ob es die zukünftige Architektur unterstützt. Die Art der Fragestellung entscheidet über das Ergebnis: Wenn du die Wahl kritisierst, wirft dich das mehrere Schritte zurück, vor allem bei der Person, die das Tool eingeführt hat.
Wie schränkst du den Fokus ein, wenn fast alles in einer Organisation hinterfragt werden könnte?
Beginne mit einer kleinen Auswahl an Hypothesen, die aus ersten Gesprächen stammen. Ohne Grenzen dauert die Erkundung ewig und es kommt nichts auf den Markt. Wenn die Qualität des Releases der Schwachpunkt zu sein scheint, sprich mit Kundendienstmitarbeitern, den Mitarbeitern aus der Pipeline oder dem DevOps-Team sowie den Testern und lies die Protokolle, anstatt dich allein auf Gespräche zu verlassen. Eine Erkundungsphase sollte Beobachtungen, eine Überprüfung des Tech-Stacks und Problemstellungen liefern.
Macht die Verbreitung von KI Softwaretester überflüssig?
Das größere Risiko liegt in der anderen Richtung. Wenn Tester sich aus der KI-Entwicklung heraushalten, entwickelt jemand, der das Handwerk nicht versteht, ein Tool, verkauft es an jemanden, der die Arbeit nicht macht, und verspricht Zeitersparnis und eine Optimierung aller Bereiche. Da KI-gestütztes Programmieren weitaus mehr Software hervorbringt, lautet die drängende Frage: Wer testet sie und wer setzt sich für ihre Qualität ein?
