Qualität als Haltung

Qualität als Haltung bedeutet, dass Softwarequalität nicht Aufgabe einer einzelnen Testabteilung ist, sondern gemeinsame Verantwortung des gesamten Entwicklungsteams. Drei Faktoren prägen erfolgreiche Teams: das konsequente Nutzen von Testgrundlagen, der gezielte Einsatz von Testautomatisierung und ein kollektives Qualitätsmindset, das jeden Schritt der Entwicklung durchzieht.

Das Wichtigste in Kürze

• Qualität ist keine Aufgabe einer Testabteilung, sondern Gesamtverantwortung des gesamten Teams, von Entwicklung über UX bis zum Product Owner.
• Fehlende Unit-Tests sind kein technisches Detail, sondern ein Warnsignal für Architekturprobleme, die spätere Refactorings blockieren und Fehler verbergen.
• Statische Codeanalyse als harte Pipeline-Schranke zu konfigurieren, statt ihre Ergebnisse zu ignorieren, verhindert den schleichenden Aufbau technischer Schulden.
• Testautomatisierung ohne Qualität der Testfälle produziert nur schnell wertlose Tests: 30.000 automatisierte Fälle können bewusst eingebaute Fehler komplett übersehen.

Qualität als Haltung: warum gute Software im Mindset beginnt

Qualität ist kein Arbeitsschritt am Ende, sondern eine Haltung, die ein Team von Anfang an mitträgt. Über zwanzig Jahre Testprojekte zeigen ein wiederkehrendes Muster: Wenn Entwicklungs- und Testteams wirklich gut zusammenspielen und belastbare Qualität ausliefern, lassen sich drei Faktoren erkennen. Solide Grundlagen, ernsthaft betriebene Automatisierung und Qualität als gemeinsame Verantwortung. Ob das Vorgehen agil oder klassisch ist, spielt dabei kaum eine Rolle.

Was gehört zu den Testgrundlagen?

Die Grundlagen des Testens sind seit Jahrzehnten beschrieben, werden im Alltag aber oft übersprungen oder gar nicht bedacht. Sie bilden das Fundament, auf dem alles andere aufsetzt. Wer sie ignoriert, baut Qualität auf Sand.

Der erste Baustein sind saubere Teststufen. Unit-Tests prüfen jede Einheit für sich, bleiben kleinteilig und liefern Entwicklern schnelles Feedback bei Refactorings. Integrationstests zeigen, wie Komponenten zusammenspielen und ob die Schnittstellen im System funktionieren. Systemtests schauen von außen auf Geschäftsprozesse, Oberflächen und Performance. Abnahme- und Akzeptanztests klären, ob das Umgesetzte dem entspricht, was der Fachbereich tatsächlich wollte.

Diese Trennung ist kein Selbstzweck, sondern eine Frage der Sauberkeit. In der Praxis stecken oft viele Integrationstests in den Unit-Tests, die dann eine halbe Stunde laufen. Ein Feedback-Mechanismus, auf den man eine halbe Stunde wartet, ist keiner. Und der Satz “Hier können wir keine Unit-Tests machen, das geht halt nicht” ist meist ein Warnsignal: Stimmt etwas mit der Architektur oder dem Entwurf nicht?

Du musst nicht jede Teststufe bedienen. Aber du solltest dir überlegen, welche Qualitätsaspekte du auf welcher Stufe für dein Produkt wirklich brauchst.

Funktionalität allein reicht nicht

Testarten beantworten die Frage, welche Qualitätsmerkmale du überhaupt prüfst. Funktionalität ist fast immer gesetzt: Was soll das System tun? Dazu gibt es reichlich Anforderungen. Bei den nicht-funktionalen Bereichen wird es dann dünn.

Usability, Performance, Zuverlässigkeit, Wartbarkeit, Portabilität: Diese Kriterien fallen in vielen Projekten hinten runter, weil der Fokus rein auf der Funktion liegt. Das rächt sich später. Performance-Probleme sind oft architekturelle Schwächen, und die deckt man besser früh auf als kurz vor dem Release.

Damit das funktioniert, müssen nicht-funktionale Anforderungen definiert sein. “Schnell und schön” ist keine prüfbare Anforderung. Du brauchst etwas Belastbares, gegen das du testen kannst.

Wie schreibt man einen guten Testfall?

Ein guter Testfall verfolgt einen Zweck, er ist nicht da, um da zu sein. Dafür existieren seit Jahrzehnten strukturierte Methoden, die auf allen Teststufen greifen, vom Unit-Test bis zum Akzeptanztest.

Äquivalenzklassenbildung, Grenzwertanalyse, Entscheidungstabellen und zustandsbasierter Test sind solche Methoden. Sie verfolgen eine Idee, wie man systematisch zu wirkungsvollen Testfällen kommt, statt beliebig viele zu schreiben.

Eine hohe Codeabdeckung allein bringt nichts, wenn die Qualität der Testfälle darunter leidet. Auf 80, 90 oder 100 Prozent zu schielen, hilft wenig, wenn die Tests schwach sind. Jede Anforderung bietet unzählige Testmöglichkeiten. Die wirklich guten herauszufinden, spannt das Netz, mit dem du echte Fehler fängst.

Statische Analyse ist der unterschätzte Quick Win

Statische Analyse findet Mängel, bevor überhaupt lauffähige Software existiert. Sie prüft Quellcode oder Dokumente vom ersten Moment an und ist damit einer der schnellsten Hebel für mehr Robustheit.

