Testing auf allen Ebenen: Systematische Qualitätssicherung für eingebettete Credentials – Erkenntnisse aus „Testing on all Levels“ von Stephan Puri-Jobi (HID Global GmbH)

Kontext: Identität sicher beweisen – und warum Testen hier entscheidend ist

In „Testing on all Levels“ zeigte Stephan Puri-Jobi (Senior Lead Test Engineer im ID Tech Lab von HID Global GmbH) sehr klar, was es braucht, um eingebettete, sichere Geräte – konkret: Credentials – robust über ihre gesamte Lebensdauer zu testen. Puri-Jobi arbeitet in Graz, bringt 19 Jahre Erfahrung in Softwareentwicklung und Test (insbesondere für Embedded Devices) mit und leitet ein diverses Testteam von 15 Personen an vier Standorten. Die Palette reicht dort von Testspezifikation, Implementierung und Automatisierung bis hin zu CI/CD.

Die übergreifende Mission: sichere, interoperable Credential-Technologien vorantreiben, die auf Karten, Smartphones oder Wearables gleich zuverlässig funktionieren. HID Global ist in Austin, Texas, ansässig, hat über 4.000 Mitarbeitende weltweit und Büros in 100 Ländern; als Teil von Assa Abloy (51.000 Mitarbeitende) arbeiten die Teams an Lösungen wie Physical Access Control, Identity & Access Management, Citizen ID und Identifikationstechnologien.

Puri-Jobi bringt den Kern auf den Punkt: Credentials dienen dem sicheren Nachweis der Identität – sie enthalten Schlüssel, verschlüsselte Daten und setzen auf standardisierte Kommunikationsmuster. In seinem Talk bildet diese Realität den roten Faden: Wie testet man eine Credential-Implementierung, die als Karte mit RFID funktioniert, aber auch als digitale Variante auf dem Smartphone? Und wie erreicht man dabei belastbare Qualität über extrem heterogene Zielplattformen?

Was ist ein Credential – und wo liegt die technische Herausforderung?

Ein Credential ist eine Technologie zum Identitätsnachweis – mit Kryptografie, Schlüsseln und verschlüsselten Daten. Die Interaktion erfolgt typischerweise über APDUs gemäß ISO 7816; das „Common Set“ umfasst dabei Kommandos wie Select, Authenticate, Get Data und Put Data.

Wichtige Einsicht: Ein Credential kann ganz unterschiedlich aussehen – als RFID-Karte (Hotel, Bezahlung, Ausweis, Führerschein) oder als digitale Entsprechung in einem Smartphone. Genau hier beginnt die Test-Herausforderung: Eine einzige Credential-ID soll über verschiedene Träger hinweg konsistent funktionieren, obwohl die Plattformen und Sprachen massiv differieren – auf der Karte meist C mit kleinem Prozessor, wenig RAM, Kryptokoprozessoren und nichtflüchtigem Speicher; auf dem Smartphone Java, Swift oder Kotlin. Reuse auf niedriger Ebene ist kaum möglich – eine besondere Randbedingung für jede Teststrategie.

Vom Requirement zur Testidee: statische Analyse statt Interpretationslücken

Bevor die erste Zeile Code entsteht, startet im ID Tech Lab die Qualitätssicherung bei der Quelle: dem Product Requirement Specification (PRS). Es beschreibt das Soll-Verhalten des Credentials. Schon hier setzt das Team auf „statisches Testen“ in Form von Reviews:

• Anforderungen verstehen und verknüpfte Interaktionen identifizieren
• Testfälle aus Anforderungen ableiten
• Lücken, Unschärfen und Unter-Spezifikation erkennen und rückmelden

Puri-Jobi adressiert eine bekannte Falle: Gibt man ein PRS direkt in die Entwicklung, besteht die Versuchung, unklare Stellen „aus dem Bauch“ zu implementieren. Testing denkt anders: Ein Test braucht einen klaren Startzustand und eine klare Erwartung. Fehlt diese, wird sofort zurück in die Spezifikation gespielt. Die frühe Reviewphase spart spätere Schleifen – und verhindert, dass implizite Annahmen in Code einfließen.

Testebenen pragmatisch gedacht: Unit, Komponenten-Integration, System

Viele kennen die „Testing-Pyramide“, deren Fundament Unit-Tests sind. Puri-Jobi bestätigt das Prinzip – ordnet es aber pragmatisch für eingebettete Credentials ein: Echtweltdruck, Produktzeiträume und Plattformvielfalt erfordern Abwägungen.

