What is the difference of a test architect to a commonly known software architect? And why do I need one? What do they have in common and where do they differ? Is there a gap where we need a bridge (Spoiler: yes)? What are the different expectations of other roles on a test architect?

Questions over questions which will be covered in this talk. With examples where it did go well because there was a test architect and examples where things got haywire maybe because a test architect was missing.

And you will also not be left alone with these questions:

• How can I become such a person which is able to be a test architect.
• How can I establish that role in my organization.

You will get input how we did this at Siemens and build up a living network of test architects.

Target Audience: Testers, Developers, Architects, Project Leads, Test Managers, Team Leads
Prerequisites: Architecture knowledge, challenges in software projects, basic testing knowledge
Level: Advanced

The objective of visual test automation is replace flaky and hard to read selectors with images. Many software packages offer the possibility of using images as selectors, but it rarely works reliably. Appium has the function "findElementByImage," Playwright has functions like "toHaveScreenshot." Code and no-code tools alike provide a number of options to tweak the sensitivity, where both, too low and to high values, produce their own set of artefacts. What makes this so difficult? Doesn't AI provide the solution to reliably compare two images? Wouldn't source code be much more readable if it showed the image of the item, rather than just a file name or its xpath?

Target Audience: Experienced test automators in code and no-code
Prerequisites: Images, test automation, CNN, AI
Level: Expert

Nachdem lange Jahre zunächst Selenium und dann Cypress den Markt der Web-Testwerkzeuge beherrscht haben, kommen inzwischen neue Player auf das Spielfeld. Mit Playwright und WebdriverIO bekommt insbesondere Cypress eine starke Konkurrenz. Beide stellen sich nicht nur im Bereich der End2End-Tests auf, sondern besetzen auch das Feld der Komponententests. Auch in anderer Hinsicht sind sie Cypress ebenbürtig.

Der Webentwickler hat erneut die Qual der Wahl. Welches Werkzeug passt am besten zur eigenen Arbeitsweise, zum Projekt und zum Softwareprodukt? Wo liegen die Stärken und Schwächen der Gegenspieler? Und lassen sich bestehende Testsuiten einfach auf ein anderes Werkzeug migrieren? Wir werfen einen vergleichenden Blick auf die drei Kontrahenten und demonstrieren ihre Fähigkeiten in Aktion.

Zielpublikum: Tester, Testmanager, Testautomatisierer, Web-Entwickler
Voraussetzungen: Grundlegende Kenntnisse von Web-Entwicklung, TypeScript, Testautomatisierung
Schwierigkeitsgrad: Advanced

Nach Vorfreude auf den AI-Coding-Assistant kam Ernüchterung: Viele Vorschläge waren unbrauchbar, es wurde zu viel „halluziniert“. Wir fragten uns, ob es der richtigen Technik bedarf. Wir experimentierten mit Techniken (Chat-Assistant, Auto-Completion, Comment-driven) und Vorgehensweisen (Chat-first, Code-first, Test-first, TDD).

Dieser Vortrag konzentriert sich auf TDD mit AI-Coding-Assistants. Wir erläutern die Vorgehensweise von AI-Coding-Assistants, erklären Begrifflichkeiten, Einschränkungen, Ansätze und demonstrieren das Vorgehen mit Live-Coding. Wir versuchen, Grenzen der AI-Assistants auszuloten: Verbesserte Code-Completion oder Pair-Programming-Partner.

Zielpublikum: Entwickler:innen
Voraussetzungen: Grundkenntnisse in Programmierung
Schwierigkeitsgrad: Basic

Bei langlebiger Software lauern die meisten Fehler in dem Code, der kürzlich verändert wurde. Das zeigen empirische Forschungsarbeiten seit Langem und unser Bauchgefühl sagt uns das vermutlich noch viel länger.

Viele Teams setzen daher die sogenannte Test-Gap-Analyse ein, die Test-Gaps (ungetestete Änderungen) automatisiert aufdeckt. Unsere Erfahrung zeigt jedoch, dass oft mehr Test-Gaps gefunden werden, als (rechtzeitig) getestet werden können.

Im Vortrag stellen wir einen risikobasierten Ansatz zur Priorisierung von Test-Gaps vor, in den mehrere Dimensionen der Code-Änderung einfließen (u.a. Zentralität im Abhängigkeitsgraph, Komplexität der Änderung, Findings-Churn). Wir haben den Ansatz empirisch validiert und stellen die Ergebnisse für acht Systeme der Munich Re und der LV 1871 vor.

Zielpublikum: Tester, Test-Manager, Testautomatisierer, Entwickler, Architekten
Voraussetzungen: Interesse an Software-Qualität und Testen
Schwierigkeitsgrad: Basic

Es gibt eine große Zahl an Werkzeugen, die Qualitätsprobleme in Bestandscode mittels statischer Analyse erkennen und sichtbar machen. Die automatische Behebung dieser Probleme war bisher aber nur in vergleichsweise einfachen Fällen möglich. Die derzeitigen Entwicklungen in der künstlichen Intelligenz, speziell die Large Language Models (LLMs), verschieben die Grenzen des Möglichen jedoch deutlich.

In diesem Vortrag möchte ich auf Basis eines hierfür erstellten Benchmarks aufzeigen, wie weit sich Qualitätsprobleme heutzutage durch KI beheben lassen. Neben Erfahrungen aus unserer internen Entwicklung möchte ich auch beleuchten, welchen Einfluss die Wahl des Basismodells hat, welche Informationen die LLMs dabei als Input benötigen und an welchen Problemen die KI heute noch scheitert.

