Qualitätssicherung in agilen Projekten

Qualitätssicherung in agilen Projekten beginnt nicht beim Testen, sondern beim Reden. Wer früh Anforderungen klärt, Akzeptanzkriterien analytisch ableitet und eine Risikoklassifikation anlegt, reduziert Fehler strukturell. Tests bauen sich stufenweise auf: statische Analyse, Modultest, Integrationstest, Systemtest. Weglassen ist erlaubt, aber nur bewusst und mit bekanntem Risiko.

Das Wichtigste in Kürze

• Frühe Einbindung des Testteams in die Anforderungsphase verhindert teure Nachbesserungen, weil Akzeptanzkriterien bereits beim Schreiben der User Story auf Testbarkeit geprüft werden.
• Wer Testumfänge bewusst reduziert, muss das Risiko explizit benennen und regelmäßig prüfen, ob er es noch akzeptiert, sonst entstehen unbemerkte Qualitätslücken.
• Statische Codeanalyse und Vier-Augen-Reviews sind die schnellsten Qualitätssicherungsmaßnahmen im Prozess, weil sie Fehler beheben, bevor der Code überhaupt ausgeführt wird.
• Künstliche Intelligenz wird Testfälle aus Akzeptanzkriterien ableiten und ausführen, erfordert aber menschliche Kontrolle auf Meta-Ebene, weil KI nur so gut ist wie ihr Training.

Reden kommt vor Coden

Qualitätssicherung in agilen Projekten beginnt nicht mit Tests, sondern mit Gesprächen. Bevor jemand Code schreibt oder eine Funktion baut, gehört geklärt, was überhaupt entstehen soll und wohin die Reise geht. Erst aus diesem Verständnis lässt sich ableiten, wie man das Ganze testet.

Der Dialog ist die wichtigste Phase im gesamten Entwicklungsprozess, und er darf ruhig die längste sein. Was am Anfang sauber durchgesprochen wird, verkürzt alles, was hinten herauskommt. Das gilt nicht nur agil. Auch im klassischen Vorgehen müsste man früh dabei sein, nur zwingt der agile Rahmen stärker dazu, sich gleich zu Beginn an einen Tisch zu setzen.

Im klassischen Vorgehen konnte man sich als Tester lange wegducken: erst die Anforderer machen lassen, später draufschauen. Diese Bequemlichkeit fällt im agilen Umfeld weg. Tester müssen aktiv darauf hinwirken, dass alle Beteiligten früh eingebunden sind, sie selbst eingeschlossen.

Wie eine Anforderung zur testbaren User Story wird

Anforderungen landen im Backlog, typischerweise als User Story. Ein Beispiel: “Als Thomas möchte ich, dass der Button grün ist, damit ich ihn vom roten Untergrund unterscheiden kann.” So eine Story ist der Einstieg, nicht das Ende der Arbeit.

Aus der Story entstehen im Gespräch die Akzeptanzkriterien. Welcher Button ist gemeint? Welcher Farbcode genau? Sollen ähnliche Buttons mitziehen? Wie verhält sich der Button beim Klick? Jede dieser Fragen schärft die Anforderung und macht sie überprüfbar.

Wer mit dem Testerohr zuhört, erkennt früh die Punkte, die später für die Abnahme zählen. Genau hier zeigt sich der Wert: Wenn der Tester schon bei der Formulierung der Story dabei ist, fließen Testgedanken in die Anforderung ein, bevor eine Zeile Code existiert.

Jeder im Team braucht eine Testerbrille

Qualität ist keine Aufgabe für einen einzelnen Tester mit Ärmelschonern, der am Ende den Stempel setzt. Im Idealfall trägt jeder eine Testerbrille in der Tasche, auch der, der die Anforderung stellt, und der, der sie entwickelt.

Wenn der Anforderer und der Entwickler beide aus dem Testblickwinkel auf eine Story schauen, überlegen sie sich rechtzeitig, wie sich die spätere Qualität sichern lässt. Sitzt der fachliche Stakeholder mit am Tisch und gibt seine Einschätzung dazu, schließt sich der Kreis.