Unit-/Komponentenebene: gezielt, aber begrenzt wiederverwendbar

• Unit-Tests prüfen isolierte Funktionen mit Mocks und Testtreibern.
• Komponenten-Integrations-Tests verbinden Funktionen und reduzieren Mocks; Beispiel: einen kryptografischen Algorithmus wirklich aufrufen und die Rückgabewerte prüfen.
• In beiden Fällen gilt: Tests sind stark sprach- und hardwaregebunden (C auf Karte vs. Java/Swift/Kotlin auf Phone). Reuse über Implementationen hinweg ist gering. Die Folge: Der Anteil an Tests auf diesen Ebenen wird bewusst schlank gehalten.

Das heißt nicht, dass diese Ebenen unwichtig sind. Aber dort investiert man fokussiert – und setzt auf die Ebene, auf der alle Implementationen zusammenlaufen, um Breite und Tiefe effizient zu erreichen.

Systemtests: die gemeinsame APDU-Schnittstelle als Dreh- und Angelpunkt

Der große Hebel liegt in Systemtests, denn alle Credential-Varianten – Karte, Smartphone, Wearable – teilen eine gemeinsame APDU-Schnittstelle. Genau hier setzt das Testbench-Design im ID Tech Lab an: über das standardisierte „Common Set“ auf der RFID-Kommunikation.

• Der Testbench implementiert die PRS-Anforderungen und verfolgt damit ein konsequent requirements-basiertes Testen.
• Ziel ist eine vollständige Abdeckung der Anforderungen – mit positiven und negativen Testfällen.

Diese Ausrichtung erlaubt es, dieselben Tests gegen verschiedene Zielplattformen zu fahren – ein massiver Produktivitätsgewinn gegenüber fragmentierter Unit-/Integrationslogik pro Sprache und Hardware.

Requirements-basiertes Systemtesten: positiv, negativ, vollständig

Puri-Jobi differenziert klar: Positive Tests prüfen den richtigen, spezifikationskonformen Weg; negative Tests alles außerhalb der Spezifikation – auch böswillige oder fehlerhafte Nutzung.

Positive Tests: Standardpfade, aber mit Wert

• Typische Sequenz: Select des Credentials, Get Data auf vorhandene Objekte, Vergleich mit zuvor personalisierten Werten.
• Technik: Boundary-Value-Analyse und Äquivalenzklassenbildung, um aussagekräftige Wertkombinationen zu wählen.

Eine Beobachtung aus dem Alltag: Entwickler prüfen beim Implementieren oft „sichere“ Mittelwerte – bei einem Bereich 1–10 etwa 5–7. Das reicht selten, um Implementierungsfehler zu enttarnen. Daher fokussiert das Testteam bewusst auf Ränder wie 1 und 10.

Negative Tests: Angriffsflächen schließen

• Alles, was nicht intendiert ist: ungültige Kommandonutzung, zu große/zu kleine Daten, Werte außerhalb der Spezifikation.
• Ziel: Die Karte muss in jedem Szenario den korrekten Fehlerstatus liefern, keine Information leaken, keine Geheimnisse preisgeben.
• Empirie aus dem Team: Das Verhältnis positiver zu negativer Tests liegt etwa bei 1:4 – pro positivem Test kommen vier negative hinzu, um eine Anforderung abzusichern.

Diese Breite adressiert reale Felderfahrungen: Eine Karte ist ungeschützt im Feld, ein Angreifer kann „alles“ probieren. Negative Tests sind damit Sicherheitsarbeit – nicht nur Qualitätsarbeit.

Simulator vs. echte Hardware: Geschwindigkeit, Einsicht, Realität

Systemtests laufen nicht nur auf der Zielhardware. Simulatoren bringen Tempo und Transparenz:

• Sie ermöglichen Gray-Box-Tests mit Code-Coverage, sodass ungetestete Pfade sichtbar werden und gezielt per Review oder statischer Analyse adressiert werden können.
• Besonders in Android-Ökosystemen ist die Simulationsunterstützung stark: schnell, genau, IDE-nah.

Aber: Ein Simulator bleibt ein Simulator. Für die Smartcard-Welt (C, kompakter Build-/Download-Zyklus, begrenzte Ressourcen) ist die Schleife „kompilieren → auf Karte oder Emulator laden → testen“ spürbar langsamer.

Konsequenz im ID Tech Lab: Frust beim Entwickeln verringern, indem möglichst viel auf Systemebene konsolidiert getestet wird – über die gemeinsame APDU-Schnittstelle. Simulatoren liefern Geschwindigkeit und Abdeckungshinweise; finale Qualitätssicherung braucht dennoch die Validierung auf echter Hardware.

