Vom Atari-BASIC zur Testleitung: Wie Stephan Puri-Jobi, Software Test Lead bei HID Global, Softwarequalität zur Berufung machte

Kontext: Unser Gespräch mit Stephan Puri-Jobi (HID Global GmbH)

• Title: Stephan Puri-Jobi, Software Test Lead bei HID Global
• Speaker: Stephan Puri-Jobi
• Company: HID Global GmbH

Als Redaktion von DevJobs.at haben wir dem Werdegang von Stephan Puri-Jobi aufmerksam zugehört. Sein Weg führt von den ersten Programmierzeilen auf einem Atari über die Erkenntnis, dass Softwaretest viel mehr ist als „ein bisschen ausprobieren“, bis hin zur Testleitung bei einem global tätigen Unternehmen. Besonders eindrücklich: wie sehr strukturierter Test, Teamkultur und kontinuierliches Lernen seine berufliche Entwicklung geprägt haben – und wie klar seine Empfehlungen an Nachwuchstalente ausfallen.

Der Anfang: Faszination am Rechner und die ersten Zeilen BASIC

Stephan entdeckte Programmierung im Jugendalter – aus purer Neugier. Auf seinem Atari lagen die Spiele irgendwann langweilig herum; spannender wurde die unscheinbare „basic diskette“, die plötzlich eine neue Welt eröffnete.

Dieser spielerische Start ist ein starkes Motiv, das wir in vielen Entwicklerbiografien hören: Nicht der perfekte Lehrplan bringt den Funken, sondern der Moment, in dem man selbst etwas zum Laufen bringt. Bei Stephan waren es die Zeilen, die sichtbar etwas bewirken – ein unmittelbares Feedback, das motiviert, weiterzumachen.

Schule und Borland Delphi: Ein Werkzeugkasten, der Horizonte öffnet

In der Schule rückte die Programmierung in strukturiertere Bahnen. Mit Borland Delphi hatte Stephan ein Werkzeug, das bereits damals „eine Menge Bibliotheken“ bot und viele Türen öffnete. Der Effekt: Aus der Faszination wurde ein Plan. Für ihn war klar, dass ein Informatikstudium kommen würde.

Das ist eine frühe Erkenntnis seiner Geschichte: Wenn Werkzeuge Zugänge schaffen, entsteht Raum für echte Lernkurven. Bibliotheken, die Aufgaben vereinfachen, mindern nicht die Leistung – sie beschleunigen den Lernprozess und zeigen, was möglich ist. So reifte bei Stephan die Zielsetzung, das Fach formal zu studieren.

Das blinde Fleckchen im Studium: Softwaretest als Randnotiz

Spannend – und für viele Leserinnen und Leser wohl vertraut – ist Stephans Rückblick auf sein Studium. „Softwareentwicklung, natürlich“, sagt er. Architektur, Technologien, Implementierung – alles präsent. Aber: „Softwaretest war nicht wirklich ein großes Thema.“

Auch in der ersten Arbeitsstation wiederholte sich dieses Muster. Man „probierte Dinge nach der Entwicklung aus“, doch aus heutiger Sicht, sagt er, war das kein „richtiges Testen“. Wir hören hier eine essenzielle Einsicht: Ohne Struktur ist Test reaktiv, zufällig und wenig belastbar. Es fehlt die Methode, die Denkrichtung, die Zielschärfe.

Der Wendepunkt: Sicherheitsrelevante Software und ein dediziertes Testteam

Der Perspektivwechsel kam in einem Unternehmen, das sicherheitsrelevante Software entwickelte. Hier gab es „strukturiertes Softwaretest“ – mit einem eigenen Team, das ausschließlich für die Qualitätssicherung zuständig war. Für Stephan war das ein Augenöffner.

Dieser Moment ist in seiner Laufbahn der Kipppunkt: Testen wird von der Nebensache zur eigentlichen Disziplin – anspruchsvoll, methodisch, kreativ. Wir nehmen aus diesem Abschnitt zwei Lehren mit:

• Struktur im Test macht den Unterschied zwischen „probieren“ und „prüfen“.
• Ein dediziertes Testteam schafft Fokus, Verantwortung und eine Kultur, die Qualitätsziele ernst nimmt.

2020: Einstieg bei HID Global GmbH und der Weg zur Testleitung

Anfang 2020 stieg Stephan als Software Test Engineer bei HID Global GmbH ein. Heute ist er Test Lead. Seine Beschreibung der Rolle ist ein klares Statement für die Vielfalt im Softwaretest: abwechslungsreich, teamzentriert und zutiefst interdisziplinär.

Für uns zeigt das: Test ist ein Feld der Spezialisierungen. Spezifikation, Implementierung, Automatisierung – das sind unterschiedliche Profile mit eigenem Tiefgang. Ein starkes Testteam vereint diese Stärken, statt auf ein Einheitsprofil zu setzen.

Ein Tag ohne Schema F: Von PRS über Spezifikationen bis zur Fehlersuche

„Den typischen Tag gibt es nicht“, sagt Stephan. Und dann zeichnet er doch einen klaren Ablauf, wie Qualität entsteht. Am Morgen etwa steht die Review von Testspezifikationen an – hergeleitet aus der „PRS“. Ziel: sicherzustellen, dass „alle interessanten Aspekte“ abgedeckt sind. Am Nachmittag folgen Implementierungen oder deren Reviews.

Parallel läuft der Puls des Tagesgeschäfts: Ein Kollege findet einen Bug – idealerweise, denn genau dafür testet man. Und dann beginnt die Analyse. Liegt der Fehler in der Testimplementierung oder -spezifikation? Oder am „Device under Test“? Diese Schleife – Hypothesen bilden, präzise abgrenzen, zuordnen – ist das Kerngeschäft guten Testens.

Uns fällt auf, wie selbstverständlich Stephan über diese Fehlerquellen spricht. Kein Alarmismus, kein Fingerzeig, sondern nüchterne Ursachenanalyse. Das ist gelebte Qualitätssicherung: Der Prozess ist robust genug, um eigene Fehler zu erkennen und zu korrigieren.

Zusammenarbeit mit der Entwicklung: Vom „Bad Guy“ zur gemeinsamen Mission

Die Interaktion mit Entwicklungsteams bezeichnet Stephan als „manchmal kritisch“. Kein Wunder: Test ist häufig der Überbringer schlechter Nachrichten. Aber der Tenor in seinem Team ist ein anderer – und genau das scheint den Unterschied zu machen.

Aus unserer Sicht liegt hierin ein entscheidender Erfolgsfaktor: Test als Partner. Wenn das Ziel geteilt wird – ein bestmögliches Produkt – werden Befunde nicht als Kritik am Code, sondern als Beitrag zur Qualität gelesen. Das entlastet, beschleunigt und verbessert.

Fundament zuerst: Warum eine Hochschulausbildung für Stephan zählt

Auf die Frage nach Rat für den Nachwuchs wird Stephan sehr konkret. Sein erster Punkt: „Du brauchst eine solide Basis.“ Die empfiehlt er ausdrücklich über ein Studium an einer Fachhochschule.

Wir interpretieren das nicht als Dogma, sondern als Handlungsanweisung: Strukturierte Grundlagenarbeit erleichtert späteres Lernen. Sie schafft Vokabular, Vergleichswerte und Denkmodelle, um neue Konzepte schneller einzuordnen – auch im Test, wo präzise Begriffe und methodisches Vorgehen zentral sind.

Lernressourcen heute: Vom 28k-Modem zu Tutorials, Foren und Open Source

Ein persönlicher Rückblick setzt die Gegenwart in Perspektive: Als Stephan begann, „kam das Internet gerade auf“. Ein 28k-Modem war weit entfernt von heutiger Verfügbarkeit. Und trotzdem gab es schon Informationen. Heute hingegen ist das Angebot schier unbegrenzt.

