Qualität in Startups entsteht nicht durch formale Testprozesse, sondern zunächst durch kundenahe Beobachtung: Gründer und Product Owner testen früh aus der Nutzerperspektive. Mit wachsender Teamgröße braucht es dann eine dedizierte Tester-Rolle, die als aktiver Teil des Entwicklungsprozesses agiert, nicht als abschließendes Quality Gate.
Das Wichtigste in Kürze
- Testen ist kein Selbstzweck: Wer niemanden im Unternehmen hat, dem die Produktqualität schlaflose Nächte bereitet, wird auch kein wirksames Testing etablieren können.
- Generierter Code aus KI-Werkzeugen enthält im Schnitt mehr Fehler und verhältnismäßig mehr kritische Fehler als manuell geschriebener Code, was den Bedarf an professionellem Softwaretesting erhöht, nicht senkt.
- Startups, die den Sprung vom Pflänzchen zum skalierbaren Unternehmen schaffen, haben das Thema Softwarequalität früh verstanden, während reine Nonchalance gegenüber Qualität nur in seltenen Fällen und über kurze Zeiträume überlebt.
- Technical Debt funktioniert wie Steuern: Wer früh nicht in Testbarkeit und Codequalität investiert, zahlt später einen weit höheren Preis, wenn die Komplexität wächst.
- Agile Tester sind dann am wirksamsten, wenn sie als gleichberechtigter Teil des Entwicklungsteams agieren und nicht als reines Quality Gate, durch das am Ende alles durchgepresst wird.
Testing in Startups beginnt nicht mit Prozessen, sondern mit Testbarkeit
Qualität entsteht in jungen Unternehmen nicht durch ein fertiges Testframework, sondern durch eine bewusste Entscheidung in der Konzeption. Wer ein neues Softwaresystem aufsetzt, kann Testbarkeit von Anfang an mitdenken, ähnlich wie Security. Ob danach automatisiert oder manuell getestet wird, ist eine Frage der Kapazität und am Anfang oft zweitrangig.
Wichtig ist die Grundhaltung dahinter. Wenn ein System so gebaut wird, dass es später testfähig ist, bleibt der Aufwand beherrschbar, sobald die Komplexität steigt. Wird Testbarkeit dagegen ignoriert, wächst der Nachholbedarf mit jeder weiteren Zeile Code.
Daniel Krauss, Mitgründer von Flix, ordnet das so ein: Die Vorstellung, Testing spiele in Startups gar keine Rolle, lässt sich heute nicht mehr halten. Vor einigen Jahren mag das anders gewesen sein. Inzwischen wissen die meisten, dass Testen ein elementarer Bestandteil guter Softwareentwicklung ist.
Warum der Unterschied zwischen B2C und B2B mehr zählt als das Alter der Firma
Ob ein Unternehmen jung oder etabliert ist, sagt weniger über sein Testverhalten aus als die Frage, für wen es baut. Klassische Enterprise-Software prägte über Jahrzehnte die Strukturen, die viele heute mit Testing verbinden. B2C-Produkte funktionieren anders.
Bei einer App im App Store entscheidet die Qualität schnell darüber, ob das Produkt angenommen wird oder scheitert. Das Feedback kommt unmittelbar. Diese Nähe zwingt zu einem anderen Umgang mit Fehlern als in einer Lieferkette, in der das fertige Produkt mehrere Schritte entfernt ist.
Daniel beschreibt diesen Kontrast aus eigener Erfahrung. In der Automotive-Zulieferindustrie liegt das fertige Fahrzeug drei Schritte weiter weg. Dort braucht es Mühe, um die Metriken einzelner Komponenten so mit dem Endprodukt zu verbinden, dass am Ende der Kunde zufrieden ist. Im B2C-Startup ist diese Brücke deutlich kürzer.
Testen ist kein Selbstzweck und sollte nie eins werden
Testen ohne Qualitätsbewusstsein funktioniert nicht. Wer ein Feigenblatt sucht oder testet, weil man das eben so macht, verfehlt das Ziel. Das Ziel lautet, die Qualität eines Produkts zu bewerten und über einen guten Entwicklungsprozess auch zu erhöhen.
Florian Fieber, Vorstand des German Testing Board, bringt dafür eine einfache Probe ins Spiel:
Ich frage erst mal, wer von euch kann denn nicht schlafen, wenn das Produkt nicht funktioniert? Wenn sich da keiner meldet, dann ist doch eigentlich alles in Ordnung. Dann haben wir ja gar kein Problem. Florian Fieber
Ohne jemanden, der ein echtes Interesse an der Produktqualität hat, lässt sich sinnvolles Testen kaum etablieren. In diesem Punkt unterscheidet sich ein Startup nicht von einem großen Unternehmen. Entscheidend ist, wie wichtig dem Team Qualität tatsächlich ist.
Metriken sagen nichts, wenn das Ziel fehlt
Eine Testabdeckung von null Prozent bedeutet, dass funktionierende Software Glück und Zufall ist. Hundert Prozent zu erreichen muss trotzdem keinen Sinn ergeben. Test Coverage ist selbst kein Selbstzweck, sondern ein Hilfswert. Die eigentliche Frage bleibt, was du damit erreichen willst.
Klassische Kennzahlen wie Lines of Code beim Programmieren oder Test Coverage beim Testen sind nicht wertlos. Sie zeigen Extreme. Aber sie allein zu messen, führt in die Irre. Je nach Kontext kann eine ganz andere Zahl die richtige sein.
Startups arbeiten hier oft mit Metriken, die stärker am Kundenfeedback ausgerichtet sind als an formaler Abdeckung. Eine formaler organisierte, dokumentenlastige Branche wie die Zulieferindustrie wird Testfälle zählen und Coverage messen. Eine auf Geschwindigkeit und Lernen ausgelegte Organisation misst eher, was beim Kunden ankommt.
Wie Testkultur bei Flix aus der Kundenperspektive gewachsen ist
Bei Flix entstand die Testdisziplin nicht aus der technischen Ecke, sondern aus dem Blick des Kunden. In der Anfangszeit testeten die Gründer selbst, später die Product Owner im agilen Kontext. Sie luden die App herunter, klickten durch und meldeten zurück, was nicht funktionierte.
Die rein technischen Aufgaben blieben beim Engineering. Die Genese zur dedizierten Rolle des Agile Testers war dagegen stärker von der Kundensicht geprägt als von der Idee, einen Testfall gegen ein Stück Software zu schreiben.
Aus der früheren lapidaren E-Mail ist ein geregelter Prozess geworden, über den Feedback zurückfließt. Diese Professionalisierung gilt nicht für jede Drei-Personen-Bude, lässt sich aber schon bei Unternehmen mit 30, 40 oder 50 Leuten gut beobachten. Der Antrieb dahinter ist die Erkenntnis, dass man mit einem schlechten Release sehr schnell weg vom Fenster sein kann.
Lernen durch Schmerzen funktioniert im Startup anders als im Konzern
Im kleinen Unternehmen können Qualitätsprobleme schnell lebensbedrohlich werden, weil das Produkt noch ein Pflänzchen ist. Gleichzeitig lassen sie sich oft schnell beheben, weil die Abhängigkeiten gering sind. Die Tiefe des Schmerzes bleibt damit begrenzt.
Formale Prozesse haben ihren Grund dort, wo Fehler teuer und schwer reversibel sind. Wer im Automotive-Umfeld 100.000 Autos zurückrufen muss, hat ein echtes Problem. Beide Welten haben ihre Berechtigung, abhängig davon, was ein Fehler kostet.
Florian dreht das verbreitete Bild von der Schildkröte um, die es ins Meer schafft. Statt zu sagen, die Überlebenden hätten Qualität verstanden, lässt sich genauso argumentieren: Wer Qualität richtig angeht, schafft es überhaupt erst ins Meer.
Der Tester braucht eine Stimme, weil er in der Unterzahl ist
Testen muss mit Rollen verankert werden, sonst hängt es am guten Willen Einzelner. Ein Entwickler im Flow denkt beim Erschaffen nicht automatisch daran, wie sich gleichbleibende Qualität sicherstellen lässt. Dafür braucht es Menschen, die an neuralgischen Punkten draufschauen.
Diese Rolle verlangt Haltung. In den meisten Teams gibt es mehr Entwickler als Tester. Wer testet, ist damit in der Unterzahl und muss bereit sein, die Stimme zu erheben, auch gegenüber dem Management.
Bei Flix prägte eine frühe Cheftesterin und Principal Engineer diese Rolle. Sie trieb das Thema voran und nahm gegenüber dem Management kein Blatt vor den Mund. Tester als Entwickler zweiter Klasse zu behandeln, ist in dieser Lesart überholt. Es geht um unterschiedliche Stärken, nicht um Rangordnung.
Vom Startup zum erwachsenen Unternehmen: wenn Disziplinen dazukommen
Viele Startups wachsen wie eine Zwiebel um ein starkes Entwicklungsteam herum. Oft ist ein Gründer selbst Entwickler. Bis zu einem gewissen Punkt trägt dieser Fokus. Dann stößt er an Grenzen.
Mit der Größe kommen weitere Disziplinen ins Spiel, die vorher unterschätzt wurden:
- Architektur als eigene Aufgabe neben der reinen Implementierung
- Anforderungsmanagement
- Testen als eigener Kompetenzbereich
- Projektmanagement und unterstützende organisatorische Prozesse
Daran entscheidet sich, ob ein Startup das Erwachsenwerden schafft. Solange das Team klein ist, kann ein Gründer mittesten. Wächst die Organisation, braucht es einen systematischen, professionellen Ansatz als eigene Disziplin. Beides ist komplementär, nicht alternativ.
Veränderung ist nicht der Schmerz, der Verlust des Kundenfokus ist es
Wachstum an sich erzeugt keine Schmerzen. Wer Veränderung als Fluss begreift, erlebt sie als Bewegung nach vorn, nicht als Last. Unbehagen entsteht meist erst dann, wenn Menschen jede Veränderung reflexhaft in die Schmerzecke stellen.
Schmerzhaft wird es an einer anderen Stelle. Wenn der Fokus auf den Kunden verloren geht und stattdessen Prozess auf Prozess auf Prozess gestapelt wird, halten Selbstzwecke Einzug. Das Ergebnis ist dann tatsächlich unangenehm.
Dagegen hilft eine einfache Frage, die jeder im Team stellen darf: Warum machen wir das eigentlich? Auch hier ist es Aufgabe der Tester, regelmäßig die Hand zu heben und Unsinn zu benennen. Kultur, bewusst gesetzt, nimmt dabei die ganze Mannschaft mit.
Was die Rolle des Agile Testers bei Flix bedeutet
Der Agile Tester ist Mitspieler im Entwicklungsteam, nicht Torhüter an einem Quality Gate. Der Name entstand aus dem Team selbst und drückt aus, dass diese Rolle ein elementarer Teil des Entwicklungsprozesses ist und sich anpassen kann.
Agil meint hier nicht Beliebigkeit. Es bedeutet, auf sich ändernde Requirements reagieren zu können und trotzdem ein gesetztes Ergebnis zu liefern. Der Tester ist Bestandteil des Teams, nicht die Tür, durch die sich am Ende alle pressen müssen.
In der verteilten Architektur von Flix sind die Entwicklungsteams typischerweise sechs bis acht, manchmal bis zu zehn Personen groß. Ein solches Team besteht aus einem Product Owner, einem Agile Tester und verschiedenen Entwicklerprofilen, von klassischen Entwicklern über Data- und AI-Themen bis zu DevOps. Die enge Abstimmung mit dem Product Owner gehört zum Kern der Rolle.
Methodisches Fundament bleibt, die Werkzeuge wechseln
Die Werkzeuge von gestern passen heute nicht mehr, die Methoden und Strategien schon. Genau das macht eine methodisch ausgerichtete Ausbildung wertvoll. Der Certified Tester fokussiert auf Grundlagen, Grundsätze und den Testprozess, agnostisch gegenüber Entwicklungsmethode, Vorgehensweise oder Unternehmensgröße.
Diese Grundideen lassen sich überall anlegen. Wie früh getestet werden soll, ist keine neue Erkenntnis. Heute heißt das Shift Left, gemeint ist eine Idee, die das Testen seit Jahrzehnten begleitet. Die Ausprägung unterscheidet sich nach Technologie, Werkzeug und Produkt, der Grundgedanke bleibt stabil.
Bei Flix wird Weiterbildung über Eigenverantwortung getragen. Teamspezifische Themen entscheidet das Team selbst. Übergreifende Fragen, die alle Agile Tester betreffen, werden gemeinsam besprochen. Am Puls der Zeit zu bleiben ist nötig, weil ein wachsender Teil der Welt aus Software besteht und damit immer mehr zu testen ist, das es vor Jahren noch nicht gab.
Vibe Coding gehört ins Prototyping, nicht in die Enterprise-Architektur
KI-gestützte Werkzeuge erhöhen die Produktivität, Vibe Coding ist davon zu trennen. Bei Flix arbeiten Entwickler mit Tools wie Claude Code, um Unzulänglichkeiten der Entwicklung KI-unterstützt abzufedern. Das ist sinnvoll. Etwas Hingewipetes ungeprüft in eine Enterprise-Architektur live zu nehmen, ist es nicht.
Daniel zieht die Parallele zu früheren Werkzeugen wie Dreamweaver, mit denen sich viel Code erzeugen ließ, dessen Ergebnis aber schlecht war. Mehr produzieren zu können macht das Ergebnis nicht automatisch besser. Im Gegenteil verschiebt es Arbeit zu denen, die solche Werkzeuge sinnvoll einsetzen müssen.
Für Rapid Prototyping und Requirements Engineering ist der Nutzen real. Product Owner können schnellere und bessere Prototypen bauen, auch ohne tiefe technische Kenntnisse. Das reduziert das Hin und Her darüber, was eigentlich gewünscht ist. Für Produktionscode in einem komplexeren Produkt bleibt die Skepsis. Sich reinzuschmeißen und auszuloten, was geht, ist trotzdem die richtige Haltung. Ablehnung wäre der Fehler.
Software ist mehr als Code, und genau deshalb steigt der Testbedarf
Der verbreitete Fehler ist die entwicklerzentrierte Sicht, die Software auf das Schreiben von Code reduziert. Software ist ein Produkt aus technischen Komponenten und Menschen. Sie zu bauen verlangt mehr, als schnell Code zu generieren.
KI-basierte Werkzeuge nehmen erhebliche Geschwindigkeit auf, das ist nicht Vibe Coding, sondern ihr ernsthafter Einsatz in der Entwicklung. Für Routineaufgaben und schnelle Lösungen lässt sich ein Großteil der Arbeit auffällig schnell erledigen.
Florian sieht darin keinen Grund zur Sorge für das Testen, sondern das Gegenteil. Generierter Code zeigt in vielen Beobachtungen mehr Fehler und relativ betrachtet mehr kritische Fehler als von Menschen geschriebener Code. Auf das Software-Testen rollt damit eine große Welle an zum Teil schlechtem Code zu. Volkswirtschaftlich ist das fragwürdig. Aus der Perspektive des Testens heißt es: Wer dachte, man brauche Tester nicht mehr, braucht sie umso mehr.
