Vom ersten PC zur Testautomatisierung: Luca Voit, QA Engineer bei evon, über Fokus, Edge Cases und Dranbleiben

Einleitung: Eine devstory aus der Qualitätswelt

In der devstory „Title: Luca Voit, QA Engineer bei evon“ (Speaker: Luca Voit, Company: evon GmbH) zeigt sich, wie ein früher IT‑Funke zu einer klaren beruflichen Nische werden kann. Luca Voit beschreibt, wie Neugier, Termindruck und ein unerschütterliches „Dranbleiben“ ihn in die Qualitätssicherung führten – und warum Testautomatisierung für ihn heute nicht nur Aufgabe, sondern Handwerk ist. Sein Weg beginnt mit einem ersten eigenen PC und führt über schulische Weichenstellungen, eine Matura samt Lehrabschlussprüfung, hinein in ein Umfeld, in dem breite Produktfunktionalität zuverlässige Tests verlangt.

Was uns auffällt: Luca spricht nie in Superlativen. Er schildert nüchtern, wie Dinge passieren, wo im Alltag die Hebel der Qualität liegen – und weshalb ein gutes Testsystem entsteht, wenn man früh im Entwicklungsprozess die richtigen Fragen stellt: Wo greift Automatisierung? Welche Edge Cases sind entscheidend? Und wie bleibt man trotz vieler Technologien gelassen und präzise?

Der erste Impuls: Ein eigener PC und der Funke IT

Der Ursprung ist unprätentiös und nachvollziehbar: ein eigener Desktop-PC mit etwa zehn Jahren. Der Wunsch wurde zur Realität – auch, weil die Schwester schon einen hatte. Im Gymnasium kristallisierte sich schnell heraus, was ihn anzog: alles, „was IT‑gestützt war“, alles „unten im PC‑Saal“. Die Botschaft, die wir daraus mitnehmen: Berührung schafft Bindung. Frühes, niedrigschwelliges Ausprobieren – nicht Theorie um ihrer selbst willen – legt eine belastbare Basis.

Diese Grundneugier zieht sich als roter Faden durch Lucas Geschichte. IT ist hier keine abstrakte Idee, sondern etwas, das greifbar und wiederholbar Spaß macht. Das ist wichtig – gerade, wenn es später ernst wird und Termindruck das Lernen erzwingt.

C# statt Italienisch: Die Weichenstellung in der Handelsakademie

Nach dem Gymnasium folgt die Handelsakademie. Eine Wahl prägt den weiteren Weg: Fremdsprache oder „Digital Business“. Luca entscheidet sich bewusst gegen eine weitere Sprache und für Programmieren. Er bringt es trocken auf den Punkt:

Was uns daran beeindruckt, ist nicht nur die Entscheidung an sich, sondern die Haltung dahinter: Software nicht als abstrakte Disziplin, sondern als Werkzeugkasten, der – wenn man dranbleibt – Spaß machen kann. Gleichzeitig verschweigt er nicht, dass der Einstieg holprig war. „Am Anfang gar nicht so gut hinkommen“, beschreibt er sein Ringen mit den ersten Aufgaben. Dieses Ringen ist typisch – und lehrreich.

Wenn der Knopf aufgeht: Lernen unter Termindruck

Der entscheidende Moment kommt mit der ersten größeren Semesterarbeit, etwa in der zweiten Klasse. Was vorher theoretisch blieb, wird plötzlich verbindlich: Abgabe, Termin, Ergebnis. Durch den Druck musste er „sich wirklich hinsetzen“ und das Problem lösen. Dann, so beschreibt er, „ist irgendwann einmal der Knopf aufgegangen“ – und der Blick auf Programmieren kippt vom Frust zum Flow:

Hier steckt ein generelles Lernmuster drin: Ausdauer plus konkretes Ziel erzeugen Feedback, das motiviert. Der Aha‑Effekt entsteht nicht beim passiven Konsumieren, sondern in der aktiven Umsetzung, wenn ein selbstgebautes Stück Software endlich tut, was es soll. Genau dieser Moment markiert bei vielen den Übergang vom „Ich probiere mal“ zum „Ich will mehr davon“.

Side Projects, Matura, Lehrabschluss: Praxis als Lehrmeister

