From first PC to test automation: Luca Voit, QA Engineer bei evon, on edge cases, focus and staying power

Introduction: A devstory from the quality trenches

In the devstory “Title: Luca Voit, QA Engineer bei evon” (Speaker: Luca Voit, Company: evon GmbH), we hear a grounded account of how an early spark for computers can grow into a clear niche in software quality. Luca Voit describes how curiosity, deadline pressure, and a stubborn commitment to “sticking with it” led him into QA—and why test automation has become less a task and more a craft. His path starts with a first desktop PC and moves through school choices, a high‑school graduation with a vocational exam, into a product environment where broad functionality demands equally broad testing.

What stands out is the pragmatism. Luca doesn’t chase buzzwords; he talks about how quality happens in practice—where in everyday work the levers of reliability are, and why a good testing system emerges when you ask the right questions early on: Where does automation hook in? Which edge cases matter? And how do you stay calm and precise amid a glut of technologies and resources?

The first spark: A personal desktop and curiosity for IT

The beginning is relatable: a desktop PC at around age ten. In high school, anything IT‑supported became the gravitational center—especially “down in the PC lab”. The takeaway is simple: hands‑on exposure creates attachment. Early, low‑barrier tinkering, not abstract theory, builds a durable base for learning.

That foundational curiosity runs through Luca’s story. IT isn’t an abstraction; it’s something tangible, repeatable, and fun—especially once it starts to work end‑to‑end.

C# instead of Italian: A decisive choice in business school

After high school, Luca attends a commercial business school (Handelsakademie). One choice sets the direction: an extra foreign language or “Digital Business”. He picks programming. His line is as dry as it is telling:

The decision is pragmatic: treat software as a toolbox and build competence by doing. Crucially, Luca doesn’t gloss over the rough start. He says he didn’t “get into it well at the beginning” and struggled to see how to make things work. That honesty matters—most careers begin with friction.

When the switch flips: Learning under deadline pressure

The turning point comes with the first semester project (around the second year). Suddenly, deadlines, deliverables, and outcomes get real. Under pressure, he had to “sit down and solve it”—and then, as he puts it, “the switch flipped.” He saw how to approach problems and got that first taste of flow:

There’s a general learning pattern here: perseverance plus a concrete goal creates motivating feedback. The aha moment rarely happens while passively consuming material; it happens during active implementation—when something you built finally behaves.

Side projects, graduation, vocational exam: Practice teaches what theory can’t

Out of that aha moment come side projects—“little helpers” he coded for himself. That is a pivotal learning loop: when you automate your own friction, you learn problem decomposition, prioritization, and reusability—the same muscles QA relies on later. With his school‑leaving exam done (Matura), Luca also completes a vocational exam as an IT specialist. Then he draws a clear line: theory box checked, time for real‑world work.

That decision continues to shape his approach: solution‑oriented, product‑centric, and focused on what actually needs to work.

Arriving in QA: QA Engineer at evon GmbH

“By now I’ve arrived at evon as a QA Engineer,” Luca says. From there, he sketches the reality of his environment: a product with a “broad spread” and a wide palette of features. That breadth is the central testing challenge. The team must “keep an overview,” know what the product is supposed to do, and—critically—what customers expect it to do.

The answer isn’t one‑off testing but a structured test suite—so that “it works the way it should.” Tests, in other words, are not just gates at the end. They are how the team upholds the promise of the product.

Keeping the overview: Aligning expectations and reality

Luca’s description makes one thing clear: quality work begins with clarity. What capability is being promised? Where are the edges and limits? In this framing, QA is not a late control phase but the backbone for expectations, a mirror to the product’s commitments. Tests codify those expectations and catch gaps before customers do.

That overview is more than a list. It must be living, able to absorb changes, and attentive to edge cases. Test planning, therefore, is continuous. It grows with the product—and with the team’s understanding of it.

Refinement as a leverage point: Thinking automation and edge cases early

When a new feature comes into refinement, Luca shifts into a distinct mode. As the technical designs are reviewed, he finds himself mentally “veering off” into testing. Two questions drive him:

• Where can test automation hook in?
• Which edge cases are interesting enough that we must cover them?

The answers feed into the test plan. Timing matters: the earlier, the better. The earlier testing ideas are on the table, the more they can shape architecture, interfaces, and data flows. That saves later rework and improves the design itself.

Test plan and test suite: Breadth of coverage as a promise

For Luca, the test plan must be “as broad as possible” so that the team can “ensure the product does what we say it does.” That phrasing is programmatic: quality is a promise; tests are the proof.

What does “broad” imply in practice? Without naming specifics, three layers emerge:

• Functional coverage: Does the feature do what was promised?
• Integration view: Does it play well with the rest of a broad product?
• Edge cases: What happens at the boundaries—under unusual usage, invalid inputs, or broken assumptions?

A test suite is not an end in itself. It is a map of risks and expectations.

Finding a niche: Test automation as a craft

Luca has found his niche: test automation. He says he has “grown into it” and that it’s what he truly enjoys. That combination—growth plus enjoyment—is the fertile ground for deep competence. Automation is never “done.” It demands pattern recognition, prioritization, and a fight for stability: tests must be regression‑proof rather than brittle; they must deliver fast feedback rather than create noise.

Seeing automation as a craft means treating tools as means, not ends. The important questions come first: What needs safeguarding? Which signals do we require? Which edge cases must be automated, and which are better served by exploratory testing?

Advice to newcomers: Sticking with it beats tool overload

