Finding Strength at the Interface: Test Automation at DS Automotion through the lens of Lukas Fiel

A DevJobs.at recap of “Lukas Fiel, Test Automation Engineer bei DS Automotion”

In the session “Lukas Fiel, Test Automation Engineer bei DS Automotion” from DS Automotion GmbH, a clear theme emerges: the power of the interface. Lukas Fiel doesn’t present a linear CV from study to senior title. Instead, he describes a deliberate choice to lean into what he does best—where software meets hardware—and to embrace the kind of thinking where the big picture often matters more than a single line of code.

We listened as he sketched his path into test automation, explained how he reads requirements into actionable tests, and why the radical automation culture at DS Automotion stands out to him. Most of all, one message resonates: testing is both craft and mindset. It demands curiosity, persistence, and the courage to say what needs to be said—even when it’s uncomfortable.

From a machine-centric start to software: a strengths-led transition

Lukas opens with a familiar scene for many career shifters: he began in a machine-proximate environment and, in his own words, took a long time to finish the bachelor’s degree. Private technical projects eventually brought a realization that now underpins almost every engineering path: everything is tied to software.

He crystallizes it succinctly: he didn’t want to compare himself to people who had studied software for years. Instead, he asked a better question: where is his unique strength? He found it at the interface between software and hardware and in understanding general technical processes. That insight led him to testing—because in testing, seeing the whole system can be more critical than perfecting fine-grained programming details.

This shift is decisive. Lukas stops measuring himself against “pure” programming paths and chooses to double down on systems thinking. For anyone navigating their place in tech, that pivot—from deficit comparison to strengths orientation—offers a blueprint worth following.

Why testing? Because systems thinking wins

Lukas frames his role in testing in pragmatic, intentional terms. Testing is where the entire system—from requirement to implementation to observable behavior—comes into focus. It rewards people who can follow trails, uncover root causes, and read the seams between software and hardware. That’s where he contributes the most.

There’s a sober clarity to this view: in testing, value comes from modeling risk and behavior, then translating that model into checks that matter. It’s not about being “less technical.” It’s about orienting technical work around outcomes.

What the work looks like at DS Automotion GmbH: reading specs, aligning focus

Lukas explains the day-to-day in terms that anyone in delivery will recognize. He dives into a project by working through the Pflichtenheft—the specification provided by “Requirements Agents”—to determine what functionality the customer truly cares about. From there, he “leans” the test focus in that direction.

That short description contains a pragmatic, modern test strategy:

• Specifications as the starting point of quality: They encode what’s been promised and what needs to be verified.
• Centering tests on customer value: Not all features carry equal weight. Tests are most valuable when they follow value, risk, and critical paths.
• Aligning the test focus: Choose deliberately where to concentrate test energy, rather than spreading it thinly and evenly.

This is testing as translation: from formalized requirements to observable, automatable behavior.

“We don’t touch anything”: radical automation as a principle

One line stands out:

He describes a setup where they “don’t touch anything” and “program it down,” enabling a test that worked yesterday to be run again today and tomorrow. Even with the transcript fragmentary in places, the point is unmistakable: tests should be reproducible and executable without manual intervention. To Lukas, this consistency is distinctive—“so extreme” he hasn’t seen it elsewhere—and the benefits are obvious.

What follows from that principle?

• Repeatability builds trust: If a test passed yesterday, under the same conditions it should pass today and tomorrow. That makes progress measurable and regressions visible.
• Automation scales insight: Instead of rerunning the same checks by hand, the knowledge is captured in test code and can be exercised indefinitely.
• Hands-off prevents drift: “We don’t touch anything” isn’t about comfort. It’s a commitment to stable environments and unambiguous results.

In systems where software and hardware meet, that standard is particularly high. Every manual interaction can alter the baseline. The “program it down” approach aims to minimize variance and maximize reproducibility.

The tester’s mindset: love for the problem, courage to push back

Technology alone doesn’t make a testing culture. Lukas describes the human core of the role with precision. You need to love digging into things that don’t work and figuring out why they don’t work. That’s curiosity and stamina in action.

And then there’s courage: the willingness to speak up when a feature doesn’t behave as intended—even when it has been prioritized by project management and implemented by developers. Saying “it still doesn’t work” isn’t about assigning blame; it’s about aligning reality with the promise.

As he notes, that’s where the loop starts again. Measure, reflect, decide, fix, repeat. That’s not failure. That’s the heartbeat of quality.

Principles distilled from the session

From Lukas’ account, a set of clear, portable principles emerges. These are intentionally general because their strength lies in their simplicity and wide applicability:

1) Lean into the interface

• Understanding boundaries—between components, domains, and teams—uncovers failure modes early.
• Design tests to probe interfaces: handovers, timing, dependencies. That’s where risk lives.

2) Let requirements steer the test focus

• Treat the specification as the bridge to customer value. Tests don’t check “anything”—they verify what was promised.
• “Lean” the focus toward what matters most to the customer. That’s prioritization in action.

3) Maximize reproducibility: “We don’t touch anything”

• Remove manual steps to reduce variance and eliminate wishful thinking.
• If tests can run today, tomorrow, and any day under the same conditions, quality becomes evidence rather than opinion.

4) Love the failure

• Bugs are information sources. Enjoy investigating them and you’ll design sturdier systems.
• Understand root causes before implementing fixes.

5) Speak with evidence