Damit das funktioniert, müssen Brücken zwischen Fachbereich und IT gebaut werden. Junge, frisch zusammengestellte Teams brauchen Begleitung, um den gefühlten Graben zu überwinden. Der ITler beißt nicht, wenn man ihm etwas Fachliches erklärt, und die Fachleute sind nicht abgehoben. Sind diese Brücken einmal da, läuft die Zusammenarbeit.

Der Dialog gehört dosiert, nicht maximiert

Alle an einen Tisch zu zwingen ist selten zielführend. Wichtiger ist, dass niemand allein im Kämmerchen sitzen bleibt. Sich zurückzuziehen, über das Aufgeschriebene nachzudenken und eine Nacht darüber zu schlafen, ist sinnvoll, danach muss es aber zurück in den Austausch.

Kleine Gruppen, die sich immer wieder abstimmen und ein Thema rund schleifen, bringen oft mehr als ein großes Meeting. Hat ein Thema einen gewissen Reifegrad erreicht, geht es ins Refinement oder Backlog-Grooming, wo die wesentlichen Beteiligten gemeinsam ein einheitliches Verständnis herstellen.

Die richtige Balance ist schwer zu finden. Alles in Refinement-Termine zu packen sprengt den Rahmen, und nicht jedes Detail ist für jeden interessant. Manchmal müssen fachliche Teile separat auseinandergeklamüsert werden oder die Techniker gehen noch einmal ins Konzept. Entscheidend ist, die Dialoge so zu schneiden, dass die richtigen Gespräche in den richtigen Kreisen stattfinden.

Vier Umgebungen, vier aufeinander aufbauende Teststufen

Ein typischer Aufbau besteht aus vier Umgebungen, die sich vom Entwickler bis zur Produktion immer weiter stabilisieren. Mit der Stabilität der Umgebung wachsen auch die Tests, die darauf laufen.

Bevor überhaupt etwas dynamisch ausgeführt wird, kommt die statische Prüfung. Eine statische Codeanalyse beantwortet, ob der Code verständlich, wartbar und sauber ist, oder ob toter Code, Syntaxverletzungen und unpassende Konstrukte drinstecken. Diese erste Qualitätsschleife liefert Befunde, ohne dass das Programm läuft.

Im Bankenumfeld kommt oft eine Charge-Code-Analyse hinzu, weil Sicherheit zählt: Es darf nichts drin sein, das später unbemerkt einen halben Cent abzweigt. Danach folgt ein Review durch einen zweiten Entwickler. Statische Analysen und Reviews sind Quick Wins, weil sie früh ansetzen und Robustheit ins System bringen, die man sich sonst später mühsam zusammensuchen müsste.

Warum man Teststufen bewusst weglassen darf, aber nicht versehentlich

Der vollständige Ablauf aus statischer Analyse, Modultest, Integrationstest und Systemtest ist der Idealfall, nicht die Pflicht für jede Situation. Für die ersten fünf Zeilen Code braucht es keine statische Analyse.

Der Punkt ist die Bewusstheit. Wer eine Stufe überspringt, muss das aktiv entscheiden und das damit verbundene Risiko benennen. Bei fünf Zeilen ist das Risiko überschaubar, bei 5000 Zeilen verliert man den Überblick, und dann muss eine zusätzliche Absicherung dazugeschaltet werden.

Die Aufgabe des Testmanagers ist es, dieses Bewusstsein zu schaffen: warum man testet, was man tun kann, was man bewusst weglassen darf und welche Risiken sich daraus ergeben. Genauso gehört dazu, immer wieder zu prüfen, ob ein einmal akzeptiertes Risiko noch akzeptabel ist oder sich die Rahmenbedingungen geändert haben.

Wer testet die Schnittstelle? Die Verantwortungsfrage bei Integrationstests

Bei Integrationstests entscheidet die Klärung der Verantwortung über die Qualität. Wenn jede Seite annimmt, die andere teste schon, entsteht in der Mitte ein Loch in der Schnittstelle, das niemand prüft.

Das Gegenteil ist genauso wenig hilfreich: Testen beide Seiten tief in den fremden Teil hinein, gibt es so viel Überlappung, dass es nicht voranbringt. Es muss klar sein, wem welcher Teil der Schnittstelle gehört und wo wer testet.