Luca’s guidance for newcomers is refreshingly non‑dogmatic:

• It’s “basically irrelevant which education path you take”—business school, technical high school, university, self‑taught, coding camp.
• You need “a bit of an eye for detail” and persistence.
• Don’t be discouraged by the “sheer amount of technologies and resources online.” Start, continue, maintain orientation.

That stance mirrors his own path: try, struggle under a deadline, then discover the fun of making things work.

Pragmatic guardrails for QA practice (our takeaways)

Here are concrete, everyday guardrails distilled from Luca’s story—no tool worship, just a clear quality compass:

1) Start testing early—begin in your head

• In refinement, listen actively and jot down test ideas in parallel.
• Translate requirements into testable criteria before implementation starts.
• Ask: What is the core value? Which design assumptions are implicit? What if an assumption breaks?

2) Curate edge cases, don’t hoard them

• Edge cases are not a junk drawer. Choose them deliberately: rare but plausible conditions; conditions with disproportionate impact if they fail; places where systems touch limits (size, timing, nulls, invalid formats).
• Each team member should answer two questions: “Which edge case worries me most?” and “How would I test it reproducibly?”

3) Treat the test plan as a living document

• Don’t let it go stale. Any change in features or understanding goes in immediately.
• Create transparency: Which areas are automated, which are deliberately exploratory? Which risks are accepted and why?

4) Automation is a product—and it needs maintenance

• Stability > breadth. Flaky tests aren’t protection; they’re noise.
• Consider runtime, data dependencies, and test isolation early.
• Invest in automation where repetition and risk are high.

5) Use side projects as a learning engine

• Small helpers for your own life are perfect to practice pattern recognition and robust coding.
• The moment “it runs and does what I told it to do” is a strong intrinsic motivator—exactly as Luca describes.

6) Cultivate an eye for detail

• Failures often live at the margins. To see margins, normalize taking “minor” inconsistencies seriously.
• Detail focus is not perfectionism. It’s a method for finding risk systematically.

A questions checklist for refinement: Thinking in edge cases

Luca’s refinement lens—“where can I drive in with test automation?”—suggests a practical checklist any team can adopt:

• Which paths are the happy paths, which are the unhappy paths—and which must be automated?
• Which design assumptions might break (empty fields, unexpected orderings, time shifts, duplicate requests)?
• Which system limits matter (data sizes, external dependencies, latency)?
• How can we create reproducible state to test edge cases stably?
• Which metrics tell us the suite actually protects (e.g., regressions caught, defect trend)?
• What is explicitly out of scope—and why?

This list doesn’t replace domain expertise, but it refines attention and brings early structure to testing.

Learning because it matters: Deadline pressure as a teacher

It’s striking how Luca frames deadline pressure—not as a burden, but as a catalyst. With “enough deadline stress,” he sat down and worked through the problem. That’s an invitation to use deadlines wisely: not as anxiety triggers but as structure for focus. Small, binding milestones are fertile ground for the very aha moments that sustain motivation.

Broad product, broad responsibility

A “broadly spread” product is demanding. It requires overview, prioritization, and recognition that quality isn’t a state but a practice. Luca’s team stance—clarify expectations, mirror customer needs, build a well‑curated suite—shows how QA is a collective job. Quality doesn’t test “against” development; it upholds the joint promise the team makes to users.

QA career paths: Openness over dogma

A strong signal for anyone considering QA: the path is open. Whether business school, technical high school, university, self‑taught, or coding camp—any path can work. As Luca notes, nobody says in kindergarten, “I want to be a QA Engineer.” What matters is bringing enthusiasm for software and being willing to build the craft. Test automation is a great playground for those who enjoy structure, take details seriously, and systematically reduce risk.

Our distilled message from the session

From “Title: Luca Voit, QA Engineer bei evon” (Speaker: Luca Voit, Company: evon GmbH), we carry three lessons:

1) Quality starts early: Thinking automation and edge cases during refinement leads to better features.

2) Persistence trumps overload: The flood of tools and resources is manageable with clear focus.

3) Joy in the run: Software that “does what I tell it to do” is a powerful engine for growth and continuous improvement.

Conclusion: Where curiosity meets system

Luca Voit’s path—from first PC to test automation—shows how interest in IT can condense into a practical quality compass. A broad product requires broad, well‑curated tests; good teams ask early questions and fight for stable automation. And those who want to grow in QA need two essentials: curiosity and staying power.

Work this way and you deliver precisely what Luca describes in his role at evon GmbH: a product that does “what we say it does.” That’s not a lucky outcome. It’s a craft, lived day by day.

• 

  

  Scheduling Optimization in Practice

  Michael Missethan von evon teilt in seinem devjobs.at TechTalk ein paar theoretische Grundgedanken zur Logik von Terminplanung und zeigt ein interessantes Beispiel einer Optimierung.

  Watch now

• 

  

  Sahra-Marie Kreidl, Front End Developer bei evon

  Sahra-Marie Kreidl von evon erzählt im Interview darüber, wie sie zum Programmieren gekommen ist, was ihr an der Arbeit im Front End gefällt und gibt Tipps für Anfänger.

  Watch now
• 

  

  Lorenz Pretterhofer, Application Engineer bei evon

  Lorenz Pretterhofer von evon gibt im Interview Einblicke in die vielfältigen Tätigkeiten als Application Engineer, wie er zu dem Job gekommen ist und was meiner Meinung nach für Neueinsteiger wichtig ist.

  Watch now