Auf den Aha‑Moment folgen Side Projects – „kleine Helferlein“, die Luca für sich selbst programmiert. Das ist ein bemerkenswerter Schritt: Wer die eigene Friktion im Alltag automatisiert, lernt Problemzerlegung, Priorisierung, Wiederverwendbarkeit – all das, was später in der Qualitätssicherung zählt. Mit der Matura in der Tasche absolviert er außerdem eine Lehrabschlussprüfung als IT‑Informatiker. Und dann zieht er für sich eine klare Linie: Genug Theorie, jetzt Berufspraxis.

Diese Entscheidung wirkt bis heute: Sie prägt, wie Luca an Themen herangeht – lösungsorientiert, am Produkt, mit Blick auf das, was wirklich benötigt wird.

Ankommen in der Qualitätssicherung: QA Engineer bei evon GmbH

„Mittlerweile bin ich … bei der evon angekommen als QA Engineer.“ Aus dieser nüchternen Feststellung entwickelt er einen Einblick in die reale Komplexität seines Umfelds: ein Produkt mit „breit gestaffelt[er] … Palette an Features“. Genau diese Breite ist die zentrale Testherausforderung. Denn ein Team muss „den Überblick halten“, wissen, „was [das Produkt] alles können soll“ – und, noch wichtiger, „was [die] Kunden … fordern“.

Die Antwort darauf ist kein einmaliges Testen, sondern eine strukturierte Test-Suite. Sie stellt sicher, „damit es so funktioniert, wie es soll“. Tests sind hier also nicht bloß Prüfsteine am Ende, sondern eine Absicherung des Wertversprechens: Das Produkt tut, was zugesagt wird.

Überblick bewahren: Anforderungen und Realität in Deckung bringen

Lucas Beschreibung legt nahe: Qualitätsarbeit beginnt mit Klarheit. Welche Fähigkeit ist zugesagt? Wo sind die Grenzen? Qualität ist hier Kompass und Rückgrat, nicht nachgelagerte Kontrolle. Besonders deutlich wird das in der Verzahnung mit dem Produkt- und Entwicklungsprozess: Tests spiegeln Erwartungen und schließen Lücken, bevor sie beim Kunden auffallen.

Dabei ist der Überblick mehr als eine Liste. Er muss lebendig sein, Änderungen aufnehmen, Edge Cases antizipieren. Die Folge: Testplanung ist eine kontinuierliche Disziplin. Sie wächst mit dem Produkt – und mit dem Teamverständnis der Anforderungen.

Refinement als Qualitätshebel: Automatisierung und Edge Cases früh denken

Wenn ein neues Feature kommt und im Refinement besprochen wird, schaltet Luca in einen charakteristischen Modus. Während die technischen Designs durchgegangen werden, „driftet“ er (wie er augenzwinkernd erzählt) geistig schon in die Testwelt ab. Er fragt sich:

• Wo kann ich mit Testautomatisierung „reinfliegen“?
• Welche Edge Cases sind interessant – also jene Fälle, die anders, selten, grenzwertig sind und dennoch auftreten können?

Die Erkenntnisse daraus fließen in den Testplan. Relevant ist die zeitliche Lage: so früh wie möglich. Je eher Testideen an Bord sind, desto besser lassen sie sich in Architektur, Schnittstellen und Datenflüsse integrieren. Das spart nicht nur Aufwand im Nachhinein, sondern erhöht die Qualität des Designs selbst.

Testplan und Test-Suite: Breite Abdeckung als Versprechen

Aus Lucas Sicht muss der Testplan „möglichst breit aufgestellt“ sein, damit „wir … gewährleisten können, dass das Produkt das tut, was wir sagen, dass es tut.“ Diese Formulierung ist programmatisch: Qualität ist ein abgegebenes Versprechen – Tests sind der Nachweis.

Was bedeutet „breit“ konkret? Ohne in Details zu gehen, werden drei Ebenen greifbar:

• Funktionsabdeckung: Prüft das Feature, was zugesagt wurde?
• Integrationssicht: Funktioniert es zusammen mit anderen Bestandteilen des breiten Produkts?
• Edge Cases: Was passiert in Grenzbereichen, unter ungewöhnlichen Nutzungsbedingungen, bei fehlerhaften Eingaben oder bei Annahmen, die brechen können?

Die Test-Suite ist damit kein selbstzweckhaftes Artefakt, sondern eine Landkarte der Risiken und Erwartungen.

Die Nische finden: Testautomatisierung als Handwerk