Nicht-funktionale Tests: Analoge Performance, Timing, Speicher

Funktionale Korrektheit ist das Fundament. Doch für den Einsatz im Feld sind nicht-funktionale Eigenschaften ebenso kritisch. Puri-Jobi nennt drei Schwerpunkte:

1) Analoge Performance der Karte

• Die Karte ist passiv und bezieht Energie aus dem Feld. Relevant ist die Feldkopplung und Modulation: Wie nah muss die Karte an den Leser, damit eine Transaktion zuverlässig gelingt?
• Diese Messungen sind hardwareabhängig und nur mit echter Karte sinnvoll.

2) Timing in der Interaktion

• Wie lange dauert es, bis eine Tür öffnet, ein Polizeibeamter eine Fahrerlaubnis verifiziert oder eine Zahlung bestätigt ist?
• Je nach Use Case variieren die Toleranzen, aber das Ziel ist gleich: Zeitverhalten klar messen, dokumentieren und optimieren.

3) Speicherverbrauch und Speicherhygiene

• Auf dem Smartphone ist Speicher oft großzügig, auf der Karte zählt jedes Kilobyte RAM.
• Prüfziele: RAM- und NVM-Verbrauch beobachten, saubere Objektanlage/-löschung sicherstellen, keine Ressourcenlecks.

Zusätzlich verankert das Team Tests zu Sicherheitsfeatures und Gegenmaßnahmen gegen Angriffe – inklusive eines Themas, das nur bei passiv versorgten Karten auftritt: Anti-Tiering.

Anti-Tiering: Datenintegrität trotz plötzlichem Power-Off

„Tiering“ (so formuliert im Talk) entsteht, wenn während eines Schreibvorgangs die Energieversorgung der Karte abreißt – etwa weil sie aus dem Feld genommen wird. Die Karte ist komplett vom Feldstrom abhängig. Wird ein Schlüsselupdate im falschen Moment unterbrochen, könnte der Schreibprozess unvollständig bleiben. Das Testziel:

• Sicherstellen, dass die Implementierung niemals einen inkonsistenten Zustand hinterlässt.
• Entweder sind die neuen Daten vollständig persistent – oder die alten Daten bleiben vollständig erhalten.

Das Team verfügt über Testfälle und Methoden, um diese Robustheit gezielt zu verifizieren. Für Kartenhersteller ist das ein Muss – denn Datenkonsistenz ist unmittelbar sicherheitskritisch.

Systemintegration: Personalisierung, Leser, Interoperabilität und Dauerlast

Nach erfolgreichem Systemtest im Team geht es einen Schritt weiter: in die unternehmensweite Integration mit anderen Einheiten. Der Grund: Im Feld kommen Credential, Personalisierung und Leser-Hardware selten aus einer Hand.

• Im Testlabor personalisiert das Team die Karte selbst (Schlüssel und Daten aufbringen) und validiert das Verhalten über APDUs.
• Realistisch ist jedoch, dass ein Hotel oder eine Organisation die Personalisierung vornimmt, während das Lesegerät aus einer anderen Business Unit stammt.

Folgende Prüfziele stehen auf Systemintegrationslevel an:

• Interoperabilität: Viele verschiedene Karten, Credentials, Telefone und Leser müssen reibungslos zusammenspielen.
• Endurance: Wie oft kann die Karte an den Leser gehalten werden, bevor Material oder Elektronik nachlassen?
• User Experience: Wie lange dauert ein erfolgreicher Lesevorgang? Gibt es ungünstige Winkel oder Positionen, die Probleme bereiten?

Hier zeigt sich der reale Einsatzkontext – und damit die Kernfrage, ob das Gesamtprodukt bereit für den Markt ist.

Was wir als DevJobs.at besonders mitgenommen haben

Stephan Puri-Jobi zeichnet ein klar strukturiertes, praxisnahes Bild von Testen im Embedded-Sicherheitsumfeld. Einige Kernsätze, die aus unserer Sicht sofort anwendbar sind:

