HID Global GmbH

Etablierte Firma

Alle Videos anzeigen

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.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

In „Stephan Puri-Jobi, Software Test Lead von HID Global“ erklärt Stephan Puri-Jobi, wie sein 15-köpfiges Test- und QA-Team mit SAFe arbeitet: kurze Dailies für Transparenz und schnelle Entblockung, dreiwöchige Sprints mit Retros, in denen gezielt Änderungen erprobt und gemessen werden, sowie vorausschauende Sprint- und Testplanung mit Puffern. Die vollständig automatisierten Tests (C#/.NET, NUnit, TestRail; CI/CD mit Jenkins, Groovy und Python; Jira, Git) prüfen Smart-Card-Credentials als Black Box mit Fokus auf Negativ- und Sicherheitsfälle sowie einer Reset-Strategie für stabile, lange Pipelines. Beim Hiring zählen klare Jobprofile und kurze, wertschätzende Interviews mit Fokus auf Teamfit und Wissensaustausch; unterstützt wird Talent durch Trainingsmaterial, Mentoring, Einsteigeraufgaben, Reviews und ausreichende Ramp-up-Zeit.

100% automatisierte Qualitätssicherung bei HID Global: Stephan Puri-Jobi über SAFe, CI/CD mit Jenkins und C#-Tests für sichere Smartcards

Ein Blick in die Praxis: Session mit Stephan Puri-Jobi (HID Global GmbH)

In der Session „Stephan Puri-Jobi, Software Test Lead von HID Global“ (Speaker: Stephan Puri-Jobi, Company: HID Global GmbH) gibt uns der Testleiter einen tiefen Einblick in eine QA-Organisation, die konsequent auf Automatisierung setzt – vom Testdesign bis zum Betrieb einer stabilen CI/CD-Pipeline. Sein Team testet sicherheitskritische Smartcard-Credentials komplett ohne manuelle Schritte und operiert unter klaren Randbedingungen: Black-Box-Tests, lange Testlaufzeiten, komplexe Standards und die Notwendigkeit, Fehlerzustände systematisch zu erzwingen, um Leckagen von Sicherheitsinformationen zuverlässig zu verhindern.

„So far, we don't have one single manual test.“

Aus unserer DevJobs.at-Perspektive ist diese Session ein Lehrstück für moderne Testorganisationen, die Sicherheit, Skalierbarkeit und Teamkollaboration verbinden. Sie zeigt, wie ein QA-Team mit 15 Personen in SAFe strukturiert arbeitet, wie Onboarding und Mentoring in einem hochregulierten Umfeld gelingen – und warum diese Umgebung für erfahrene wie aufstrebende Testingenieur:innen besonders attraktiv ist.

Teamauftrag: Sicherheit und Zuverlässigkeit für Smartcard-Credentials

Das Team von Stephan Puri-Jobi testet Credentials – konkret Smartcards, etwa in Formfaktoren, wie man sie aus dem Banking oder aus Hotels kennt. Der Fokus: funktionale Korrektheit und vor allem Sicherheit. Das Besondere dabei ist die Black-Box-Situation: Die Karte bietet keine Debug-Schnittstellen, die interne Logik ist nicht einsehbar. Alles muss über definierte Schnittstellen und beobachtbares Verhalten verifiziert werden.

„We are testing a piece of plastic. We don't have any debug connections… We really have to test it from the outside.“

Die stärksten Herausforderungen entstehen dort, wo Angriffe realistisch sind: Fehlbedienungen, falsche Kommandos, korrekte Kommandos mit falschen Daten oder falsche Sequenzen. Das Team muss sicherstellen, dass selbst bei absichtlicher Fehlbenutzung keine sensiblen Informationen offengelegt werden und die Karte nicht in unsichere Zustände kippt.

„We have to ensure that in the negative case… the card just does not malfunction and worst case would reveal any security… to the attacker.“

Diese Mission prägt alles: Testdesign, Toolchain, Pipeline-Strategie und Teamkultur.

Struktur und Rollen: 15 Personen, klare Schwerpunkte

Mit aktuell 15 Personen ist das Team für eine QA-Organisation stattlich besetzt. Die Verantwortlichkeiten sind klar gegliedert:

Test-Spezifikation: Ableitung und Dokumentation von Testfällen aus Standards (z. B. ISO) und Produktspezifikationen.
Test-Implementierung: Umsetzung der Testfälle in C#/.NET mit NUnit.
Testautomatisierung und CI/CD: Pflege von Jenkins-Pipelines, Groovy- und Python-Skripten, Integrationen und Testumgebungs-Setup.

Diese Dreiteilung spiegelt die technische Tiefe der Domäne wider. Das ist kein „Klicktest“-Umfeld. Es geht um Protokolle, Standards, Sequenzen, Zustände – und um den Übergang von formalen Anforderungen in ausführbaren, deterministischen Testcode.

Arbeitsweise nach SAFe: kurze Dailies, mutige Retros, fokussierte Planung

Das Team organisiert sich nach SAFe. Drei Elemente stechen hervor:

1) Dailies: kurz, klar, blockerlösend

