FrankSazamaDie Idee zu diesem Vortrag kam mir aus einer scheinbar einfachen Entwicklerfrage:
👉 „Darf ich weitermachen – oder muss ich mich erst um die Qualität kümmern?“
Eine alltägliche Frage.
Aber dahinter steckt viel mehr: ein System. Eine Haltung. Eine Verantwortung.
Denn Qualität ist keine Phase – sie ist ein kontinuierlicher Begleiter. Und sie braucht eins: Feedback.
Qualität beginnt mit einer Frage – und endet nicht beim Test
In der agilen Entwicklung – besonders in der Embedded-Software für Automotive – entscheiden Entwickler:innen tagtäglich, wie sie mit Code, Tests und Anforderungen umgehen.
Aber wie sollen sie entscheiden, ohne zu wissen, ob das, was sie bauen, überhaupt funktioniert?
Wie sollen sie Verantwortung übernehmen, wenn das Feedback 4 Wochen später vom Testteam kommt?
Genau das ist das Problem traditioneller Silostrukturen:
🔁 Lange Zyklen, große Chunks, spät erkannte Fehler, hohe Kosten.
Die Lösung?
Kontinuierliche Integration & automatisiertes Testen.
Was CI und Test wirklich leisten – wenn sie richtig gedacht sind
Ich spreche nicht über Tools – sondern über Prinzipien.
👉 Kleine, tägliche Inkremente
👉 Feedback in Minuten statt Wochen
👉 Gemeinsames Repository – nicht nur für Code, sondern für Anforderungen, Architektur, Design
Automatisiertes Testen ist kein Add-on. Es ist die Rückmeldung, ob du auf dem richtigen Weg bist.
Und Rückmeldung schafft Verantwortung.
Die Person, die das Problem verursacht, ist verantwortlich für die Behebung – aber sie ist nicht allein.
Ein gutes CI-System unterstützt, visualisiert und fördert Zusammenarbeit.
Von der V-Kurve zum Feedback-Kreislauf
In der klassischen V-Kurve dauert das Testen so lange wie das Entwickeln – oft sogar länger.
Im CI-Paradigma verändern wir zwei Dinge:
- Wir verkleinern die Pakete.
→ Weniger Komplexität pro Inkrement - Wir ändern den Winkel der Testzeit.
→ Automatisiertes Testen reduziert die Feedbackzeit dramatisch
Das Ziel: Feedback in 5–15 Minuten – nicht in Tagen.
So entsteht ein Entwicklungsrhythmus mit Qualität im Zentrum.
Organisation schlägt Tool – Die wahren Voraussetzungen
CI & Test funktionieren nicht „einfach so“.
Sie brauchen:
- Klare Zuständigkeiten im Team
- Entwicklung und Test in einem Team – nicht in zwei Abteilungen
- Transparenz über Abhängigkeiten (→ z. B. durch PI-Planning)
- Ein gemeinsames Verständnis für „Done“
Das bedeutet:
Testfälle werden parallel zur Entwicklung geschrieben – nicht vorher, nicht danach.
Und: Jeder Commit muss getestet sein – mit Unit-, Integrations- und Regressionstests.
Feedback ist Systemleistung – nicht individuelle Leistung
Der Schlüssel liegt in der Zusammenarbeit:
📍 Wer arbeitet gleichzeitig an welcher Funktion?
📍 Wer könnte wessen Tests beeinflussen?
📍 Welche Module hängen voneinander ab?
Das ist nicht nur Planung. Das ist Führungsverantwortung durch Architektur & Transparenz.
Ein guter CI-Flow ist ein Spiegel der Teamorganisation – nicht nur der Testautomatisierung.
Fazit: Continuous Integration ist mehr als ein Tool – es ist eine Haltung
Wer CI und automatisiertes Testen richtig versteht, erkennt:
💡 Es geht nicht um Technik.
Es geht um Verantwortung, Zusammenarbeit, Vertrauen – und um gute Entscheidungen.
Jeder Commit ist ein Versprechen.
Jeder Test ein Feedback.
Und jeder grüne Kreis ein Zeichen dafür, dass wir auf dem richtigen Weg sind.