Zielpublikum: Architekten, Entwickler, Projektleiter
Voraussetzungen: Interesse an Software-Qualität und KI
Schwierigkeitsgrad: Basic

Es gibt viele Tools, die AI nutzen, um uns in der Softwareentwicklung zu assistieren. Einige generieren Code oder Testfälle, andere schlagen Code-Verbesserungen vor oder selektieren Tests auf Basis von Code-Änderungen uvm.

Leider wissen wir wenig darüber, welche Fehler diese AI-Assistenten sporadisch oder häufig machen. Allerdings müssen wir uns vermutlich darauf einstellen, dass sie in allen Phasen der Softwareentwicklung Einzug halten werden, alleine schon deshalb, weil sie bequem sind.

In diesem Vortrag möchte ich darüber sprechen, wie wir dieser Herausforderungen aus Sicht der Qualitätssicherung begegnen können und welche automatisierten Analysen ergänzend oder begleitend zu AI-Tools eingesetzt werden können, um dem Risiko ihres Einsatzes zu begegnen.

Zielpublikum: Entwickler, Architekten, Manager
Voraussetzungen: Interesse an Qualitätssicherung, Code-Analysen und AI-Assistenten
Schwierigkeitsgrad: Basic

BDD is not new, but is very useful. If you have never used it before, or have tried and it didn't work, this session will give a good grounding to using BDD successfully. We'll cover the basics, working through some examples and discuss how to succeed.

We will focus on the process, learning how to write scenarios and have a brief glimpse at what happens under the hood. We'll also think about helping everyone engage with testing.

If you want more people to get involved in testing and need ideas, come along. I'll tell you about my experiences and what has and hasn't worked. You can share your experience too, so we can all go away ready to test, think and communicate better.

Target Audience: Developers, testers, business or product owners
Prerequisites: An awareness of automatic testing
Level: Advanced

Ab Juni 2025 müssen in der EU viele digitale Produkte barrierefrei sein. Eines der großen Probleme bei der Umsetzung: der Testaufwand. Viele Dinge müssen von Hand überprüft werden, denn die automatischen Prüftools haben nur eine geringe Abdeckung. Wir Entwickler haben aber gerne ein Sicherheitsnetz von automatisierten Tests in der Pipeline. Wie können wir das für Barrierefreiheit erreichen?

In diesem Vortrag gebe ich euch das Handwerkszeug, um euch in Hinblick auf Barrierefreiheit besser abzusichern. Dabei lernen wir zunächst automatische Tools und ihre Möglichkeiten und Grenzen kennen. Danach schauen wir auf Strategien zum Schreiben eigener Tests mit gängigen Testframeworks. Abschließend schauen wir uns an, was AI in dieser Hinsicht für uns leisten kann.

Zielpublikum: Entwickler
Voraussetzungen: Grundkenntnisse in Webentwicklung
Schwierigkeitsgrad: Advanced

Am Anfang eines Projekts ist die Produktivität hoch. Architektur, Bausteine und Abhängigkeiten sind klar definiert. Doch mit der Zeit wird der Code immer umfangreicher und die Anforderungen werden komplexer. Es schleichen sich ungewollte Abhängigkeiten ein. Code und Architekturdiagramme passen nicht mehr zusammen.

Architekturtests wirken dem entgegen. Sie funktionieren wie Unit Tests, testen aber Anforderungen an die Architektur. Sie laufen automatisiert im Continuous Build und verhindern dadurch, dass sich Verstöße gegen die anfangs aufgestellten Architekturregeln einschleichen.

Der Vortrag gibt einen Überblick über die Möglichkeiten von Architekturtests und demonstriert anhand einer Beispielarchitektur, wie sich verschiedene Aspekte der Architektur testen lassen. Der praktische Anteil des Vortrags ist sehr hoch. Die Teilnehmer sind nach dem Vortrag in der Lage, das neu erworbene Wissen umgehend in eigenen Projekten praktisch anzuwenden.

Zielpublikum: Architekten und Entwickler
Voraussetzungen: Softwarearchitekturgrundlagen, Grundkenntnisse in .NET
Schwierigkeitsgrad: Advanced

Generative AI is a powerful asset if you know how to tame it. As this technology rapidly transforms the software landscape, one of the key challenges lies in effectively testing and validating GenAI applications. Traditional testing methodologies fall short in addressing the unique complexities posed by these systems, especially in enterprise environments.

Drawing from real-world experiences and hard-earned insights, we'll explore how to adapt established software engineering principles to the world of GenAI, and where entirely new approaches are necessary. Key topics include:

• Strategies for testing non-deterministic outputs
• Which metrics to choose and how to cope with conflicting metrics
• Unit-Tests vs End-To-End-Tests in the World of GenAI
• How to evaluate the evaluators: Aligning automatic evaluation with human evaluation
• Techniques for evaluating model hallucinations and biases
• Approaches to performance and scalability testing for GenAI systems
• Methods for ensuring data privacy and security in AI-driven applications
• Practical tools and frameworks for continuous testing in GenAI pipelines

Attendees will gain actionable knowledge on implementing robust testing practices for GenAI applications, bridging the gap between traditional QA and the demands of modern AI systems. This session is essential for developers, QA engineers, and technical leaders navigating the complexities of deploying GenAI in production environments.

Target Audience: AI engineers, software engineers, architects, and stakeholders working with GenAI applications
Prerequisites: Attendees should have a foundational understanding of AI
Level: Advanced