• Beginnt beim PRS. Eine saubere, frühe Review verhindert Interpretationslücken und spätere Rewrites.
• Investiert dort, wo Tests maximal wiederverwendbar sind: auf Systemebene über die gemeinsame APDU-Schnittstelle.
• Positive Tests sind notwendig – aber negative Tests sichern ab. Das 1:4-Verhältnis verdeutlicht den realen Bedarf.
• Boundary-Value-Analyse und Äquivalenzklassen sind nicht „nice to have“, sondern effektiv, um reale Fehler zu provozieren.
• Simulatoren sind Turbo und Lupe (Coverage, Gray Box), echte Hardware ist die Realität. Beides gehört zusammen.
• Nicht-funktionale Anforderungen (analoges Verhalten, Timing, Speicher) sind für Karten essenziell – unterschätzt sie nicht.
• Anti-Tiering ist keine Option, sondern Pflicht – insbesondere bei passiv versorgten Medien.
• Denkt in Ende-zu-Ende-Szenarien: Personalisierung, Leser, Interoperabilität, Dauerlast und UX sind integraler Bestandteil des Testziels.

Konkrete Anwendungsschritte für Engineering-Teams

Aus dem Talk lassen sich Vorgehensweisen ableiten, die sich auf andere Embedded-Testkontexte übertragen lassen – immer strikt im Rahmen der gehörten Inhalte:

1. Anforderungen operationalisieren

• PRS früh reviewen, Begriffe klären, Grenzfälle identifizieren.
• Pro Anforderung: klare Pre-/Postbedingungen definieren.

1. Testdesign an der Schnittstelle ausrichten

• Gemeinsame, standardisierte Schnittstellen (hier: APDUs nach ISO 7816) als Testanker nutzen.
• Testbench so bauen, dass sie direkt die PRS-Anforderungen abbildet.

1. Positiv- und Negativpfade ausbalancieren

• Pro positivem Test mehrere negative auslegen, inkl. ungültiger Längen, Werte und Sequenzen.
• Grenzen gezielt auswählen (1 und 10 statt nur 5–7 im Beispielbereich).

1. Simulator und Hardware kombinieren

• Simulator für Geschwindigkeit und Coverage-Transparenz einsetzen (Gray Box, ungetestete Pfade identifizieren).
• Kritische Messungen immer auf echter Hardware bestätigen – besonders analoges Verhalten und Timing.

1. Ressourcen und Robustheit messen

• RAM-/NVM-Verbrauch und Speicherhygiene explizit überprüfen.
• Anti-Tiering-Tests definieren, die unterbrochene Schreiboperationen simulieren und den resultierenden Zustand validieren.

1. Systemintegration planen

• Personalisierungsprozesse, Leserhardware und verschiedene Credential-Formate in die Testmatrix aufnehmen.
• Interoperabilität, Endurance und UX unter realitätsnahen Bedingungen prüfen.

Zitate und Gedankenstützen aus dem Talk

Einige Aussagen von Puri-Jobi bleiben hängen – als Leitplanken für Tests im Credential-Umfeld:

• „Spoiler alert. We do some testing … on all different levels.“ – Mehrstufiges Testen ist kein Luxus, sondern Notwendigkeit.
• „We really do a requirements-based testing here.“ – Die Anforderungen sind der Testplan.
• „We cannot reuse it …“ – Unit-/Komponenten-Tests sind wichtig, aber die Wiederverwendbarkeit entscheidet über den Fokus.
• „This is really annoying … very frustrating.“ – Embedded-Test-Workflows müssen Produktivität mitdenken.

Fazit: Ein Systemtest-getriebenes Testmodell für heterogene Credentials

„Testing on all Levels“ zeigt, wie ein Team die Testpyramide für einen hochheterogenen, sicherheitskritischen Kontext pragmatisch interpretiert: mit einem klaren Schwerpunkt auf Systemtests über die gemeinsame APDU-Schnittstelle, flankiert von gezielten Unit-/Integrationsprüfungen, einer konsequenten Mischung aus positiven und negativen Testfällen und einer bewussten Aufteilung zwischen Simulator-Tempo und Hardware-Realität.

Für eingebettete Credentials – ob Karte, Telefon oder Wearable – ist das aus unserer Sicht ein tragfähiger Pfad: frühe PRS-Klarheit, wiederverwendbares Systemtestdesign, strikte Negativtests, Anti-Tiering-Sicherung und echte Systemintegration mit Personalisierung und Lesern. So wird aus „Testing auf allen Ebenen“ ein belastbares Qualitätsversprechen, das im Feld hält, was es im Labor beweist.

• 

  

  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
• 

  

  Stephan Puri-Jobi, Software Test Lead bei HID Global

  Stephan Puri-Jobi von HID Global redet im Interview über seine Anfänge im Programmieren bis hin zum Software Testing, was seine Arbeit beinhaltet und gibt Tipps für Neueinsteiger.

  Jetzt ansehen