Linting-Werkzeuge oder SonarQube prüfen Code auf Schwachstellen und Verletzungen von Mustern. In eine Build-Pipeline integriert, siehst du sofort, wie es um die Qualität deines Codes steht. Nicht jedes Finding ist ein echter Fehler, aber jedes weist auf eine mögliche Unsauberkeit hin. Früh behoben, entsteht daraus ein solider Block an Robustheit.

Der typische Fehler in Unternehmen: Die Tools laufen mit, produzieren Hunderte oder Tausende Issues, und am Ende werden sie ignoriert. Das ist der falsche Weg. Schau dir an, welche Regeln verletzt wurden, behebe punktuell und arbeite dich sukzessive durch. Sonst nimmst du all diese technischen Schulden in die weitere Entwicklung mit.

Reviews verbreiten Wissen und finden Fehler

Die manuelle Analyse gehört genauso zu den Grundlagen wie die automatisierte. Code-Reviews, Architektur-Reviews und Pairing finden Fehler und verteilen Wissen im Team.

Gerade in agiler Entwicklung ist das einer der wichtigsten Faktoren. Wenn mehrere Leute gemeinsam auf den Code schauen, kennt sich jeder mit den Teilen aus, und das Team findet eine gemeinsame Basis dafür, wie es eigentlich entwickeln will.

Automatisiere, was sich automatisieren lässt, aber nicht blind

Testautomatisierung ist die Voraussetzung dafür, Software häufig zu releasen. Wer mehrfach pro Woche oder pro Tag ausliefern will, braucht eine robuste Testsuite, die genug abprüft, um Fehler aus der Produktion fernzuhalten.

Der Fortschritt ist spürbar. Früher war Automatisierung auf höheren Teststufen ein Gefrickel, und Abnehmer saßen stundenlang in Testräumen und klickten Testfälle durch. Heutige Werkzeuge bringen hier deutlich mehr Effizienz, besonders bei Akzeptanztests.

Gerade weil Automatisierung so verlockend ist, lohnt der Blick darauf, was sinnvoll zu automatisieren ist. Wer Mist automatisiert, hat Mist nur schneller.

Ein Projekt hatte rund 30.000 bis 40.000 automatisierte Testfälle. Beim Versuch, über bewusst eingebaute Fehler herauszufinden, ob die Tests anspringen, bemerkte kein einziger Testfall den eingeschleusten Fehler. Eine große Zahl an Tests sagt nichts über ihre Wirkung aus.

Qualität ist Teamverantwortung, nicht Testerpflicht

Qualität ist nicht die Aufgabe einer einzelnen Person oder einer Testabteilung, der man fertige Software über den Zaun wirft. Das klassische Modell, bei dem nach drei Wochen Fehler zurückkommen und niemand mehr weiß, worum es ging, funktioniert nicht mehr.

Stattdessen kommen Tester, Entwickler, Architekten, UX-Designer, Anforderer und Product Owner als Team zusammen und denken Qualität von Anfang bis Ende mit. Jeder übernimmt sie als eigene Verantwortung. In Teams, die das leben, entsteht eine hohe Selbstverantwortung. Niemand sagt “Testen interessiert mich nicht, das soll wer anders machen”.

Gute Software heute ist einfach auch getestet und voller Qualität.

Richard Seidl

Harte Schranken trennen gute Teams von guten Absichten

Disziplin in der Pipeline ist das, was leistungsstarke Teams auszeichnet. Statische Analyse lässt sich in die Build-Pipeline einbauen und auswerten. Der Unterschied liegt darin, was dann passiert.

Optionale Ergebnisse, die man “später” anschaut, verpuffen. Eine harte Schranke nicht: Tritt ein neuer Mangel auf, fällt ein Test um oder sinkt die Codeabdeckung, geht es im Build-Prozess nicht weiter. Die roten Lampen gehen an, das Team kommt zusammen und behebt den Fehler.

Ein ignorierter Fehler bleibt selten allein. “Mache ich morgen, nach dem Release” wird zum zweiten, dritten, vierten Fehler. Irgendwann steht das Unternehmen vor einem Berg Altsoftware, in der “TBD” im Kommentar steht und niemand mehr weiß, wo etwas hingehört. Diese Dinge im Nachhinein aufzuräumen kostet viel mehr Aufwand, als sie gleich sauber zu machen.

Wie wird Qualität zur Selbstverständlichkeit?

Qualität als Haltung ist ein Prozess, der Zeit braucht und sich nicht über Nacht einstellt. Er beginnt mit den Grundlagen, nutzt Automatisierung und entwickelt daraus das gemeinsame Selbstverständnis, gute Software in Produktion zu bringen.

Dafür braucht ein Team einen passenden Rahmen. Nicht der Projektleiter ordnet Qualität an. Wirksamer ist die Frage, wie man selbst als Vorbild vorangeht. Ein Quality Engineer kann andere coachen, als Mentor begleiten und Wissen weitergeben, etwa vom guten Unit-Test hin zum guten Akzeptanztest.

Wenn diese drei Aspekte zusammenkommen, verliert das Thema seine Schwere. Statt des seufzenden “Da müssen wir auch noch testen, wer soll das machen?” wird Qualität zum Selbstverständnis. Genau das macht Software langlebig, statt sie in zehn Jahren zum alten Hut werden zu lassen, an den sich niemand mehr herantraut.