Die täglichen Stand-ups sollen vor allem Transparenz schaffen und Doppelarbeit vermeiden. Ebenso wichtig: Blockaden früh erkennen und auflösen.

„We really try to keep this short… to identify early that if somebody is blocked by something so that we can help him out immediately.“

2) Retrospektiven: in jedem Sprint etwas verändern

Sprints dauern drei Wochen. Am Ende steht stets eine Retrospektive – und dort wird bewusst mindestens eine Sache geändert. Dieser kleine, kontrollierte Experimentierdrang ist Teil der Team-DNA.

„We always find something to change… We try to monitor this and track and see how this influences our way of work.“

Statt großer Umbauprojekte setzt das Team auf iteratives „Operational Tuning“: Hypothesen bilden, messen, beibehalten oder zurückrollen.

3) Sprintplanung mit Puffer

Planungen werden dicht, aber niemals überzogen aufgestellt. Puffer für Bugs und Unvorhergesehenes sind obligatorisch. So bleibt die Pipeline stabil und das Team reaktionsfähig.

„Everybody tries to fill himself up to almost the capacity… Of course, we need to have small buffers always for bugs…“

Toolchain und Automatisierung: C#, NUnit, TestRail, Jenkins, Groovy, Python

Die technische Basis der QA ist klar und fokussiert:

Testumgebung: C#/.NET
Test Runner: NUnit
Testspezifikation: TestRail als führendes System
Integration: Hilfsskripte übertragen Informationen aus TestRail in die C#-Implementierung
CI/CD: Jenkins mit Groovy- und Python-Skripten
Agile Tooling: Jira zur Planung und Nachverfolgung im SAFe-Kontext
Versionsverwaltung: Git

„Our team is quite lazy. They don't want to do much. They prefer programming things, and this is perfectly fine.“

Diese augenzwinkernde Bemerkung steht sinnbildlich für die Automatisierungsmaxime des Teams: Was wiederholbar ist, wird geskriptet. „Manuelles“ Testen gibt es nicht.

„So far, we don't have one single manual test.“

Für Tech-Talente ist das ein klares Signal: Hier gilt „Automate first“. Wer gerne mit Code die Qualitätssicherung vorantreibt, findet ein Umfeld mit konsequentem CI/CD-Fokus.

Testdesign unter Black-Box-Bedingungen: positiv, negativ, zustandsorientiert

Smartcards sind von außen betrachtet Zustandsmaschinen. Das Team muss diese Zustände gezielt ansteuern – und zwar nicht nur die „Happy Paths“. Besonders kritisch sind negative Pfade:

Falsche Kommandos oder Sequenzen
Korrekte Kommandos mit falschen Daten
Missbrauchsszenarien ohne Schutzmechanismen („You can do whatever you want with this card.“)

Das Testdesign spiegelt dies wider: Sicherheitsnahe Testszenarien müssen bewusst provozieren, was ein Angreifer tun würde – und verifizieren, dass keine sicherheitsrelevanten Informationen preisgegeben werden.

