Zwischen Software und Hardware liegt die Stärke: Testautomatisierung bei DS Automotion durch die Augen von Lukas Fiel

Ein DevJobs.at-Recap: „Lukas Fiel, Test Automation Engineer bei DS Automotion“

In der Session „Lukas Fiel, Test Automation Engineer bei DS Automotion“ von DS Automotion GmbH zeichnet sich ein klares Leitmotiv ab: die Kraft der Schnittstelle. Lukas Fiel beschreibt seinen Weg in die Testautomatisierung nicht als geradlinige Karriere vom Studienbeginn bis zum Senior-Titel, sondern als bewusste Entscheidung, die eigenen Stärken dort einzusetzen, wo Software auf Hardware trifft und wo das große Ganze oft wichtiger ist als einzelne Codezeilen.

Wir haben zugehört, wie er seinen Werdegang skizziert, sein Verständnis von testgetriebener Qualität teilt und erklärt, weshalb er die radikale Automatisierung bei DS Automotion als außergewöhnlich erlebt. Vor allem aber bleibt eines hängen: Testen ist ein Handwerk und eine Haltung. Es verlangt Neugier, Ausdauer und den Mut, die Dinge auszusprechen, die Projekte voranbringen – auch dann, wenn sie unbequem sind.

Vom maschinennahen Umfeld zur Software: ein Weg, der über Stärken führt

Lukas beginnt mit einem Bild, das vielen Quereinsteigerinnen und Quereinsteigern vertraut vorkommen dürfte: Er startete in einem maschinennahen Umfeld und brachte, wie er offen sagt, „ewig ein Bachelor“. Aus privaten technischen Projekten heraus entsteht dann eine Erkenntnis, die heute zur Grundbildung jeder Ingenieurslaufbahn gehört:

Dieser Satz ist mehr als eine Feststellung – er ist eine Weichenstellung. Statt sich zu fragen, wie er mit klassischen Informatiklaufbahnen mithalten soll, stellt er die entscheidende Frage: Wo liegt seine Stärke?

Diese Standortbestimmung führt ihn in den Test. Nicht, weil Testen „weniger“ Programmierung wäre, sondern weil es ein Feld ist, in dem Systemsicht, Prozessverständnis und die Fähigkeit, Anforderungen in überprüfbare Qualität zu übersetzen, den Ausschlag geben. Oder wie es Lukas zusammenfasst: Im Test ist es oft relevanter, das große Ganze zu sehen, als „die kleinen Feinheiten in der Programmierung“ bis ins letzte Zeichen auszureizen.

Warum Test? Weil Systemsicht zählt

Lukas’ Begründung für seine Rolle im Test klingt pragmatisch und zugleich sehr bewusst: Im Test geht es darum, die Gesamtheit eines Systems zu verstehen – die Funktionskette vom Requirement über die Umsetzung bis zum Verhalten in der Realität. Diese Art von Arbeit belohnt Menschen, die Spuren aufnehmen, die Ursachen hinter Fehlern freilegen und die Kanten zwischen Software und Hardware lesen können. Genau hier sieht er seinen Beitrag.

Was uns auffällt: Er vergleicht sich nicht mit „den Programmierkollegen“, die „das seit 12 Jahren machen“. Stattdessen baut er dort auf, wo er einzigartig ist. Dieser Perspektivwechsel – weg vom Defizitvergleich, hin zur Stärkenorientierung – zieht sich als Leitmotiv durch seine Geschichte und liefert eine Blaupause für alle, die sich innerhalb der Tech-Welt neu positionieren wollen.

Alltag bei DS Automotion GmbH: Pflichtenhefte, Anforderungen und Testfokus

Wie übersetzt sich diese Systemsicht in den Arbeitsalltag? Lukas beschreibt es so:

Das ist ein kompaktes Prozessbild:

• Pflichtenhefte als Ausgangspunkt der Qualität: Sie bündeln das, was die Anforderungen – hier durch „Requirements Agents“ – als verbindlich definieren.
• Herausarbeiten, was dem Kunden wirklich wichtig ist: Nicht alles hat die gleiche Priorität. Tests werden dort am wertvollsten, wo sie Kundennutzen, Risiken und kritische Pfade widerspiegeln.
• Den Testfokus „lehnen“: Ein schönes Wortbild für das Ausrichten von Testenergie auf das, was zählt. Es geht um bewusstes Priorisieren statt gleichmäßiger Verteilung.

In dieser kurzen Passage steckt viel von dem, was moderne Teststrategien prägt: Testen ist kein bloßer Abgleich gegen Soll-Listen. Es ist das bewusste Modellieren von Risiko, Wert und Verhalten – und das konsequente Übersetzen dieses Modells in automatisierte Prüfungen.

„Wir greifen nichts mehr an“: Radikale Testautomatisierung als Prinzip