Jedes neue Inkrement verändert diese Abstimmung. Die eine Seite versteht ihren Teil technisch, die andere ihren, und beide müssen im Dialog bleiben, ob das Zusammenspiel noch funktioniert. Auch die Fachleute dahinter gehören in diesen Test eingebunden.

Was in einen einzigen Sprint gehört

In einen Sprint gehören nach den statischen Tests der Komponenten- und Modultest, der Systemintegrationstest und der Systemtest. Schaut der Fachbereich das erste Mal auf die Funktion und sind die Akzeptanzkriterien erfüllt, ist die Definition of Done erreicht und der Sprint kann abgeschlossen werden.

Bemerkenswert daran: Der Softwareentwicklungsprozess ist damit noch nicht am Ende. Die Software ist nicht in Produktion, der Sprint ist trotzdem fertig und die nächste Iteration kann starten. Der Abnahmetest folgt später, oft regulatorisch vorgeschrieben.

Modultests laufen meist automatisiert, weil über eine Version mehrfach iteriert wird. Das herzustellen und zu warten kostet Aufwand, legt aber eine solide Basis. Wenn alle Funktionen mit den denkbaren Datenausprägungen geprüft sind und mögliche Fehler abgefangen werden, kann technisch wenig danebengehen.

Liefere mehrmals im Sprint statt fünf Minuten vor dem Review

Der häufigste Fallstrick ist die Hektik am Sprintende, wenn fünf Minuten vor dem Review alles eingecheckt, gemerged, gepusht und gepullt wird. Das vermeidest du, indem du fertige Stücke früh ausliefest.

Ist eine Story durch statische Analyse, Review, Modultest und Integration gelaufen, liefere sie aus und lass den Fachbereich draufschauen, bevor du die nächste Story angehst. So bekommst du noch im selben Sprint Feedback, kannst Defekte sofort bearbeiten und stellst am Ende eine geprüfte Story vor, statt drei Tage Testarbeit auf den letzten Metern zu stapeln.

Diese frühe Auslieferung geht im Eifer des Gefechts oft verloren, ohne bösen Willen. Hier hilft der Blick von außen: freundlich anklopfen und an eine Zwischenlieferung erinnern, statt Druck aufzubauen. Spätestens in der Retrospektive lässt sich vereinbaren, künftig jede fertige Story sofort auszuliefern.

Wo der Testmanager im agilen Team sitzt

Die reine Rolle des Testmanagers gibt es agil kaum noch. Im Idealfall sitzt der Testmanager als T-Shaped-Person im Dev-Team: Er bringt den Testmanagement-Skill mit, kann aber auch entwickeln. In der Praxis gibt es oft Fullstack-Entwickler und daneben einen Testmanager.

Dann besteht seine Aufgabe darin, bei den Entwicklern das Bewusstsein für Qualität zu schärfen und an Schritte zu erinnern, die sonst untergehen. Er managt nicht nur Tests von außen, sondern zieht die Menschen mit hinein, damit alle früh dabei sind.

Warum Aktionismus die Qualität nicht hebt

Wenn die Qualität im Argen liegt, lautet der erste Reflex meist “wir müssen mehr testen”. Dann werden hinten am Abnahmetest in Masse Testfälle geschrieben, oft nicht qualitativ hochwertig, sondern irgendwelche, Hauptsache viele. Das hebt die Qualität nicht.

Typisch entstehen zwei Enden mit einer Lücke dazwischen. Auf der einen Seite viele Abnahmetests aus fachlicher Sicht, auf der anderen Seite Unit-Tests, die fast jeder Entwickler aus eigenem Qualitätsbedürfnis schreibt, aber meist aus dem Bauch heraus, ohne Vier-Augen-Prinzip und ohne analytische Methode. Beide Seiten sind nicht durchdrungen und greifen nicht ineinander.

Was fehlt, ist Systematik. Viele erinnern sich an Ad-hoc-Tests oder anforderungsbasierte Tests, weil das gut klingt. Dass es weitere Testfallermittlungsverfahren gibt, geht oft unter. Mit dem passenden Skillset stellt man andere Fragen und merkt etwa, dass ein Textfeld Sonderzeichen zulässt und deren Verhalten geprüft werden muss.