Luca hat seine Nische identifiziert: Testautomatisierung. Er erzählt, dass er in diesem Bereich „gewachsen“ ist – und dass ihm das „wirklich Spaß macht“. Genau diese Kombination – Wachstum und Freude – ist der Nährboden für Kompetenzaufbau. Automatisierung ist nie „fertig“. Sie verlangt Mustererkennung, Priorisierung und vor allem das Ringen um Stabilität: Tests sollen regressionssicher sein, nicht brüchig; sie sollen schnell Feedback geben, nicht nur Last erzeugen.

Wer Automatisierung als Handwerk versteht, sieht Werkzeuge als Mittel, nicht als Ziel. Das Wichtige kommt vorher: Was will ich absichern? Welche Signale brauche ich? Welche Edge Cases müssen zwingend automatisiert werden und welche gehören eher in exploratives Testen?

Dranbleiben schlägt Overload: Lucas Rat an Einsteiger:innen

Der vielleicht wichtigste Satz, den Luca für Einsteiger:innen parat hat, ist ein doppelter: Dranbleiben – und sich von der schieren Menge an Technologien nicht einschüchtern lassen. Er sagt klar:

• Es ist „eigentlich ganz egal, was man für eine Ausbildung macht“ – ob HAK, HTL, Studium, selbst beigebracht oder Coding-Camp.
• Entscheidend ist, dass man „ein bisschen ein Auge fürs Detail“ mitbringt und dranbleibt.
• Die „Fülle an Technologien oder Ressourcen … online“ darf nicht abschrecken. Wichtig ist: anfangen, weitermachen, Orientierung behalten.

Diese Haltung korrespondiert mit seinem eigenen Weg: Erst probieren, dann unter Termindruck durchbeißen, schließlich Spaß an der Struktur finden.

Praktische Leitplanken für die QA-Praxis (unsere Takeaways)

Aus Lucas Erzählung lassen sich konkrete, alltagstaugliche Leitplanken ableiten – ohne Tools zu glorifizieren, aber mit einem klaren Qualitätskompass:

1) Früh im Prozess testen – im Kopf beginnen

• In Refinements aktiv zuhören und parallel Testideen formulieren.
• Prüffragen notieren: Was ist der Kernnutzen? Welche Annahmen stecken im Design? Was passiert, wenn eine Annahme bricht?
• Anforderungen in testbare Kriterien übersetzen, bevor Implementierung startet.

2) Edge Cases kuratieren statt sammeln

• Edge Cases sind kein Sammelbecken. Sie müssen gezielt ausgewählt werden: seltene, aber plausible Bedingungen; Bedingungen, die besonders schmerzhaft sind, wenn sie schiefgehen; Stellen, an denen Systeme Grenzen berühren (Limits, Timeouts, Nullwerte, ungültige Formate).
• Jede:r im Team sollte zwei Fragen beantworten können: „Welcher Edge Case bereitet mir die größte Sorge?“ und „Wie würde ich ihn reproduzierbar testen?“

3) Testplan als lebendes Dokument behandeln

• Testplan nicht als statisches Artefakt begreifen. Änderungen am Feature oder am Verständnis gehören sofort hinein.
• Transparenz schaffen: Welche Bereiche sind automatisiert, welche bewusst explorativ? Welche Risiken sind akzeptiert?

4) Automatisierung ist ein Produkt – und braucht Pflege

• Stabilität > Umfang. Flaky Tests sind keine Absicherung, sondern Rauschen.
• Laufzeiten, Datenabhängigkeiten und Testisolation früh berücksichtigen.
• Automatisierung dort investieren, wo Wiederholung und Risiko groß sind.

5) Side Projects als Lernmotor nutzen

• Kleine Helfer für den eigenen Alltag sind ideal, um Muster zu erkennen und robusten Code zu schreiben.
• Das Erfolgserlebnis, wenn „es läuft und tut, was ich ihm sage“, ist ein kraftvoller Motivator – wie Luca es beschreibt.

6) Detailfokus kultivieren

• Fehlerbilder entstehen oft an Rändern. Wer Ränder sehen will, braucht Routine darin, scheinbar „unwichtige“ Abweichungen ernst zu nehmen.
• Detailfokus ist kein Perfektionismus: Er ist eine Methode, um Risiken systematisch zu finden.

Fragenkatalog für Refinements: So denken wir Edge Cases mit