Der Satz, der uns am stärksten hängen bleibt, ist dieser:

Auch wenn das Transkript an der Stelle holpert, die Aussage ist klar: Tests sollen reproduzierbar, wiederholbar und möglichst ohne manuelle Eingriffe durchführbar sein. Für Lukas ist diese Konsequenz etwas Besonderes – „so extrem“ hat er es bisher nicht erlebt – und die Vorteile liegen für ihn auf der Hand.

Was leitet sich daraus ab?

• Wiederholbarkeit erzeugt Vertrauen: Ein Test, der gestern grün war, sollte heute und morgen unter gleichen Bedingungen dasselbe Ergebnis liefern. Das macht Fortschritt messbar und Regressionen sichtbar.
• Automatisierung skaliert Erkenntnis: Anstatt Menschen die gleiche Prüfroutine immer wieder manuell ausführen zu lassen, wird Wissen im Testcode konserviert – und beliebig oft abrufbar gemacht.
• Hands-off verhindert Verfälschung: „Wir greifen nichts mehr an“ ist mehr als Bequemlichkeit. Es ist ein Bekenntnis zur Stabilität der Testumgebung und zur Unbestechlichkeit der Ergebnisse.

Gerade für Systeme, in denen Software auf Hardware trifft, ist das eine hohe Messlatte. Denn jeder manuelle Handgriff kann die Ausgangsbedingungen verändern. Der Ansatz, alles „runterzuprogrammieren“, setzt auf Reproduzierbarkeit und klare Schnittstellen.

Das Mindset: Liebe zum Debuggen, Mut zum Widerspruch

Technik allein reicht nicht. Lukas beschreibt sehr transparent, welche Haltung es im Test braucht:

Diese „Liebe“ ist Neugier, Beharrlichkeit und Freude am Erforschen. Sie macht den Unterschied zwischen Fehlerbehebung und Ursachenanalyse. Und sie führt direkt zum zweiten Baustein:

Testen heißt, dem Produkt einen Spiegel vorzuhalten. Das verlangt Zugriff auf Fakten, aber auch das Standing, sie auszusprechen. Wichtig ist dabei der konstruktive Kern: Die Aussage „So funktioniert es halt dann trotzdem nicht“ ist keine Wertung von Personen, sondern eine Beobachtung zum Verhalten des Systems. Und genau diese Klarheit setzt Energie für die nächste Iteration frei:

So sieht gelebte Qualität aus: messen, widerspiegeln, entscheiden, nachbessern – und wiederholen.

Aus der Praxis abgeleitet: Prinzipien für testzentrierte Entwicklung

Die Aussagen von Lukas verdichten sich zu einigen klaren Prinzipien, die wir aus der Session mitnehmen. Sie sind bewusst generisch formuliert – genau in dieser Allgemeinheit liegt ihre praktische Stärke.

1) Stärke an der Schnittstelle nutzen

• Wer Systemgrenzen versteht, erkennt Fehlerbilder früher. Gerade dort entstehen unerwartete Zustände.
• Tests sollten Schnittstellen bewusst provozieren: Übergaben, Timing, Abhängigkeiten – dort sitzt das Risiko.

2) Anforderungen als Steuer: Pflichtenhefte ernst nehmen

• Was in Pflichtenheften steht, ist die Brücke zum Kundenwert. Tests prüfen nicht „irgendwas“, sondern die versprochene Funktionalität.
• Der Testfokus „lehnt sich“ an das, was dem Kunden wichtig ist. Das ist gelebte Priorisierung.

3) Maximale Reproduzierbarkeit: „Wir greifen nichts mehr an“

• Eliminieren von manuellen Schritten reduziert Varianz und Beschönigung.
• Wenn Tests heute und morgen unter gleichen Bedingungen laufen, wird Qualität messbar, nicht gefühlt.

4) Liebe zum Fehler statt Angst davor

• Fehler sind Informationsquellen. Wer sie gern untersucht, wird produktiver – und baut robustere Systeme.
• Ursache statt Symptom: Erst verstehen, dann fixen.

5) Mut zum Klartext

• Testen erzeugt Evidenz. Sie auszusprechen, ist Pflicht – auch gegenüber Hierarchie und Erwartungsdruck.
• Es geht nicht ums Recht haben, sondern ums Richtigmachen: Klarheit schafft Fortschritt.

Den Testfokus aus Anforderungen ableiten: Ein kurzer Leitfaden

Was heißt es konkret, den Testfokus „in die Richtung zu lehnen“, die dem Kunden wichtig ist? Aus Lukas’ Beschreibung lässt sich ein einfacher Ablauf ableiten:

• Pflichtenheft lesen wie ein Risikodokument: Wo sind Muss-Kriterien? Wo sind Akzeptanzkriterien? Welche Teile sind kritisch für Betrieb und Sicherheit? Welche Szenarien sind „Happy Path“, welche „Edge Cases“?
• Funktionen in Verhalten übersetzen: Was soll das System in einer konkreten Situation tun? Welche Eingaben treffen auf welche Zustände? Wie sieht „erfolgreich“ aus?
• Automatisierbare Prüfbarkeit herstellen: Wenn „wir nichts mehr angreifen“, müssen Systeme fernsteuerbar, messbar und auswertbar sein. Das Denken in Schnittstellen ist hier entscheidend.
• Regression bewusst machen: Jede automatisierte Prüfung ist ein Stück konserviertes Wissen. Es gehört in die tägliche Routine, damit jede Änderung gegen dieses Wissen geprüft wird.
• Ergebnisse kommunizieren: Klare, nachvollziehbare Resultate sind der Hebel für Entscheidungen. Sprache und Visualisierung sollten das Verhalten des Systems zeigen, nicht nur Zahlenkolonnen.

Dieser Leitfaden ist unscheinbar – und genau deshalb robust. Er lässt sich auf viele Kontexte übertragen, ohne mehr zu versprechen, als in den Aussagen der Session angelegt ist.

Quereinstieg und Rollenbewusstsein: Was Lukas’ Weg lehrt

Lukas macht etwas, das wir im Engineering oft zu selten sehen: Er verzichtet auf Vergleichswettbewerbe und setzt stattdessen auf komplementäre Stärken. Die wichtigsten Beobachtungen dazu:

• Nicht alles ist Code – und dennoch ist alles Software: Wer Systeme versteht, muss nicht der tiefste Spezialist in einer einzelnen Sprache sein, um großen Wert zu liefern.
• Spezialisierung an der Schnittstelle ist eine Stärke: Gerade im Test, wo Verhalten zählt und Hard- und Software interagieren, ist diese Kombination schwer zu ersetzen.
• Tempo ist relativ, Richtung ist entscheidend: „Ewig ein Bachelor“ ist in seiner Erzählung kein Makel, sondern Teil eines Weges, der zur richtigen Position geführt hat.

Für viele, die ihren Weg in die Software suchen, ist das eine Einladung, sich zu fragen: Wo ist meine Schnittstelle, an der ich unverwechselbar Wert stifte?

Teamdynamik: Test als Partner der Entwicklung

Wenn Lukas vom Mut spricht, „dagegen zu reden“, hören wir nicht Konfrontation – wir hören Verantwortung. Testen bedeutet, unbestechliche Rückmeldung zu geben. Damit daraus Zusammenarbeit wird, helfen ein paar Grundsätze, die sich an seinen Aussagen orientieren:

• Ergebnisse sind Beobachtungen, keine Urteile: „So funktioniert es halt dann trotzdem nicht“ bezieht sich auf das Systemverhalten, nicht auf Personen.
• Evidenz statt Meinung: Wer reproduzierbare Tests hat, bringt Fakten in die Diskussion. Das entlastet Debatten – und beschleunigt Entscheidungen.
• Iteration als Normalfall: „Dann fängt das ganze Spiel wieder von vorne an“ ist kein Rückschritt. Es ist der Puls eines lebenden Systems.

So entsteht eine Kultur, in der Test und Entwicklung keine Gegenpole sind, sondern zwei Blickrichtungen auf denselben Gegenstand.

Radikale Automatisierung im Alltag: Chancen und Anforderungen

Der Anspruch „wir greifen nichts mehr an“ setzt Teams unter Strom – im positiven Sinn. Er verlangt:

• Klar definierte Schnittstellen für Steuerung und Beobachtung der Systeme.
• Stabilität in Umgebungen, damit Testläufe vergleichbar bleiben.
• Die Disziplin, manuelle Shortcuts zu vermeiden – insbesondere unter Zeitdruck.

Die Chancen sind groß: Wer Tests beliebig oft wiederholen kann, verbessert Feedbackzyklen, erkennt Seiteneffekte früher und verschiebt den Schwerpunkt der Arbeit von „Bugreactiv“ zu „Qualitätsproaktiv“. In Kombination mit einer Anforderungsorientierung nach Pflichtenheft entsteht ein Qualitätsfluss vom Requirement bis zum Ergebnis.

Fehlerfreundlichkeit: Vom Finden zum Verstehen

Lukas spricht explizit von der „Liebe“, sich in nicht funktionierende Dinge einzugraben. Diese Wortwahl setzt einen Akzent: Es geht nicht nur ums Finden, sondern ums Verstehen. In der Praxis heißt das:

• Reproduktion: Den Fehler so eingrenzen, dass er zuverlässig nachstellbar ist.
• Hypothesenbildung: Mögliche Ursachen skizzieren, ohne sich vorschnell festzulegen.
• Evidenz sammeln: Welche Beobachtungen stützen oder widerlegen welche Hypothese?
• Klarer Report: Was wurde beobachtet, unter welchen Bedingungen, mit welchem erwarteten vs. tatsächlichen Verhalten?

