52. TAV
Save the Date: 52. Treffen der Fachgruppe TAV am 19. und 20. März 2026 in Düsseldorf bei GEBIT Solutions!
Veranstaltungsort
GEBIT SolutionsOststraße 10
40211 Düsseldorf
Beschreibung
Das 52. Treffen der Fachgruppe TAV der Gesellschaft für Informatik (GI) findet am 19. und 20. März 2026 bei GEBIT Solutions in Düsseldorf statt und steht unter dem Motto: Funktion oder User Experience - was testen wir eigentlich?Gesucht werden speziell Beiträge zu den folgenden Themen:
Einreichungen sind aber auch zu allen anderen Themen mit Schwerpunkt Test, Analyse und Verifikation von Software erwünscht. | ![]() |
Die Kurzbeiträge wurden in den Softwaretechnik-Trends, Band 46, Heft 2 veröffentlicht.
Programm / Zeitplan
Donnerstag
Uhrzeit |
|
|---|---|
ab 9:00 | Ankunft und Registrierung |
10:00 | Eröffnung des Treffens |
11:00 | Kaffeepause |
11:15 | Barrierefreiheit testen Barrierefrei, aber bitte verständlich! Skalierung von automatisierten Accessibility Regressions-Tests |
12:45 | Mittagspause |
13:45 | Barrierefreiheit testen ff. Automatisierte vs. manuelle Tests von Barrierefreiheit am Beispiel von PDF Dokumenten Testautomatisierung mit KI Exploratives Testen mit KI – Unterstützung und Perspektiven |
15:15 | Kaffeepause |
15:30 | Testautomatisierung mit KI ff. Testautomatisierungslücke mit KI füllen – Erfahrungen aus dem ISTQB Glossary Projekt |
16:30 | Gamification in der Praxis / Demo Vom analogen Spielen zum digitalen Systemtest mit anschließendem Spiel und Test an realen Kassensystemen der GEBIT Solutions GmbH |
19:30 | Gemütliches Abendtreffen (unterstützt vom German Testing Board) |
Freitag
Uhrzeit | |
|---|---|
08:30 | Analyse From Rule Checking to Language Enforcement: An Empirical Analysis of MISRA-Style Compliance in Rust |
09:20 | Qualitätssicherung und KI - Perspektiven Interaktionsqualität für KI-Systeme |
10:05 | Kaffeepause |
| 10:20 | Fishbowl Was haltet ihr persönlich derzeit für die größte Herausforderung im Bereich Test, Analyse, Verifikation? |
10:50 | Ergebnisse der Arbeitskreise Treffen der TAV-Arbeitskreise |
12:30 | Mittagspause |
13:30 | Fortsetzung der Treffen der Arbeitskreise |
15:45 | Plenum: Ergebnisse der Arbeitskreise |
16:00 | Ende des TAV-Workshops |
Kurzfristige Änderungen möglich.
Wir danken allen Sponsoren für die lokale Organisation und Unterstützung der Veranstaltung.
Hinweise für Vortragende und Autoren, Fristen und Termine
Siehe Call for Paper.
Anmeldung
Die Anmeldung zur TAV erfolgt über folgenden Link. Die Teilnahme ist kostenlos und steht auch Nichtmitgliedern der Fachgruppe offen. Wie immer, setzen wir auch auf dieser TAV die Tradition fort, den ersten Tag mit einem gemütlichen Abendtreffen ausklingen zu lassen. Bitte registriert euch / registrieren Sie sich für ein kostenloses Ticket in Abhängigkeit, ob ihr / Sie an beiden Tagen teilnehmen werden oder nur am Donnerstag oder Freitag. Bitte vermerkt / vermerken Sie auch, ob ihr / Sie am gemeinsamen Abendessen am Donnerstag teilnehmen werden.
Anfahrt und Unterkunft
Siehe auch: https://www.gebit.de/kontakt/duesseldorf
Anreise per Bahn/Bus
Mit der Bahn bis Düsseldorf Hauptbahnhof fahren. Die GEBIT erreicht man von dort nach ca. 15 min Fußweg. Mit geringerem Fußweg ist die GEBIT mit Bus (Linie 737), Straßenbahn, U-Bahn oder S-Bahn zu erreichen. Die Buslinie 737 (Wehrhahn-Center) sowie die U-Bahnlinien U71, U72, U73 und U83 (Pempelforter Straße, Ausgang Oststraße) halten direkt vor dem Büro.
Anreise per Auto
Parkmöglichkeiten gibt es in der CONTIPARK Tiefgarage „Momentum“, die im gleichen Bürokomplex Momentum liegt (kostenpflichtig).
Anreise per Flugzeug
Ab Flughafen Düsseldorf fahren die S-Bahnlinien S1, S6, S11, S68 bis Düsseldorf Wehrhahn. Den Ausgang Grafenberger Allee nehmen, die GEBIT erreicht man von dort in ca. 8 min. Fußweg.
Unterkunft
Premier Inn Düsseldorf City Centre
Am Wehrhahn 80
40211 Düsseldorf
7 min Fußweg
Me and All Hotel Düsseldorf by Hyatt
Immermannstraße 23
40211 Düsseldorf
7 min Fußweg
25hours Hotel Das Tour
Louis-Pasteur-Platz 1
40211 Düsseldorf
10 min Fußweg
Hotel Motel One Düsseldorf Hauptbahnhof
Immermannstraße 54
40210 Düsseldorf
11 min Fußweg
Das Leitungsgremium der FG TAV freut sich auf Ihre / Eure zahlreichen Anmeldungen für die TAV 52 in Düsseldorf!
Dr. Dehla Sokenou
Mario Friske
Dr. Baris Güldali
Dr. David Farago
Sponsoren
Programm
Donnerstag 10 - 18 Uhr
Keynote
Christian Klaproth
Qualität beginnt an der Oberfläche
In der Eröffnungs-Keynote werden die Teilnehmenden eingeladen, den eigenen Qualitätsbegriff bewusst zu hinterfragen: Testen wir eigentlich nur Funktionen oder auch das Nutzungserlebnis? Ausgehend von der These „Qualität beginnt an der Oberfläche“ verbindet die Keynote klassisches Software-Testing mit UX-Design sowie Barrierefreiheit und greift die Perspektive der Nutzerinnen und Nutzer als oft härteste und ehrlichste Form des Testens auf. Sie dient als mentale Einstimmung auf zwei spannende Tage rund um Softwaretest und User Experience und soll dazu ermutigen, Qualität nicht nur als technisch korrekt, sondern auch als verständlich, zugänglich und akzeptanzfördernd zu betrachten.
Lilia Gargouri
Barrierefrei, aber bitte verständlich!
Digitale Barrierefreiheit betrifft mehr Menschen, als viele vermuten: Sie unterstützt nicht nur Menschen mit Behinderungen, sondern verbessert die Nutzbarkeit digitaler Angebote für alle. Dieser Vortrag richtet sich an Entwickler:innen, UX-Designer:innen, QA-Verantwortliche und Projektleitende, die ein fundiertes Verständnis für Barrierefreiheit aufbauen wollen – technisch, rechtlich und konzeptionell.
Ziel des Vortrags ist es, praxisnahes Grundlagenwissen zu vermitteln, häufige Barrieren sichtbar zu machen und ein strukturiertes Verständnis für gesetzliche Anforderungen und technische Standards zu schaffen – als Grundlage für qualitativ hochwertige, inklusive digitale Produkte.
Björn Scherer
Skalierung von automatisierten Accessibility Regressions-Tests
Barrierefreiheit ist mittlerweile verpflichtend für alle Endkunden Anwendungen und somit sind Accessibility Tests nicht mehr wegzudenken. An vielen Stellen wurde (und wird teilweise immer noch) viel Aufwand investiert, um Anwendungen barrierefrei zu gestalten.
Doch nach diesen "Hauruck" Aktionen stehen Unternehmen und Entwicklungsteams vor der Herausforderung, Barrierefreiheit nachhaltig in ihr Entwicklungs- & Test-Vorgehen zu integrieren und Accessibility Prüfungen zum Standard werden zu lassen. Auch wenn automatisierte Prüfungen nicht alle BFSG relevanten Kriterien abdecken können, bilden sie dennoch eine grundlegende Absicherung als Fangnetz.
Bei der Wartung und Erweiterung bestehender Systeme um neue Features, muss der mühsam erreichte Qualitätsstand erhalten bleiben und durch Regressionstests abgesichert werden. Doch wie kann das gelingen?
Gerade in komplexen, formularbasierten Anwendungen, deren diverse Masken und Zustände nicht einfach per URL angesprungen werden können, sondern nur über fachliche Use Cases erreichbar sind, ist dies eine echte Herausforderung.
Entsprechende Accessibility-Prüfungen müssen daher in funktionale Tests integriert werden.
Einzelne Checks sind einfach implementiert, aber wie skaliert man das auf längere Use Cases mit vielen Masken und Varianten? Hier gibt es viele States die durchlaufen und geprüft werden sollen.
Dieser Vortrag zeigt konkrete Strategien und Werkzeuge für Entwicklungsteams. Wir beleuchten wie Accessibility-Prüfungen in bestehende End-to-End-Tests integriert werden können, um nicht nur einzelne Checks durchzuführen, sondern auch kontinuierliche Barrierefreiheitstests zu ermöglichen, als fester Bestandteil des Entwicklungsprozesses – nachhaltig, effizient und mit minimalem Mehraufwand.
Baris Güldali, Lavinia Nimczewski
Automatisierte vs. manuelle Tests von Barrierefreiheit am Beispiel von PDF Dokumenten
Der Beitrag ordnet Barrierefreiheit als Subthema von UI/UX ein, das mit dem Barrierefreiheitsstärkungsgesetz ab 2025 für viele digitale Produkte verbindlich wird. Barrierefreiheit wird damit zu einer prüf- und nachweispflichtigen Qualitätseigenschaft von Software, Webanwendungen und digitalen Dokumenten. QA und Test spielen eine zentrale Rolle, da die zugrunde liegenden Standards eine Vielzahl testbarer Anforderungen definieren. Der Beitrag zeigt, dass automatisierte Tests nur einen begrenzten Teil dieser Anforderungen abdecken und durch manuelle Tests ergänzt werden müssen. Ein besonderer Fokus liegt auf der Prüfung von PDF-Dokumenten als Teil digitaler Geschäftsmodelle, einem in der Praxis häufig vernachlässigten Aspekt der digitalen Barrierefreiheit. Am Beispiel des PDF Accessibility Checker (PAC) wird deutlich, dass auch bei Dokumenten eine realistische Kombination aus automatisierten und manuellen Prüfungen erforderlich ist.
Matthias Hamburg
Testautomatisierungslücke mit KI füllen – Erfahrungen aus dem ISTQB Glossary Projekt
Dynamisches Testen umfasst Testanalyse, Testentwurf, Testrealisierung und Testdurchführung. Bis heute ist es nur sehr wenigen Teams gelungen, all diese Aktivitäten vollständig zu automatisieren. Der Bedarf an einem höheren Grad an Testautomatisierung wächst jedoch stetig aufgrund immer komplexerer Softwaresysteme, häufigerer Integration und Bereitstellung (CI/CD) sowie der Verbreitung von DevOps.
Herkömmliche Testautomatisierungswerkzeuge automatisieren nur die Testdurchführung. Modellbasiertes Testen (MBT) kann den Testentwurf automatisieren, wird jedoch aufgrund von Schwächen bei der Testrealisierung selten eingesetzt. Die größte Testautomatisierungslücke besteht jedoch bei der Testanalyse, der kreativsten Aktivität des dynamischen Testens. Deshalb stellt sich die Frage, ob KI die Lücken bei Testanalyse und Testrealisierung schließen kann, also ob eine geeignete Kombination aus generativer KI mit bestehenden Werkzeugen das dynamische Testen vollständig automatisieren kann, von der Testbasis bis zum Testergebnis.
Der Autor berichtet über eine solche Fallstudie aus seiner Praxis. Testobjekt war die ISTQB Glossary App, eine webbasierte Dialoganwendung. Das Hauptziel des Tests war es, das Image des ISTQB durch die Qualität seiner Glossary App zu wahren. Daraus ergab sich ein hoher Bedarf an Vertrauen in die funktionale Eignung. Die eingesetzte Werkzeugkette bestand aus dem Testautomatisierungswerkzeug Playwright, dem MBT-Werkzeug Harmony, und dem GenAI-System Claude Sonnet.
Die Anforderungen wurden in natürlicher Sprache dokumentiert. Zuerst musste die KI die Testbarkeit analysieren, um falsche Annahmen zu meiden. War die Testbasis testbar, generierte die KI-basierte Analysekomponente, die entsprechend in den ausgewählten Testverfahren trainiert war, Testmodelle. Hierbei war auch die Begründung (Reasoning) relevant. Die Modelle mussten darüber hinaus wiederverwendbare Schlüsselwörter auf Domänenebene verwenden, um die Automatisierung zu unterstützen. Aus diesen Modellen konnte dann das MBT-Werkzeug abstrakte Testfälle generieren, die von menschlichen Testern überprüft werden können.
Sobald das Testobjekt in der Testumgebung verfügbar war, kam die Testimplementierung. Dabei musste die generative KI Testdaten auswählen und die Schlüsselwörter auf Domänenebene den Objekten der Testschnittstelle zuordnen. Schließlich konnte sie die Testfälle durch das Testaitomatisierungswerkzeug ausführen lassen.
Der Autor teilt seine Erkenntnisse aus dieser Fallstudie.
Ralf Somplatzki
Vom analogen Spielen zum digitalen Systemtest
Ralf Somplatzki stellt einen Ansatz vor, wie mit Hilfe eines Brettspiels Testfälle praxisnahe Tests für die Gebit-Produkte gewonnen werden. In einer kurzen Präsentation wird der Weg von der Idee zum fertigen Spiel erläutert.
Anschließend haben alle Teilnehmenden die Gelegenheit mit dem Spielmaterial an realen Kassensystemen die Produkte der GEBIT Solutions GmbH zu testen.
Die spielerische Runde liefert Impulse, wie Tests nicht am Reißbrett generiert werden, sondern mit spielerischer Leichtigkeit und einem augenzwinkernden Blick auf die Wirklichkeit der User und Stakeholder.
Freitag 8:30 - 16 Uhr
Florian Werner, Andreas Wübbeke
From Rule Checking to Language Enforcement: An Empirical Analysis of MISRA-Style Compliance in Rust
In automotive embedded software development, compliance with safety-oriented coding standards such as MISRA C++ is traditionally ensured through external static analysis tools and manual code reviews. This approach introduces significant verification overhead and remains prone to residual defects, particularly in the presence of undefined behavior and concurrency errors. This paper investigates a fundamentally different compliance model enabled by the Rust programming language. Instead of retroactively checking rule violations, Rust enforces a subset of MISRA-style safety constraints directly at the language and compiler level. Based on an empirical evaluation of selected MISRA C++:2023 rules, we classify which rules become inherently enforced by Rust’s type system and ownership model, which remain applicable but require tool support, and which are no longer meaningful. We further evaluate the effectiveness of current Rust static analysis tools and demonstrate how these guarantees integrate into an automated CI pipeline. The results show a structural shift from tool-driven verification toward language-enforced safety, with significant implications for test, analysis, and verification strategies in automotive software engineering.
Heiko Frey
Exploratives Testen mit KI – Unterstützung und Perspektiven
Requirements basiertes Testen ist in vielen Organisationen der etablierte Standard, insbesondere in regulierten Entwicklungsumfeldern. Dennoch gilt als weitgehend anerkannt, dass eine reine Anforderungsabdeckung nicht ausreicht, um alle relevanten Fehler und Risiken eines Systems aufzudecken. Exploratives Testen stellt daher eine sinnvolle Ergänzung dar, um insbesondere bislang unbekannte Risiken („unknown unknowns“) zu identifizieren und die Gesamtqualität eines Systems zu erhöhen.
Exploratives Testen ist eine erfahrungsbasierte Testmethode, bei der Testdesign, Testausführung und Erkenntnisgewinn eng miteinander verzahnt sind. Anstelle vorab vollständig spezifizierter Testfälle nutzen Testingenieurinnen und ingenieure ihr Domänenwissen, ihren gesunden Menschenverstand sowie ihre praktische Erfahrung, um Testideen dynamisch zu entwickeln und während der Durchführung anzupassen. Ziel ist es, durch gezieltes Beobachten, Hinterfragen und Variieren von Eingaben auffälliges oder unerwartetes Systemverhalten zu identifizieren.
Vor dem Hintergrund aktueller Entwicklungen im Bereich Künstlicher Intelligenz stellt sich die Frage, in welchem Umfang exploratives Testen durch KI unterstützt oder sogar selbstständig durchgeführt werden kann. KI kann den explorativen Testprozess insbesondere in der Vorbereitung und Strukturierung unterstützen. Beispiele hierfür sind die Generierung von Testchartern und Testideen, die Ableitung potenzieller Risikobereiche aus vorhandenen Artefakten oder die Unterstützung bei Dokumentation und Zusammenfassung von Testergebnissen. Darüber hinaus können KI Systeme Muster in Testergebnissen erkennen und Hinweise auf Anomalien liefern, die für menschliche Tester nicht unmittelbar offensichtlich sind.
Gleichzeitig stößt der Einsatz von KI im explorativen Testen an konzeptionelle Grenzen. Exploratives Testen lebt vom Kontextverständnis, implizitem Wissen und situativer Bewertung. Der Kenntnisstand einer KI über das System under Test sowie dessen Nutzungskontext ist oft unvollständig oder nicht transparent. Entsprechend besteht die Gefahr, dass KI generierte Testideen lediglich bekannte Heuristiken reproduzieren, ohne tatsächlich neue Erkenntnisse zu liefern. Eine Bewertung und Einordnung der Ergebnisse durch erfahrene Testende bleibt daher unerlässlich.
Diese Aspekte werden im Beitrag anhand einer Fallstudie illustriert, in der exploratives Testen sowohl manuell als auch KI gestützt durchgeführt wurde. Ziel ist nicht der Vergleich einzelner Fehlertypen, sondern die Untersuchung der jeweiligen Stärken und Grenzen beider Ansätze.
Als Ausblick wird ein iterativer Ansatz diskutiert, bei dem KI gestützt erzeugte explorative Testergebnisse erneut durch KI analysiert und verfeinert werden. Dies eröffnet das Potenzial, den Erkenntnisgewinn pro Testsession zu erhöhen, macht jedoch zugleich deutlich, dass exploratives Testen auch künftig ein wesentlich von menschlicher Expertise getriebener Prozess bleibt.
Dehla Sokenou, Harald Störrle
Interaktionsqualität für KI-Systeme
KI-Systeme haben natürliche Sprache als Mensch-Maschine-Interface endgültig etabliert. Die Verwendung von geschriebener und gesprochener Sprache hat diese Systeme für eine breite Masse von Menschen nutzbar gemacht, die nicht unbedingt Experten sein müssen. Prompten kann jeder, vielleicht nicht jeder gleich gut. Sprache als Kommunikationsmittel ist uns in die Wiege gelegt, nun können wir mit diesem Mittel ohne Umwege IT-Systeme bedienen. Wir reden mit ChatBots und bevorzugen ein LLM gegenüber einer Suchmaschine.
Interaktionsanforderungen treten damit in den Vordergrund und stehen als querschnittlicher Aspekt den feingranularen funktionalen Anforderungen gegenüber. Das stellt uns auch in der Qualitätssicherung vor neue Herausforderungen. Was bedeutet Interaktionsqualität und wie bettet sie sich in klassische Softwarequalitätsmodelle ein? Wie können wir Interaktionsqualität messen und bewerten? Ist Sprache immer das richtige Mittel oder gibt es auch andere Interaktionsformen und wie gehen wir damit um? Welche Herausforderungen gibt es, wenn KI-Systeme multimodal sind?
Der Vortrag wird diese Fragen (noch) nicht abschließend beantworten und soll primär eine Diskussionsgrundlage bieten.
Treffen der Arbeitskreise
Anmeldung
- Kosten
- Kostenlos
- Hinweis
- Zu dieser Veranstaltung können Sie sich online anmelden.
- Anmeldefrist
- 09.03.2026
- Abmeldefrist
- 19.03.2026