Luca hat uns mit seiner Refinement-Perspektive – „wo kann ich mit einer Test-Automation reinfahren“ – einen klaren Impuls gegeben. Daraus ergibt sich ein Fragenkatalog, der in jedem Team anwendbar ist:

• Welche Nutzerpfade sind „Happy Paths“, welche sind „Unhappy Paths“ – und welche müssen unbedingt automatisiert abgedeckt werden?
• Welche Annahmen im Design könnten brechen (z. B. leere Felder, unerwartete Reihenfolgen, Zeitverschiebungen, doppelte Anfragen)?
• Welche Systemgrenzen sind relevant (Größenlimits, Abhängigkeiten von externen Systemen, Latenzen)?
• Wie lässt sich der Zustand reproduzierbar herstellen, um Edge Cases stabil zu testen?
• Welche Metriken zeigen uns, dass die Test-Suite wirklich schützt (z. B. gefundene Regressionsfälle, Fehlertrends)?
• Was ist explizit nicht im Scope – und warum?

Dieser Katalog ist kein Ersatz für Fachwissen, aber eine pragmatische Checkliste, die den Blick schärft.

Lernen, weil es ernst wird: Termindruck als Lehrmeister

Bemerkenswert ist, wie Luca Termindruck beschreibt: nicht als Last, sondern als Katalysator. „Genügend Terminstress“ zwang ihn, sich hinzusetzen – und genau dort sprang der Funke über. Das ist eine Einladung, Deadlines klug zu nutzen: nicht als Stressfaktor, sondern als Struktur, die Fokus schafft. Wer kleine, verbindliche Ziele setzt, fördert genau die Art von Aha‑Momenten, die bleibend motivieren.

Breite Produkte, breite Verantwortung

Ein „breit gestaffeltes“ Produkt ist anspruchsvoll. Es verlangt Übersicht, Priorisierung und ein Verständnis dafür, dass Qualität kein Endzustand ist. Lucas Teamansatz – Erwartungen klären, Anforderungen der Kunden spiegeln, Test-Suite bauen – zeigt, wie QA ein kollektiver Job wird. Die Qualitätssicherung testet nicht „gegen“ Entwicklung, sondern „für“ das gemeinsam abgegebene Versprechen.

Karrierepfade in QA: Offenheit statt Dogma

Ein starkes Signal an alle, die überlegen, in QA einzusteigen: Der Weg ist offen. Ob HAK, HTL, Studium, Selbststudium oder Coding-Camp – alles ist möglich. Luca betont, dass niemand „im Kindergarten“ sagt: „Ich will QA Engineer werden.“ Wichtig ist, dass man Freude an Software mitbringt und bereit ist, sich das nötige Handwerkszeug zu erarbeiten. Genau dort entfaltet sich Testautomatisierung als Spielfeld für alle, die strukturiert denken, Details ernst nehmen und systematisch Risiken reduzieren wollen.

Unsere Bilanz aus der Session

Aus „Title: Luca Voit, QA Engineer bei evon“ (Speaker: Luca Voit, Company: evon GmbH) nehmen wir drei Kernbotschaften mit:

1) Qualität beginnt früh: Wer im Refinement schon an Automatisierung und Edge Cases denkt, baut bessere Features.

2) Dranbleiben schlägt Unsicherheit: Die Fülle an Technologien ist kein Hindernis, wenn der Fokus klar ist.

3) Freude am Laufen: Software, die tut, „was ich ihr sage“, ist ein starker intrinsischer Antrieb – und der Motor für kontinuierliche Verbesserung.

Fazit: Qualität entsteht, wo Neugier auf Systematik trifft

Luca Voits Weg vom ersten PC zur Testautomatisierung zeigt, wie sich Interesse an IT in einem klaren Qualitätskompass verdichten kann. Ein breites Produkt verlangt breite, gut kuratierte Tests; ein gutes Team braucht frühe Fragen und stabile Automatisierung. Und Menschen, die in QA wachsen wollen, brauchen vor allem zwei Dinge: Neugier – und die Bereitschaft, dranzubleiben.

Wer so arbeitet, liefert genau das, was Luca in seiner Rolle bei evon GmbH beschreibt: ein Produkt, das tut, „was wir sagen, dass es tut“. Das ist kein Zufall, sondern gelebtes Handwerk.

• 

  

  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.

  Jetzt ansehen

• 

  

  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.

  Jetzt ansehen
• 

  

  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.

  Jetzt ansehen