Die Botschaft ist klar: Wer lernen will, hat kaum Barrieren. Der Schlüssel liegt im aktiven Zugriff. Tutorials schauen, Communitys lesen, Open-Source-Projekte verstehen – das sind keine Ersatzhandlungen, sondern echte Lernpfade. Für uns als Redaktion klingt da ein weiterer Imperativ mit: Nicht passiv konsumieren, sondern am Code mitdenken.

Praxis vor Theorie: So früh wie möglich „an echten Code“

Stephans dritter Rat ist vielleicht der handfesteste: „Geh so früh wie möglich raus.“ Praktika, echte Codebasen, Kolleginnen und Kollegen, die helfen – das ist der Multiplikator, den kein Kurs ersetzen kann.

Und dann der Satz, der viele Karrieren zusammenfasst:

Diese Haltung ist ein Lernsystem für sich: Feedback-Schleifen, Vergleich und Praxis. Wer sie konsequent auf Test und Entwicklung anwendet, maximiert seine Lernrate.

Was wir mitnehmen: Leitlinien für eine Karriere im Softwaretest

Aus der Geschichte und den Ratschlägen von Stephan Puri-Jobi lassen sich konkrete Handlungsfelder ableiten. Ohne Buzzwords, mit Fokus auf das, was er tatsächlich gesagt und gelebt hat.

1) Baue eine solide Basis

• Investiere in ein strukturiertes Studium an einer Fachhochschule.
• Sammle dort Breite: Technologien, Architekturmuster, Implementierungswege.
• Ziel ist nicht nur Wissen, sondern Denkwerkzeuge, um später schneller zu lernen.

2) Suche die Struktur im Testen

• „Probieren“ ist nicht „Testen“.
• Lerne, wie Testspezifikationen aus Anforderungen abgeleitet werden (Stichwort: PRS in Stephans Praxis).
• Entwickle eine Routine aus Review, Implementierung, Ausführung und Analyse.

3) Spezialisierung im Team nutzt allen

• Testspezifikation, Testimplementierung, Automatisierung: Das sind unterschiedliche Rollen.
• Stärke entsteht, wenn diese Perspektiven zusammenarbeiten – nicht, wenn eine Person alles alleine stemmt.

4) Pflege die Kultur mit der Entwicklung

• Test findet Fehler – und das ist gut so.
• „Bad Guy“-Momente werden produktiv, wenn beide Seiten das gemeinsame Ziel teilen: das beste Produkt.
• Klare, respektvolle Kommunikation schafft Vertrauen und Tempo.

5) Nutze offene Lernkanäle

• Tutorials, Videos, Foren, Open Source – das Angebot ist großartig.
• Wähle bewusst, halte den Code im Blick, und verknüpfe Gesehenes mit Praxis.

6) Praktika und Code-Reviews so früh wie möglich

• Suche dir Umgebungen, in denen Kolleginnen und Kollegen deinen Code begutachten.
• Lerne aktiv aus dem Code anderer – das verkürzt Lernschleifen enorm.
• Je früher, desto besser: Praxis ist der beste Beschleuniger.

Ein Blick auf die Praxis: Der Qualitätszyklus, den Stephan beschreibt

Was uns an Stephans Beschreibung besonders überzeugt, ist die Klarheit im Ablauf – trotz der Aussage, dass es den „typischen Tag“ nicht gibt. Wir sehen einen Qualitätszyklus, der sich in vielen Teams bewährt:

• Anforderungen sichtbar machen: Ableitung der Testspezifikationen aus der PRS.
• Spezifikationen gemeinsam prüfen: Review, um „alle interessanten Aspekte“ abzudecken.
• Implementieren und gegenprüfen: Testimplementierungen erstellen und reviewen.
• Entdecken und erklären: Bugs finden, Ursachen zuordnen – Testfehler vs. Produktfehler.
• Zusammenarbeit leben: Entwicklung und Test am selben Ziel ausrichten – bestmögliche Produktqualität.

Dieser Zyklus ist kein starres Prozessdiagramm, sondern eine Art Denkbewegung: vom Verstehen über das Absichern ins Lernen zurück. Er enthält Prinzipien, die universell sind – ob in Embedded, Desktop, Mobile oder Web – ohne dass Stephan hier konkrete Technologien nennen musste.