Die Reset-Strategie: robust bleiben, wenn etwas schiefgeht

Ein volles Testrun benötigt derzeit etwa dreieinhalb Stunden – Tendenz steigend. Ein einzelner früher Ausfall darf nicht das gesamte Ergebnis unbrauchbar machen. Daher setzt das Team auf eine dezidierte Reset- und Isolationsstrategie:

„Having a reset strategy in place to be able to reset the card and in fact, the whole test environment… and this failing test is then isolated and all subsequent tests are still executed.“

Ziele dieser Strategie:

Testumgebung in einen definierten, reproduzierbaren Zustand zurückführen
Kartenstatus sicher zurücksetzen
Bereits erfolgreich gelaufene Tests valide halten
Fehlende Abhängigkeiten vermeiden und Folgetests entkoppeln

In einem Black-Box-Umfeld ohne Debug-Schnittstellen ist diese Resilienz der Testinfrastruktur essenziell, um echte Coverage über viele Stunden und Szenarien zu schaffen.

Recruiting-Philosophie: Klarheit, kurze Interviews, Teamfit

Stephan Puri-Jobi betont zwei Punkte beim Recruiting:

1) Präzise Jobbeschreibungen: Erwartungshaltungen werden klar definiert, damit „die richtigen“ Kandidat:innen anklopfen.

2) Schlanke, angenehme Interviews: Technische Fragen gehören dazu, sind aber bewusst nicht „trickreich“. Entscheidend ist, ob jemand fachlich beitragen und kollaborativ Wissen teilen kann.

„Somebody with a big knowledge on technology is, of course, very valuable… but he has to be part of the team at the end… if somebody cannot contribute to the team and can't give his know-how to the others, then this… slows us down.“

Das ist eine klare Botschaft: Einzelkämpfermentalität schadet mehr, als dass sie nützt. Know-how muss im Team zirkulieren.

Onboarding und Mentoring: Zeit geben, gezielt fordern, gemeinsam prüfen

Die Einarbeitung ist strukturiert und empathisch – eine Kombination aus Trainingsmaterial, Mentoring und anfänglichen „Beginner Tasks“. Das Team weiß, wie anspruchsvoll die Domäne ist: ISO-Standards, viel Spezifikationsarbeit, Interaktionen zwischen Systemen. Eine steile Lernkurve ist eingeplant, und die Zeit dafür ist ausdrücklich vorgesehen.

„A new employee gets this time. This is quite important to us.“

Kernelemente des Onboardings:

Bereitgestellte Schulungen und Materialien für den schnellen Einstieg
Mentor:in als feste Anlaufstelle für die ersten Wochen
Einstiegsaufgaben, um System und Testcode praktisch zu verstehen
Code-Reviews und gemeinsames Lernen als Teamaufgabe

Das Ziel ist klar: Neue Kolleg:innen so schnell wie möglich befähigen, effektiv beizutragen – ohne unrealistische Erwartungen.

Zusammenarbeit: Transparenz, frühe Hilfe, geteilte Verantwortung

Dailies, Retros, Mentoring – das alles zahlt auf eine Kultur ein, die Blockaden früh auflöst und Verantwortung teilt. Niemand arbeitet isoliert. Die Fähigkeit, Wissen zu vermitteln und Fragen zu stellen, ist explizit Teil der Rolle. Das Team selbst sieht seinen Erfolg daran, wie schnell neue Mitglieder produktiv werden und wie stabil die Pipeline bei wachsenden Testumfängen bleibt.

Gründe, warum Tech-Talente hier andocken wollen

Für QA- und Testautomatisierungsprofis bietet dieses Umfeld mehrere starke Anreize:

100% Automatisierung: Keine manuellen Tests – wer gerne mit C#/.NET, NUnit, Jenkins, Groovy und Python arbeitet, findet eine klare Heimat.
Sicherheitskritische Domäne: Smartcards mit Black-Box-Charakter verlangen präzises, robustes Testdesign – inklusive negativer und adversarialer Szenarien.
Reife Agile-Praxis: SAFe-Workflows mit bewusst kurzen Dailies, messbaren Retros und realistischen Puffern in der Planung.
Lernorientierte Kultur: Mentoring, Zeit zum Ramp-up und Teamfokus beim Wissenstransfer.
Einfluss auf Arbeitsweise: In jeder Retros wird „mindestens eine Sache“ verändert und gemessen – ein echter kontinuierlicher Verbesserungsprozess.
Stabilitätsdenken in CI/CD: Reset-Strategie, Isolierung fehlerhafter Tests, lange, reproduzierbare Testruns.
Klare Rollen, klare Erwartungen: Aufgabenteilung zwischen Spezifikation, Implementierung und Automatisierung.

Für Entwickler:innen mit Testfokus, SDET-Profile und erfahrene QA Engineers ist das eine Kombination aus anspruchsvoller Technik, sinnstiftender Aufgabe (Sicherheit) und reifer Teamkultur.

Engineering-Praktiken zum Mitnehmen

Aus der Session lassen sich mehrere Prinzipien destillieren, die auch anderen Teams helfen können:

Black-Box ernst nehmen: Ohne Debug-Schnittstellen braucht es starke Orchestrierung von Zuständen und eine saubere Trennung von Triggern und Beobachtungen.
Negativtests zuerst denken: Sicherheitskritische Produkte müssen böswillige Pfade modellieren und prüfen – nicht nur Happy Paths.
Reset vor Retest: Eine definierte Strategie für das Zurücksetzen von Gerät und Umgebung macht lange, stabile Testruns möglich.
„Eine Änderung pro Sprint“: Kleine, kontrollierte Prozessänderungen sind messbar und rückholbar – gelebte kontinuierliche Verbesserung.
Puffer sind Pflicht: Sprintplanung ohne Reserve ist in QA/CI/CD ein Rezept für Instabilität.
Automatisieren als Haltung: Skripte statt Handarbeit – „lazy“ im besten Sinne des Wortes.
Onboarding als Teamsport: Mentoring, Materialien, Einstiegsaufgaben und Reviews sind ein kollektiver Hebel.

Herausforderungen, die das Team bewusst adressiert

Die Komplexität wird nicht beschönigt. Das Team hat klare Antworten auf harte Probleme:

Lange Laufzeiten (ca. 3,5 Stunden pro Testrun, Tendenz steigend): Pipeline-Resilienz und Testisolation.
Keine Einsicht ins Innere der Karte: Zustandssteuerung über Schnittstellen und präzises Beobachten des externen Verhaltens.
Adversariale Szenarien: Systematische, automatisierte Negativtests als Sicherheitsgarantie.
Hoher Wissensbedarf (ISO-Standards, Spezifikationsdichte): Strukturiertes Onboarding, Mentoring und Zeit zum Lernen.

Fazit: Ein starkes Beispiel für moderne, sicherheitsorientierte Testkultur

Die Session „Stephan Puri-Jobi, Software Test Lead von HID Global“ zeigt eine QA-Organisation, die Sicherheit, Automatisierung und Teamkultur konsequent zusammenführt. Mit klarer Rollenverteilung, SAFe-Abläufen, einer robusten Toolchain (C#/.NET, NUnit, TestRail, Jenkins, Groovy, Python) und einer kompromisslosen Black-Box-Teststrategie entsteht eine Umgebung, die für anspruchsvolle Tech-Talente hochattraktiv ist. Wer Freude an sauberer Automatisierung, negativen Testpfaden und stabilen CI/CD-Prozessen hat – und wer Wissen nicht hortet, sondern teilt – wird hier Wirkung entfalten.

„The sooner the new one is part of the team, the sooner he can contribute and help us then make our lives easier.“

Diese Haltung prägt das Team – und macht den Unterschied zwischen einer Testabteilung und einer echten, kollaborativen Engineering-Organisation.

Weitere Tech Talks

Weitere Dev Stories