Schreibt man diesen Testfall früh auf, kann der Entwickler den Fall schon beim Bauen abfangen. Die Qualität steckt dann von vornherein drin.

Testumfang ist Risikomanagement, keine Vollabdeckung

Die wenigste Software muss vollständig durchgetestet werden, das wäre nicht rentabel. Eine Mondmission, bei der Menschenleben am Code hängen, verlangt eine ganze Schippe mehr Aufwand. Bei normaler Software darf man Testfälle weglassen, muss aber wissen, welche.

Die Auswahl folgt dem Risiko aus zwei Faktoren: Eintrittswahrscheinlichkeit und Auswirkung. Hochkomplexe, stark verschachtelte oder bibliotheksabhängige Codeabschnitte bekommen besonderes Augenmerk. Genauso die Stellen mit hohem fachlichem Risiko. Ein Login ist technisch oft simpel, muss aber funktionieren, denn ohne Login funktioniert keine Software.

Bei agiler Entwicklung über mehrere Iterationen kommt der Regressionstest hinzu, und auch dort wird nicht alles getestet, was je getestet wurde:

• Neue Funktionen (Progression): so viele Testfälle, wie wirtschaftlich vertretbar, um sie sauber auszutesten.
• Allgemeine Regression: Hochrisiko-Testfälle, die die Software auf Vitalität prüfen.
• Veränderte Bereiche: zusätzlich Testfälle mittleren Risikos, um rechts und links der Änderung zu prüfen, ob das Testobjekt noch funktioniert.

Eine Risikoklassifizierung der Testfälle macht diesen Zugriff schnell. Keine Doktorarbeit, sondern grobe Stufen wie hoch, mittel, gering bei Komplexität und Auswirkung. Über diese Matrix lässt sich für jede Regression gezielt hineingreifen, und sind die Testfälle automatisiert, kostet ein zusätzlicher kaum noch etwas.

Dokumentation widerspricht dem agilen Gedanken nicht

Das agile Manifest sagt nicht, dass Dokumentation unwichtig ist, sondern dass es Wichtigeres gibt. Das Wichtigere ist das Gespräch. Irgendwann muss das Besprochene aber aufgeschrieben werden, damit man in drei Monaten oder drei Jahren noch nachvollziehen kann, was man getan hat.

Eine Risikoklassifizierung am Testfall, ein definiertes Testobjekt und strukturiert abgelegte Testfälle helfen gerade agil, weil man die Testfälle sehr häufig in die Hand nimmt und sich Teams ändern. Die Dokumentation bleibt knapp: kurz reinschreiben, wie man auf den gewählten Testumfang gekommen ist, keine Romane.

Über den Umfang entscheidet das Team gemeinsam. Product Owner als Vertreter des Fachbereichs und Entwickler überlegen zusammen, was ein sinnvoller Umfang ist, statt dass ein einzelner Testmanager im Hintergrund einen großen Testplan schreibt. So existiert dasselbe Verständnis im ganzen Team.

Qualität als Haltung, KI als Werkzeug mit blinden Flecken

Qualität als Haltung begreifen, mit Automatisierung umgehen und künstliche Intelligenz nutzen, aber das Können und das Nichtkönnen unterscheiden. — Christian Mercier

Künstliche Intelligenz wird das Testen stärker automatisieren. Aus Akzeptanzkriterien lassen sich Tests ableiten und ausführen, ohne dass man jeden Testfall selbst schreibt. Das verschiebt die Arbeit, ersetzt aber nicht die Kontrolle.

Auch eine KI hat Fehler und blinde Flecken, und sie ist nur so gut, wie sie trainiert wurde. Wer eine KI nicht selbst trainiert, muss umso genauer hinschauen, was sie tut und was nicht. Der Mensch erreicht hier eine Meta-Ebene: Er muss wissen, was die Automatisierung leisten kann und wo ihre Grenzen liegen.

Qualität endet nicht beim Review. Abnahmetests und ein After-Go-Life-Check gehören zu einem durchgängigen Prozess. Diese Haltung sollte jeder mitbringen, der an Software arbeitet, nicht nur der Tester.