Dieses Vorgehen macht den Unterschied zwischen „Fehler erledigt“ und „Fehler verstanden“. Und eben dieses Verstehen ist die Grundlage für robuste Korrekturen.

Kommunikation als Werkzeug des Testers

Die stärksten Sätze von Lukas drehen sich um Sprache: Klar sagen, dass etwas nicht funktioniert – und trotzdem auf Augenhöhe bleiben. Testarbeit ist Kommunikationsarbeit:

• Übersetzen, was im Pflichtenheft steht, in überprüfbares Verhalten.
• Vermitteln, was ein Test wirklich gemessen hat – und was nicht.
• Verhandeln, welche Risiken adressiert werden müssen und welche später folgen.

Gerade deshalb ist die Kombination aus Systemsicht, reproduzierbaren Tests und Klartext so wirksam: Sie macht Diskussionen ehrlich und ergebnisorientiert.

Was wir von „Lukas Fiel, Test Automation Engineer bei DS Automotion“ mitnehmen

Aus wenigen, prägnanten Aussagen entsteht ein stimmiges Bild:

• Testautomatisierung ist kein Selbstzweck. Sie ist der konsequente Weg, um Anforderungen zuverlässig zu prüfen und Wissen zu konservieren.
• Systemsicht ist eine Kernkompetenz. Wer Schnittstellen verstehen will, braucht technische Breite und Prozessbewusstsein.
• Mut und Neugier sind keine Soft Skills am Rand, sondern harte Anforderungen an die Rolle. Ohne sie bleibt Qualität beliebig.

Vor allem aber bleibt ein Gedanke: Stärke entsteht an der Schnittstelle. Dort, wo sich Software und Hardware treffen, wo Pflichtenhefte auf Realität stoßen und wo Menschen mit Fakten, Klarheit und Disziplin Verbesserungen auslösen.

Praktische Impulse für deinen Alltag

Abschließend verdichten wir Lukas’ Kerngedanken in umsetzbare Anstöße:

• Richte deinen Testfokus an den Funktionen aus, die dem Kunden wirklich wichtig sind. Nimm Pflichtenhefte als Steuerinstrument.
• Automatisiere so, dass du Tests beliebig wiederholen kannst – heute, morgen, jederzeit. Eliminiere manuelle Schritte, wo immer möglich.
• Trainiere deine Systemsicht: Verstehe, wie Komponenten zusammenspielen und wo Schnittstellen brechen können.
• Kultiviere die „Liebe zum Debuggen“: Baue Routinen auf, die vom Reproduzieren über Hypothesenbildung bis zum klaren Report reichen.
• Hab den Mut, Evidenz klar auszusprechen. Es geht nicht um Fleißpunkte, sondern um Funktionalität.

Wer diesen Kompass befolgt, wird nicht nur bessere Tests schreiben. Er oder sie wird – so wie Lukas es vorlebt – eine Rolle spielen, die Entwicklung und Betrieb messbar stabiler macht.

Schlussbild: Qualität als wiederholbarer Beweis

„Wir greifen nichts mehr an, wir programmieren das runter“ – dieser Satz steht exemplarisch für die Haltung, die Lukas Fiel bei DS Automotion GmbH beschreibt. Er ist Anspruch und Arbeitsmethode zugleich. Qualität zeigt sich darin, dass ein Test, der gestern funktioniert hat, heute und morgen wieder verlässlich funktioniert – oder klar signalisiert, wo das System abweicht. In dieser Wiederholbarkeit liegt der Wert der Testautomatisierung: Sie macht Qualität zu einem wiederholbaren Beweis, nicht zu einer Vermutung.

Und genau das ist die Stärke an der Schnittstelle.

• 

  

  Kevin Greßlehner, IT Techniker bei DS Automotion

  Kevin Greßlehner von DS Automotion spricht im Interview über seinen ursprünglichen Zugang zur IT Technik und gibt einen Überblick über seinen Job im Unternehmen sowie Tipps für Anfänger.

  Jetzt ansehen
• 

  

  Klemens Pleiner, Basis Software Developer bei DS Automotion

  Klemens Pleiner von DS Automotion gibt im Interview Einblicke in seinen Weg als Developer, das Besondere an seiner aktuellen Arbeit im Unternehmen und was seiner Meinung nach wichtig für Neueinsteiger ist.

  Jetzt ansehen
• 

  

  Gerald Hahn, Requirements Engineer bei DS Automotion

  Gerald Hahn von DS Automotion berichtet im Interview über das Requirements Engineering: wie er in die Branche eingestiegen ist und was er Anfängern raten würde.

  Jetzt ansehen