Qualitätssicherung von der Anforderung bis zur Auslieferung
📌 Konferenz-Tipp: TACON 2026 in Leipzig (16.–17. September). Ich war letztes Jahr als Keynote dort und fand den Austausch richtig gut 👉 https://swt.fm/tacon
„Das Leben ist zu kurz, keine Unitests zu schreiben." – Alexander Vukovic
Hinter Shift Left steckt die Idee, Qualität so früh wie möglich im Entwicklungsprozess zu betrachten. Denn je später Qualitätsprobleme gefunden werden, desto teurer und aufwändiger ist deren Behebung. D.h. wir versuchen, alle Aktivitäten, die zu hoher Qualität beitragen und ebenso Qualitätsprüfungen so früh wie möglich umzusetzen. Dabei spielen nicht nur saubere Unittests eine große Rolle, sondern auch die Entwicklungsumgebung, die Code-Qualität, der Inhalt der User-Stories, etc.
Seit 1989 beschäftigt Alex sich mich mit Softwareentwicklung, seit 1996 mit dem Spezialbereich Softwaretesting. Als leidenschaftlicher Entwickler ist ihm die Qualität von Software ein Herzensanliegen. Seine Kerngebiete liegen in der Beratung insbesondere im agilen Quality Coaching, Methoden Training, Product Owner, der internen Produktentwicklung und im Lasttestbereich. In seiner Freizeit arbeitet er als Lektor für Softwaretest und Qualitätsmanagement am Technikum Wien. Aktuell beschäftigt er sich mit dem razzfazz.io-Entwicklungsteam mit Node.js-Entwicklung, einer hochskalierbaren JavaScript-Serverplattform und JavaScript als Fullstack-Programmiersprache.
Unit Tests sind die Grundvoraussetzung für jede Shift-Left-Strategie: Ohne dieses feinmaschige Fallnetz auf Code-Ebene lässt sich keine ausreichende Abdeckung auf höheren Teststufen wirtschaftlich realisieren.Consumer Driven Contract Testing mit Tools wie PACT ermöglicht es, API-Kompatibilität zwischen Services bereits lokal gegen automatisch generierte Mocks zu prüfen, ohne eine vollständige Integrationsumgebung aufzubauen.Qualitätsfeedback direkt in der IDE, zum Beispiel zyklomatische Komplexität inline angezeigt, ist einem späteren Build-Server-Report überlegen, weil der Entwickler sofort reagiert, statt einen zusätzlichen Korrekturzyklus zu drehen.Teams, die jeden Entwickler eine eigene User Story alleine umsetzen lassen und die Tester erst am Sprintende einschalten, bauen einen Mini-Wasserfall im Sprint nach und riskieren, am Sprintende keine einzige Story vollständig fertigzustellen.Eine pauschale 100-Prozent-Unit-Test-Abdeckung als Ziel ist kontraproduktiv; sinnvoller ist es, kritische Geschäftslogik explizit zu annotieren und für genau diesen Code vollständige Abdeckung verbindlich einzufordern.Danke an die Community-Partner des Podcasts:Alliance for Qualification | ASQF | Austrian Testing Board | dpunkt.verlag | German Testing Board | German Testing Day | GI Fachgruppe TAV | Heise | HANSER Verlag | ISTQB | iSQI GmbH | oop | QS-TAG | SIGS-DATACOM | skillsclub | Swiss Testing Board | TACON Credits: Sound | Grafik