• Testing produces evidence. Say what it shows—even against pressure or hierarchy.
• It’s not about being right; it’s about making the product right.

From requirement to test focus: a practical flow

Lukas’ process suggests a straightforward flow for turning specifications into tests that matter:

• Read the Pflichtenheft like a risk document: Identify must-have criteria and acceptance conditions. Highlight critical paths where business value or safety is at stake. Distinguish happy paths from edge conditions.
• Translate functions into behaviors: What should the system do in a concrete situation? Which inputs meet which states? What does “success” look like in observable terms?
• Ensure automatable observability: If you’re not “touching” the system, it must be controllable and measurable via interfaces. Think in terms of controllability and observability from the start.
• Make regression explicit: Every automated check is preserved knowledge. Put it on a cadence so changes are continually tested against what’s been learned.
• Communicate results clearly: Show what the system did under which conditions, versus what was expected. Clarity is a lever for decision-making.

None of this is flashy—and that’s exactly why it works in practice.

Lessons for career shifters and specialists alike

One of the strongest takeaways from Lukas’ story is his refusal to run a race he didn’t sign up for. He doesn’t measure himself against people who have spent a dozen years solely on programming. Instead, he builds where he’s unique: at the interface and in process understanding.

• Not everything is code—and yet everything is software: Systems skill sets can be immensely valuable without being the deepest specialist in any one language.
• Interface specialization is a strength: Especially in testing, where cross-domain behavior matters, that combination is hard to replace.
• Speed is relative; direction is decisive: Taking longer on a formal path can still lead to the right role if the strengths fit.

For anyone figuring out where to contribute most in tech, that’s an invitation to ask: where’s my interface—the place where my mix of skills creates outsized value?

Team dynamics: testing as a partner to delivery

When Lukas talks about the courage to push back, we don’t hear conflict—we hear responsibility. Testing means returning an unvarnished signal. To make that signal collaborative rather than confrontational, a few patterns help, all consistent with his account:

• Report observations, not judgments: “It still doesn’t work” refers to behavior, not people.
• Let evidence lead: Reproducible tests surface facts. Facts shorten debates and speed decisions.
• Treat iteration as normal: “The loop starts again” isn’t a setback—it’s how living systems evolve.

This is how testing and development become two complementary perspectives on the same system.

Radical automation in everyday work: demands and dividends

The “we don’t touch anything” ethos raises the bar in productive ways. It requires:

• Clearly defined interfaces for controlling and observing systems under test.
• Stable environments so runs are comparable over time.
• Discipline to avoid manual shortcuts, especially under pressure.

The payoff is substantial: when tests can run again and again, feedback cycles accelerate, side effects are caught earlier, and the center of gravity shifts from reactive bug-fixing to proactive quality. Combined with a requirements-first mindset, this creates a quality flow from specification to result.

Error-friendliness: from finding to understanding

Lukas explicitly talks about the “love” of digging into what doesn’t work. That emphasis reframes failure as fuel. Practically, it means:

• Reproduction: Narrow the conditions until the issue is consistently reproducible.
• Hypothesis work: Sketch plausible causes without prematurely locking in on one.
• Evidence gathering: Observe which traces support or refute each hypothesis.
• Clear reporting: Document expected vs. actual behavior under explicit conditions.

This progression is the difference between “the bug is gone” and “the bug is understood.” The latter yields robust fixes.

Communication as a core tool for testers

Again and again, language is central in Lukas’ account: say clearly when something doesn’t work—and keep it grounded. Testing is communication work as much as it is technical work:

• Translating specifications into verifiable behavior.
• Explaining what a test truly measured—and what it didn’t.
• Negotiating which risks must be addressed now and which can wait.

This is why systems thinking, reproducible tests, and plainspoken reporting are so powerful together: they make conversations honest and outcome-focused.

What we’re taking away from “Lukas Fiel, Test Automation Engineer bei DS Automotion”

A few concise points add up to a coherent practice:

• Test automation isn’t a trophy. It’s the most reliable way to verify requirements and preserve knowledge.
• Systems thinking is a core competence. Understanding interfaces and processes is decisive when software meets hardware.
• Curiosity and courage aren’t “nice-to-haves”; they’re part of the job definition. Without them, quality remains a matter of taste.

Above all, one idea sticks: strength lives at the interface—where software meets hardware, where specifications meet reality, and where people with evidence, clarity, and discipline trigger improvement.

Practical prompts for your own practice

Translating Lukas’ core points into day-to-day moves:

• Aim your tests at customer-critical functionality. Use the specification as your north star.
• Automate so you can run tests today, tomorrow, and any day—without touching the system. Remove manual steps wherever possible.
• Train your systems view: understand how components interact and where seams can rip.
• Cultivate a love for debugging: build routines from reproduction to hypothesis to clear reporting.
• Speak up with evidence. The goal isn’t to be right; it’s to make the product right.

Follow that compass and, like Lukas, you’ll contribute in ways that make development measurably more reliable.

Closing image: quality as repeatable proof

“We don’t touch anything; we program it down” captures the spirit Lukas describes at DS Automotion GmbH. It’s both a standard and a working method. Quality shows up when a test that worked yesterday works again today and tomorrow—or clearly signals where the system diverges. That repeatability is the value of test automation: it turns quality from a hunch into evidence.

And that’s the strength of the interface-driven mindset he embodies.

• 

  

  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.

  Watch now
• 

  

  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.

  Watch now
• 

  

  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.

  Watch now