Warum diese Story Entwicklerinnen und Entwickler heute anspricht

Mehr denn je wird Qualität in der Software zum Differenzierungsmerkmal. Stephans Weg zeigt, dass Testen keine „Phase“ ist, sondern ein Denkstil: neugierig, strukturiert, kollaborativ. Die Elemente seiner Story – früher Einstieg, solide Grundlagen, strukturierte Methoden, Teamkultur, Praxisnähe – ergeben zusammen einen Plan, der funktioniert, auch wenn die Tools wechseln.

Besonders überzeugend ist die Balance aus Demut und Anspruch: Es ist okay, wenn Testspezifikationen einmal falsch liegen. Wichtig ist, dass das System – Menschen, Prozesse, Reviews – robust genug ist, das zu erkennen und zu korrigieren. In dieser Haltung liegt Professionalität.

Konkrete nächste Schritte für Leserinnen und Leser

Wer sich von Stephans Weg inspirieren lässt, kann unmittelbar ansetzen:

• Suche dir ein Open-Source-Projekt, dessen Tests du nachvollziehen kannst. Versuche zu verstehen, wie Anforderungen in Tests übersetzt wurden.
• Bitte in deinem Umfeld um ein kleines, regelmäßiges Code-Review-Format – wechselseitig und fokussiert.
• Schreibe für eine bestehende Funktion zunächst eine Testspezifikation, dann die Testimplementierung. Prüfe beides im Review.
• Lege dir eine Lernroutine an: wöchentlich ein Tutorial oder eine Artikelserie zum Thema Testentwurf, kombiniert mit praktischer Übung am Code.
• Bewirb dich proaktiv für ein Praktikum oder suche dir eine Mentorin/einen Mentor in deinem Team, der/die dir gezielt Feedback gibt.

Alle diese Schritte sind durch Stephans Empfehlungen gedeckt und bauen auf seinen Erfahrungen auf – ohne künstlichen Ballast.

Schluss: Qualität als Teamleistung – und als persönlicher Weg

Die Geschichte von Stephan Puri-Jobi, Software Test Lead bei HID Global, ist ein Plädoyer für den bewussten Weg: frühe Neugier, strukturierte Grundlagen, dann die Entdeckung, dass Testen eine anspruchsvolle Disziplin ist. Seine heutige Arbeit – mit Fokus auf Spezifikation, Implementierung, Automatisierung, Review, Debugging und Zusammenarbeit – zeigt, wie viel Gestaltungskraft im Softwaretest steckt.

Wir nehmen mit: Qualität entsteht dort, wo Menschen gemeinsam denken, präzise arbeiten und voneinander lernen. Oder, in Stephans Worten: „Versuche, so viel wie möglich so früh wie möglich zu tun – lass andere auf deinen Code schauen und schau du auf den Code anderer.“ Besser lässt sich ein verlässlicher Karrierekompass kaum formulieren.

• 

  

  Testing on all Levels

  Stephan Puri-Jobi von HID Global beleuchtet in seinem devjobs.at TechTalk das Thema Testing und was es insbesondere bei Secure Devices zu beachten gibt.

  Jetzt ansehen
• 

  

  Importance of secure coding

  Bassem Taamallah von HID Global spricht in seinem devjobs.at TechTalk darüber, wie sich die Praktiken von Secure Coding auf die Qualität der Produkte auswirkt.

  Jetzt ansehen

• 

  

  Stephan Puri-Jobi, Software Test Lead von HID Global

  Software Test Lead bei HID Global Stephan Puri-Jobi gibt im Interview Einblicke in den Aufbau des Unternehmens und des agilen Testing Teams, mit welchen Technologien gearbeitet wird und wie das Recruiting im Team gestaltet ist.

  Jetzt ansehen

• 

  

  Anna Dziarkowska, Software Engineer bei HID Global

  Anna Dziarkowska von HID Global erzählt im Interview wie sie zum Software Engineering gekommen ist, mit welchen Themen sie sich aktuell als Software Engineer beschäftigt und was sie Anfängern empfehlen würde.

  Jetzt ansehen