Du hast Fragestellungen, die du mit anderen Testinteressierten diskutieren möchtest? Du möchtest mit deiner Erfahrung anderen Personen eine Perspektive auf Fragen anbieten? Dann bist du beim Lean Coffee genau richtig. Denn im Lean Coffee bestimmt die Gruppe, welche Themen für wie lange diskutiert werden, um den maximalen Nutzen des Austauschs zu erreichen. 

Lean Coffee ist ein strukturiertes agenda-loses Meeting-Format, bei dem die Teilnehmer:innen die Tagesordnung durch die Themen, die sie einbringen, selbst bestimmen. Trete in den Austausch mit Gleichgesinnten und diskutiere die aktuellen Themen rund um das Thema „Testen", „Qualität“ oder was auch immer in diesem Moment gerade wertvoll ist.

Um die Auswahl zwischen den parallel laufenden Vorträgen und Workshops zu vereinfachen, geben die Sprecherinnen und Sprecher einen kurzen Teaser zu Ihrer Session. 

Purposeful Testing is a game-changer: it's about making every test count, not just for catching bugs, but for building better products and stronger teams. In this talk, we'll tackle common misconceptions, share real-life examples, and dive into how this approach can streamline your processes, boost team morale, and increase customer satisfaction. Join us to transform your testing strategy into a critical tool for company success, with actionable insights and proven strategies.

Die Raiffeisen Bank International hielt lange an der Überzeugung fest, dass Testautomatisierung Softwareentwicklung ist. Also Code-Schreiben. Doch ein unkonventioneller Testathon mit Low-Code/No-Code-Tools änderte alles. Zwei Produktverantwortliche – ohne Programmiererfahrung – automatisierten in Minuten Testfälle mit einer LC/NC-Test-Platform. Das führte zu einem Proof of Concept für zwei SAS-Anwendungen (Jira/GitHub), bei dem ein Ferienpraktikant ohne Programmiererfahrung erfolgreich die gesamte Regressions-Test-Suite automatisierte. Der Vortrag teilt die Erkenntnisse aus diesem Projekt und wie eine Paradigmenwechsel hin zu TestOps stattfand.

Zielpublikum: Produkt-Manager, Software-Entwickler, Tester, jeder der sich mit dem Thema Test Automation für Nicht-Techniker auseinandersetzen will
Voraussetzungen: Keine
Schwierigkeitsgrad: Basic

Building secure and reliable software is an essential and challenging endeavor that requires extensive testing. Due to development teams' time and resource constraints, testing falls short, and necessary tests are even skipped altogether. Feedback-based fuzzing is the most practical dynamic testing method to find bugs and security vulnerabilities in software. In this talk, I'll provide an overview of fuzzing and show how we can leverage large language models to generate the test harnesses needed for fuzzing automatically. This enables an automated and scalable testing strategy for modern software.

Target Audience: Developers, testers, engineering managers, CTOs
Prerequisites: Basic knowledge of Java
Level: Basic

Extended Abstract:
Dynamic testing methods, including feedback-based fuzzing, are the most effective approach for finding software bugs and security vulnerabilities. Fuzzing has uncovered thousands of bugs and vulnerabilities in both open-source and enterprise software. The self-learning aspect of feedback-based fuzzing makes it suitable to integrate into the development process to provide quick feedback to developers, thus enabling them to fix them quickly. Despite this incredible track record, one barrier has been left hindering the broad adoption of dynamic white-box testing: The manual engineering effort required to identify relevant interfaces and develop the corresponding test harnesses. In this talk, I'll provide an overview of feedback-based fuzzing and show how it can automatically uncover functional and security issues. I will also discuss the self-learning aspect of automatically generating test cases that explore the program and maximize code coverage. Next, I'll address the overhead of writing test harnesses for fuzzing and show how we can leverage the code generation capabilities of large language models to automate this step. This opens the door to building an automated and scalable testing strategy for our software. I'll demonstrate the discussed approach in a live demo.

Die Autoren stellen ein neues Verfahren zum modellbasierten Testen vor. Das Verfahren verbessert die Effektivität und Effizienz von GUI-Tests erheblich, insbesondere bei DevOps. Zuerst werden die Probleme der heutigen MBT-Ansätze analysiert. Anschließend wird das neue Verfahren vorgestellt, das diese Probleme löst. Dabei wird in der ersten Phase ein abstraktes, aber für Tester leicht verständliches Testmodell entworfen. Die zweite Phase dient der effizienten werkzeuggestützten Testimplementierung. Veranschaulicht wird das Verfahren mit einem Fallbeispiel aus der eigenen Praxis mit dem MBT-Tool Harmony und dem Automatisierungstool PlayWright.

Zielpublikum: Fachtester, Testanalysten, GUI-Tester, Testmanager, DevOps-Tester, MBT-Spezialisten
Voraussetzungen: Grundlagen des Testens
Schwierigkeitsgrad: Advanced

Extended Abstract:
Die geschätzten jährlichen Kosten von Softwareproblemen in den USA übersteigen eine Billion Dollar. Die Ausgaben für die Fehlerbehebung machen etwa 20 % der gesamten IT-Kosten aus und belaufen sich weltweit auf viele weitere Milliarden Dollar in nur einem Jahr. Ein Großteil dieser Verluste ist nicht auf die inhärente Schwierigkeit zurückzuführen, Softwarefehler zu finden, sondern darauf, dass der Testentwurf ineffektiv und ineffizient ist. Die Autoren sind der Meinung, dass ein erheblicher Teil dieser Kosten durch die Anwendung modernster Testentwurfsverfahren und Automatisierung gemindert werden kann. Eine effiziente Testautomatisierung umfasst sowohl den Testentwurf als auch die Testimplementierung und -Durchführung. Automatisierter Testentwurf wird dabei durch modellbasierte Testwerkzeuge (MBT) umgesetzt. Die heute gängigen MBT-Werkzeuge haben allerdings mehrere Probleme. Sie erfordern einerseits sehr umfassende Modellierungskenntnisse, die über ein Analysemodell weit hinausgehen. Herkömmliche Modelle sollten "computerlesbar" sein, d.h., das Modell sollte von einem Computerprogramm analysiert und verarbeitet werden können. Wenn das erfolgt ist, werden die ausführbaren Tests generiert. Daher muss das Modell alle Details der Anwendung einschließlich Design und Implementierung enthalten, sodass eine Automatisierung von vornherein fast unmöglich ist. Ein weiteres Problem stellt das erwartete Ergebnis dar. Auch die Ausgaben des Testobjekts sollten im Modell enthalten sein, sodass der Tester sie bei der Modellierung berechnen muss. In diesem Vortrag stellen die Autoren ein neues MBT-Verfahren, das Zwei-Phasen-MBT vor, das diese Probleme löst. Sie zeigen an einem Fallbeispiel aus der Praxis die Vorteile des Verfahrens. Beim Zwei-Phasen-MBT wird zuerst ein abstraktes und dann ein konkretes Testmodell erstellt. Das abstrakte Modell, das die Autoren im Fallbeispiel genutzt haben, besteht aus einem speziellen Flussgraphen, dessen Knoten Testschritte sind. Jeder Testschritt enthält eine (Benutzer-)Aktion, eine oder mehrere (System-)Antworten — optional — und einen Testzustand — optional. Dieses Testmodell ist für manuelle Tester leicht erlernbar und deckt sowohl das Verhalten des Testobjekts in den Interaktionen, wie z.B. das bei Anwendungsfallspezifikationen oder verhaltensgetriebener Entwicklung (behavior-driven development, BDD) der Fall ist, als auch das zustandsabhängige Verhalten. Testfälle werden aus dem Graphen generiert. Ein Testfall ist ein Pfad vom Anfangsknoten zu einem Blattknoten. Das abstrakte Modell ist "menschenlesbar", aber noch nicht „computerlesbar“, d.h., aktuelle Anwendungen sind nicht in der Lage, es zu verarbeiten, um Testcode zu erzeugen. Stattdessen werden aus dem abstrakten Modell abstrakte Testfälle generiert. Diese Testfälle können von den Testern ausgeführt werden, aber auch hier kann kein ausführbarer Testcode erzeugt werden. Abstrakte Testfälle können die Anforderungen vor der Implementierung validieren. Auf diese Weise können verschiedene Fehler, nicht erwarteter Code usw. eliminiert werden, was den SDLC kostengünstig und den Code qualitativ hochwertig macht. In der zweiten Phase erfolgt die Generierung eines konkreten Modells und des ausführbaren Testcodes. Dies kann durch die manuelle Ausführung der abstrakten Testfälle am implementierten Testobjekt erfolgen. Während der Ausführung wird ein konkretes Modell generiert. Der ausführbare Testcode wird vom MBT-Werkzeug sofort generiert und ausgeführt. Wenn die manuellen Testschritte ausgeführt werden, wird diese Ausführung mit einem geeigneten Werkzeug automatisiert, sofort ausgeführt und man ist fertig. Hierbei hat sich das Testautomatisierungswerkzeig PlayWright in unserer Fallstudie ausgezeichnet bewährt. Das generierte konkrete Modell ist computerlesbar, womit wir bei der traditionellen Lösung angekommen sind. Auf diese Weise kann das Zwei-Phasen-MBT als eine Weiterentwicklung des traditionellen Modells betrachtet werden. Anhand des Fallbeispiels werden die Teilnehmer die Vorteile des Zwei-Phasen-MBT gegenüber herkömmlichem MBT verstehen:

• kompakter
• verständlicher
• viel schneller
• führt zu qualitativ hochwertigem Code
• erfordert keine Berechnung der erwarteten Ergebnisse, es reicht, sie zu validieren
• Abstrakte Tesetfälle können vor der Testimplementierung generiert werden
• In-Sprint-Testautomatisierung ist möglich

What is spontaneously your first thought when it comes to performance testing? "uh... nothing for me because too complex" or "that's something for developers or infra colleagues". Don't panic, this reaction is perfectly normal because performance testing is usually underexposed. However, its importance cannot be underestimated because the performance of a system -in addition to its functionality- largely determines the user experience. Even though performance testing has an important technical component, we need everyone during the journey, including you, the manual tester. This workshop will explain how you can play a role in this journey.

Target Audience: (Manual) testers in general
Prerequisites: No technical background required. Even more, it is better if people don't have experience with performance testing. This workshop will just show them how they can play a role in the performance testing journey
Level: Basic

Max. number of participants: 36
If you would like to attend this workshop, we kindly ask you to note the course selection when purchasing your ticket. Please be at the lecture room 10 minutes before the workshop starts.

Extended Abstract:
What is spontaneously your first thought when it comes to performance testing? "uh... nothing for me because too complex" or "that's something for developers or infra colleagues". Don't panic, this reaction is perfectly normal because performance testing is usually underexposed. However, its importance cannot be underestimated because the performance of a system -in addition to its functionality- largely determines the user experience. Even though performance testing has an important technical component, we need EVERYONE during the journey, including you, the (manual) tester. "But what can I do in such a project"? you may be asking yourself. That's exactly what this tutorial is going to answer. Non-technical aspects such as collaboration, communication, creativity are just as important. How else can you properly answer the following questions:

• How to determine the requirements for performance testing when you have no (existing) baseline
• How does the strategy differ from functional testing?
• What information to report to your stakeholders and in which format?
• Why is this -more than other testing types- an interdisciplinary activity? 

Rest assured, during this tutorial we will take you step by step through the exciting journey of performance testing using a mix of exercises, quizzes, case studies, polls. And we promise that we don’t dive too deep in the technical complexity of performance testing.

Einblicke in die Implementierung der SAP-Test-Factory im Bereich Life Sciences

Regressionstests stellen hohe Anforderungen an Aufwand und Geschwindigkeit. Wir stellen ein Vorgehen vor, wie die Expleo über eine Test Factory diese Aufgaben von Satorius übernommen hat. Durch die Erhöhung des Automatisierungsgrads konnte die Dauer des Regressionstests verkürzt werden. Der Fachbereich wurde zu 100% entlastet und konnte sich seinen ursprünglichen Aufgaben widmen. Wir präsentieren den Rahmen und das grundlegende Vorgehen, basierend auf einer bewährten Testmethodik. Von fundamentaler Bedeutung sind auch die regulatorischen Anforderungen der GXP in der Life-Science-Industrie, die, wie in anderen Branchen, besondere Beachtung erfordern.

Werft mit uns einen Blick auf die Herausforderungen und Möglichkeiten des automatisierten Accessibility Testing. Wir besprechen, was Automatisierung leisten kann und an welchen Stellen eine kombinierte Strategie mit User-Tests ansetzen sollte. Wie schafft man die optimale Grundlage für User Tests? Warum lohnt sich ein schneller Check durch Automatisierung noch vor der Rekrutierung der Proband:innen für einen Test auf digitale Barrierefreiheit? Und was sind die größten Vorteile aus UX-Sicht? Diese und viele weitere Fragen beantworten unsere Expertinnen mit praktischen Einblicken und Beispielen.

Zielpublikum: Testmanager, Projektleiter, Entscheider, Product Owner, Berater, Softwareentwickler
Voraussetzungen: Interesse am Thema digitale Barrierefreiheit und kombinierte Testingmethoden.
Schwierigkeitsgrad: Basic

Extended Abstract:
Das Testen der Barrierefreiheit wird für alle, die an der Produktentwicklung beteiligt sind, ein immer wichtigeres Thema. Grund dafür ist auch, dass Mitte 2025 alle digitalen Produkte einen Katalog an Mindestanforderungen an die Barrierefreiheit erfüllen müssen (gemäß der WCAG-Richtlinien und des Barrierefreiheitsstärkungsgesetzes). Schnelle Ergebnisse durch automatisierte Accessibility Tests sind da besonders verlockend. Doch was kann die Automatisierung in diesem Zusammenhang leisten und an welchem Punkt ist eine kombinierte Strategie durch User Testing sinnvoll? In ihrem Vortrag betrachten die beiden Speakerinnen das Ganze aus einer Dating-Perspektive und bringen ihre beiden Kompetenzbereiche zusammen. Finden Test Automation und UX/UI-Testing in unserem "Matching" nach Dating-App-Vorbild zusammen?

Was wäre, wenn wir heute schon menschliche Intelligenz in der Qualitätssicherung und im Testdesign nutzen würden? Oft zeigt sich, dass noch viel zu viel aus dem Bauch und ad hoc durchgeführt wird. Da hilft es dann auch nichts, diese Ergebnisse aus dem Testdesign zu automatisieren. Können uns Sprachmodelle wie ChatCPT helfen. Wie? Auf was müssen wir achten? All diese Punkte werde ich in meinem Vortag beleuchten und mit Live-Beispielen untermalen. Der Vortrag wird durch ein Miro-Projekt unterstützt, sodass die Teilnehmer auch schon während des Vortrags dort aktiv sein können und natürlich auch noch lange danach.

Zielpublikum: Tester:innen, Testmanger:innen, Requirements Engineers
Voraussetzungen: Keine speziellen, Spaß an Neuem, Interesse an Qualitätssicherung
Schwierigkeitsgrad: Basic

Die elektronische Zivilplattform bietet deutschen Bürgern Zugang zu einer Fülle von Formularen, von denen jedes Bundesland seine eigene Variante besitzt. Diese Formulare können je nach Ausführung mehrere 100 Felder enthalten, deren Anforderungen unaufhörlich wachsen. Jede Formularvariante kann auf bis zu elf verschiedene Arten ausgefüllt werden. Unsere kleines, aber engagiertes QS-Team, bestehend aus nur vier Mitgliedern, stand vor der wagemutigen Aufgabe, 981 Formularvarianten mit insgesamt über 110.300 Feldern auf höchstem Qualitätsniveau zu sichern. Erfahren Sie, wie wir diese vermeintlich unüberwindbare Herausforderung bewältigt haben.

Zielpublikum: Test Manager, Tester, QA Experts
Voraussetzungen: Projekterfahrung mit Qualitätssicherung und Test-Management
Schwierigkeitsgrad: Expert

Extended Abstract:
Willkommen in der Welt der Qualitätssicherung im digitalen Zeitalter! Die elektronische Zivilplattform bietet deutschen Bürgern einen unvergleichlichen Zugang zu einer Fülle von Formularen, von denen jedes Bundesland seine eigene Variante besitzt. Diese Formulare können je nach Ausführung mehrere 100 Felder enthalten, deren Anforderungen unaufhörlich wachsen. Jede Formularvariante kann auf bis zu elf verschiedene Arten ausgefüllt werden. Unsere kleine, aber engagierte Qualitätssicherungstruppe, bestehend aus nur vier Mitgliedern, stand vor der wagemutigen Aufgabe, 981 Formularvarianten mit insgesamt über 110.300 Feldern auf höchstem Qualitätsniveau zu sichern. Begleiten Sie uns auf einem fesselnden Streifzug durch das digitale Labyrinth, in dem wir vermeintlich unüberwindbare Hindernisse durch kreatives Denken und technische Raffinesse überwunden haben. Erfahren Sie, wie unser Team einen entscheidenden Beitrag zur erfolgreichen Umsetzung dieses bedeutenden Kundenprojekts geleistet hat und welche Lehren Sie für Ihre eigene Reise in der Software-Qualitätssicherung mitnehmen können.

Software kann auf verschiedene Arten getestet werden. Aber wie sieht eine effiziente Verteilung der einzelnen Testarten aus?
Der Vortrag gibt einen Einblick in manuelle und automatisierte Testverfahren bei der Projektron GmbH, einem mittelständischen Softwarehersteller aus Berlin.
Beleuchtet werden dabei verschiedene manuelle Testpfade sowie Strategien und Lessons-Learned im Rahmen des automatisierten Testens. 
Ziel des Vortrags ist es, den Zuhörern Anregungen zur Entwicklung eigener Teststrategien mit auf den Weg zu geben.

Bei der Initiierung einer serverlosen Architektur stellt sich oft die Frage, wie diese automatisiert getestet werden kann, ohne eine Verbindung zur Cloud zu benötigen. In meinem Vortrag werde ich verschiedene Ansätze und Frameworks vorstellen, die es ermöglichen, serverlose Architekturen in der lokalen Entwicklungsumgebung zu testen und nahtlos in die Deployment-Pipeline zu integrieren, ohne auf die Cloud angewiesen zu sein. Anhand praktischer Beispielen und Best Practices werde ich zeigen, wie Entwickler diese Herausforderung meistern können, um eine effiziente und zuverlässige serverlose Architektur zu realisieren.

Zielpublikum: Softwarearchitekten, Entwickler, IT-Leiter
Voraussetzungen: Erfahrung mit Tests und Serverless
Schwierigkeitsgrad: Advanced

Extended Abstract:
Stell dir vor, du entwickelst eine serverlose Architektur und möchtest sicherstellen, dass sie einwandfrei funktioniert, ohne ständig mit der Cloud verbunden zu sein. Aber wie kann ich serverlose Anwendungen effektiv testen und in die Deployment-Pipeline integrieren, ohne die Cloud-Ressourcen zu belasten? Dies ist das zentrale Problem, das in diesem Vortrag gelöst wird. Serverlose Architekturen sind eine leistungsfähige Möglichkeit, Anwendungen zu entwickeln und bereitzustellen. Die Entwicklungs- und Testphase erfordert jedoch besondere Aufmerksamkeit, da sie Cloud-Ressourcen und -Kosten beanspruchen kann. In diesem Vortrag zeige ich dir, wie du dieses Problem angehen und serverlose Anwendungen effizient und zuverlässig entwickeln und testen kannst. Ich stelle dir Beispiele und Frameworks vor, mit denen du serverlose Architekturen in deiner eigenen lokalen Umgebung testen und nahtlos in deine Deployment-Pipeline integrieren kannst. Du wirst lernen, wie du Kosten in der Cloud minimieren und Ressourcen optimal nutzen kannst, ohne auf die Vorteile serverloser Architekturen verzichten zu müssen. Mein Ziel ist es, dir bewährte Methoden und Best Practices zu vermitteln, um eine stabile, skalierbare und wartbare serverlose Architektur zu schaffen, die unabhängig von der Cloud getestet werden kann.

When we explain our neurodivergent brains and how they work to colleagues and friends, we often get compared with Artificial Intelligence - no joke! But one of us is barely using AI tools and one of us loves them! We will play a game with the audience to finally know if you are Team Human or Team AI. In addition, we will share with you our assessment approach to help you determine if you have any weaknesses that ChatGPT can help you with. You will know if you are the type to use the tool and what to consider to use it effectively.

Target Audience: Everyone
Prerequisites: None
Level: Basic

Extended Abstract:
Using ChatGPT in different ways is not the only way we are diverse. However, we both found our way into the testing community. Tugba has a lot of technical expertise and feels the best in a SDET role whereas Viviane prefers roles with communication and processes such as quality architect or quality coach. To prepare our speech we are going to give us each several tasks from our daily doing. Tugba will solve them using "her buddy" ChatGPT and Viviane will face them without it. We will show you how we each came to our solution and present to you our results. And then we need you to judge! After each presented task we will ask for your preference. And we will clarify the ultimate question: Are you team AI or team human? As an additional benefit we will give some insights how to effectively use ChatGPT in your daily doing and where it might be better to use the intelligence without the artificial aspect.

Have you ever asked yourself: ‘Am I ready to master the challenges to come?’ Well, I did it a lot when I moved into my first leadership role as a QA Manager in 2023. OK and to be honest, it was more like ‘What the heck am I doing here?’. The early days were exciting and scary at the same time. I was instantly confronted with situations for which no training course (could) ever prepare me. Like the happy little accident at the daylight saving time changeover. Being a first-time manager is tough, especially when imagination meets reality. Based on real-life examples I will describe the challenges and I share my leadership tips and tricks with you.

Target Audience: Any tech professional who is aspiring a leadership role, Managers aka Team Leads in their first role
Prerequisites: None
Level: Basic

1. Das Puzzle der QA-Metriken: Wie man aus den Einzelteilen ein Gesamtbild der Softwarequalität baut (Anastasia Mikitenko)
In diesem Vortrag werde ich zeigen, wie ich die Konsolidierung von Metriken aus SonarQube und Fortify über 200 verschiedene Projekte gelöst habe. Ich werde erörtern, wie ich Anreize geschaffen habe, die Teams zur Verbesserung der Qualität ermutigt haben. Natürlich werde ich auch die Schwierigkeiten ansprechen, auf die ich währen der Implementierung gestoßen bin. Dieser Vortrag ist besonders relevant für QA-Manager, die mehrere Anwendungen überwachen, wo es entscheidend ist, einen Überblick zu behalten und notwendige Handlungen abzuleiten. 

2. AI Image Recognition for Smarter Testing (Stefan Dirnstorfer)
The objective of image based testing is to break free from a UI's internal state and its specific device constraints. We advocate for assessing correctness based on appearance rather than internal structure, using tools like Appium's "findElementByImage." However, these tools often fail due to minor rendering changes, such as color shifts or line breaks. We'll delve into the root causes of these issues and introduce image algorithms to mitigate them. Lastly, we'll touch on our algorithmic choices for training a fully capable network in the pursuit of software that can "see" like a human.

Um die Auswahl zwischen den parallel laufenden Vorträgen und Workshops zu vereinfachen, geben die Sprecherinnen und Sprecher einen kurzen Teaser zu Ihrer Session. 

Ein Modell wie die Testpyramide adressiert nur einen Teilaspekt eines Testkonzepts. Welche Ansätze gibt es noch, um ein zum Produkt passendes Testkonzept zu erarbeiten? Wir zeigen auf, dass der individuelle Kontext und die dazugehörigen Risiken berücksichtigt werden müssen, und liefern einen pragmatischen Ansatz, das Testkonzept konkret und übersichtlich darzustellen. Um dieses Testkonzept auch mit zielgerichteten Tests umsetzen zu können, betrachten wir ebenfalls, wie man den Schnitt der Anwendung und der Tests geschickt wählt. Wie das Genannte konkret aussehen kann, zeigen wir anhand eines leicht nachvollziehbaren Beispiels.

Zielpublikum: Entwickler:innen, Domänen-/Fachexpert:innen, Tester:innen
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Advanced

Extended Abstract:
Ist das Streben nach einem bestimmten Testmodell sinnvoll? Und ist dies schon ein vollständiges Testkonzept? Ein Testmodell wie die Testpyramide adressiert nur einen Teilaspekt. Diesem einen Teilaspekt dogmatisch zu folgen, bietet meistens keinen ausreichenden Mehrwert. Wir schauen daher mit einem breiteren Blick auf das Thema Testkonzept: Welche Ansätze gibt es, um ein zum spezifischen Produkt passendes Testkonzept zu erarbeiten? Dabei zeigen wir die Notwendigkeit auf, den individuellen Kontext und die dazugehörigen Risiken zu berücksichtigen. Ein häufiges Problem in der Praxis ist, dass Testkonzepte nur schwer in den Transfer gebracht werden können und somit auch nicht gelebt werden. Wir liefern einen pragmatischen Ansatz, mit dem man ein Testkonzept so konkret darstellt, dass es verständlich und übersichtlich ist. Um dieses Testkonzept auch mit zielgerichteten Tests umsetzen zu können, benötigen wir eine gute Modularisierung. Daher betrachten wir ebenfalls, wie man den Schnitt der Anwendung und der Tests geschickt wählt. Wie das Genannte konkret aussehen kann, zeigen wir anhand eines leicht nachvollziehbaren Beispiels.

Continuous Testing ist der wichtigste Prozess, durch den DevOps erst erfolgreich wird. Dabei handelt es sich um einen Prozess, der automatisiert und kontinuierlich die Veränderungen des Codes überprüft, um sowohl funktionale als nicht-funktionale Anforderungen zu validieren. Das Ziel ist es, proaktiv Fehler zu finden und frühzeitig in der Entwicklung zu beheben. Aber wie sieht es bei Last- und Performancetests im wirklichen Leben aus?

Zielpublikum: Erfahrene Softwaretester, Testanalysten, Testautomatisierer, Testmanager, Test Consultants, Tool-Verantwortliche, Mobile Tester
Voraussetzungen: Keine
Schwierigkeitsgrad: Advanced

Extended Abstract:
Continuous Testing ist der wichtigste Prozess, durch den DevOps erst erfolgreich wird. Dabei handelt es sich um einen Prozess, der automatisiert und kontinuierlich die Veränderungen des Codes überprüft, um sowohl funktionale als nicht-funktionale Anforderungen zu validieren. Das Ziel ist es, proaktiv Fehler zu finden und frühzeitig in der Entwicklung zu beheben. Aber wie sieht es bei Last- und Performancetests im wirklichen Leben aus? In diesem Vortrag werden folgende Aspekte beleuchtet:

• Last- und Performancetests im Continuous-Delivery-Umfeld
• Best Practices beim Testen webbasierter Oberflächen
• Best Practices für die Entwicklung dedizierter Performance-Pipelines
• Die Rolle von Open Source beim Continuous Testing
• Die Schritte zum Continuous Testing
• Continuous Performance Testing/Last- und Performancetests zum Anfassen – Live Demo (Azure, GitHub)

Fazit: Damit Continuous Performance Testing erfolgreich sein kann, werden die richtigen Tools und qualifizierte Experten (ISTQB Performance Tester) benötigt. Continuous Performance Testing ist weit mehr als Automatisierung!

Andreas Berger und sein Team entwickeln die Systemtest-Infrastruktur beim Küchenprofi RATIONAL. Diese Infrastruktur umfasst etwa 17 k Zeilen Code und ist damit längst selbst ein komplexes Stück Software, dessen Qualität für RATIONAL essenziell ist. Den langen und nicht immer leichten Weg zum heutigen hohen Qualitätsniveau dieser Infrastruktur sind sie gemeinsam mit Thomas Pettinger (Berater, CQSE GmbH) gegangen. Im Vortrag sprechen Andreas und Thomas über ihre Erfahrungen, Erkenntnisse und Lessons Learned aus diesen sechs gemeinsamen Jahren. Freuen Sie sich auf diese Rezeptsammlung aus der Qualitätsküche!

Zielpublikum: Tester:innen, Testmanager:innen, Entwickler:innen
Voraussetzungen: Basiswissen Softwareentwicklung und -test
Schwierigkeitsgrad: Basic

Extended Abstract:
In der Küche muss die Qualität stimmen. Deshalb entwickeln und betreiben Andreas Berger und sein Team beim Küchenprofi RATIONAL eine topmoderne Systemtest-Infrastruktur, in der sowohl die Endgeräte als auch notwendige Test-Hardware und -Software eingebunden sind. Diese Infrastruktur beinhaltet heute etwa 17.000 Zeilen Python-Code, in mehreren selbst verwalteten Packages, und ist damit längst selbst ein komplexes Stück Software geworden. Da hohe Zuverlässigkeit und damit eine hohe Qualität der Testergebnisse aus dieser Infrastruktur für RATIONAL natürlich essentiell sind, stellte sich schon früh die Frage, wie die Qualität der Infrastruktur ohne erheblichen Zusatzaufwand gesichert werden kann. Damit finden sich Andreas und sein Team in einer Doppelrolle wieder: Als Testabteilung gegenüber dem Rest der Firma und als Entwicklungsteam der Systemtest-Infrastruktur inklusive direkter Verantwortlichkeit für deren Qualität. Infolgedessen setzen Sie die Prozesse und Werkzeuge, die sie anderen zur Qualitätssicherung zur Verfügung stellen, gleichzeitig auch selbst ein. So haben sie für ihre Testinfrastruktur statische und dynamische Qualitätsanalysen eingeführt, um sowohl die interne Qualität, als auch die Vollständigkeit der Tests ihrer Testinfrastruktur sicherzustellen. Heute ist Andreas’ Team stolz auf die beinahe vollständige Testabdeckung aller Änderungen, die überschaubare Anzahl an Findings aus automatisierten Qualitätsanalysen und minimale Code-Duplikation. Den langen und nicht immer leichten Weg hin zu diesem Qualitätsniveau sind sie gemeinsam mit Thomas Pettinger (Berater für Softwarequalität von der CQSE GmbH) gegangen. Dabei gewannen sie wertvolle Erfahrungen und Erkenntnisse, beispielsweise zur Arbeitsweise von qualitätsbewussten Entwicklern unter hohem Projektdruck, zu Auswirkungen von Qualitätsanalysewerkzeugen (und deren Zuverlässigkeit) auf die Softwarequalität und zur eigenen Projektvergangenheit. Im Vortrag blicken Andreas Berger (RATIONAL AG) und Thomas Pettinger (CQSE GmbH) zurück auf diesen Weg, den die Qualitätssicherung von RATIONALs Systemtest-Infrastruktur in den letzten 6 Jahren genommen hat, und berichten von überraschenden Erkenntnissen, zufälligen Entdeckungen und wertvollen Lessons Learned. Freuen Sie sich auf diese Rezeptsammlung aus der Qualitätsküche!

Im Bund sind barrierefreie Anwendungen nach BITV-Gesetz. Ab 28.6.25 dann auch für Privatunternehmen, z. B. bei Bankdienstleistungen und der Personenbeförderung, aber auch für Messenger- und Telefondienste. Wer sind die Zielgruppen und wie fühlt sich das an? Was steckt hinter den Anforderungen und was ist im Rahmen der Softwareentwicklung zu tun? Welche Fähigkeiten braucht man dafür im Team und wie baut man die auf? Welche Rolle sollte das bisherige Qualitätspersonal dabei einnehmen? Teilnehmende informieren sich über Barrierefreiheit, machen spielerisch eigene Erfahrungen und diskutieren vermeintliche Hindernisse bei der Softwareentwicklung.

Zielpublikum: Alle am SWE Beteiligten
Voraussetzungen: Keine
Schwierigkeitsgrad: Basic

Maximale Anzahl von Teilnehmern: 60
Wenn Sie an diesem Workshop teilnehmen möchten, bitten wir Sie, beim Kauf Ihres Tickets die Kursauswahl zu vermerken. Bitte erscheinen Sie 10 Minuten vor Beginn des Workshops im Vortragsraum.

Extended Abstract:
Barrierefreie Anwendungen sind im öffentlichen Sektor seit dem 23.6.2021 Pflicht. Dazu müssen sie alle Prüfungen nach BITV 2.0 erfolgreich erfüllen. Ab dem 28.6.2025 gilt dies auch für etliche Anwendungen von Privatunternehmen, z.B. bei Bankdienstleistungen und der Personenbeförderung, aber auch für Messenger- und Telefondienste. Wer sind die Zielgruppen und wie fühlt sich das an? Was steckt hinter den Anforderungen und was ist im Rahmen der Softwareentwicklung zu tun? Welche Fähigkeiten braucht man dafür im Team und wie baut man die auf? Welche Rolle sollte das bisherige Qualitätspersonal dabei einnehmen? Alle Teilnehmenden sind eingeladen, sich im Rahmen eines teilweise nichtlinearen Formats über Barrierefreiheit zu informieren, eigene Erfahrungen mit Barrieren zu machen und in die Diskussion über Zielkonflikte bei der Umsetzung und entsprechende Konsequenzen zu gehen. Dies wird im Wortsinne zum Teil "spielerisch" passieren.

Komplexe Systemlandschaften enthalten große Datenmengen, die über mehrere Anwendungen verteilt sind. Die Herausforderung für Tester und Entwickler besteht oft darin, geeignete Daten für den Test zu finden, obwohl die Datenbanken und deren Strukturen nicht bekannt sind.
Erfahren Sie, wie Sie einen Überblick über die Entitäten Ihrer Geschäftsdaten und deren Attribute erhalten. Wenn Sie wissen, wie die Daten verteilt sind, können Sie die am besten geeigneten Daten für Ihre Testausführung ermitteln.
Erwerben Sie das Wissen, wie Sie die Daten extrahieren und auf jede Testumgebung anwenden, entweder eine statische Umgebung oder dynamische Testumgebungen, die nur während der CI/CD-Läufe der Anwendung vorhanden sind.
In der Präsentation wird dargelegt, wie ein Datenbereitstellungsprozess für Testdaten eingerichtet wird, der einzelne Geschäftsfälle automatisch über ein einfaches Webformular transportieren oder über einen Webdienst von jedem Testautomatisierungsprozess aus ausgelöst werden kann.
Wenn wir echte Daten verwenden, werden wir uns natürlich damit befassen, wie wir diese Daten entsprechend den DSGVO- oder HIPAA-Anforderungen maskieren können.
Andererseits zeigt die Präsentation Einblicke, wie umfangreiche Modifikationen im Maskierungsprozess genutzt werden können, um ihn als Tool zur Testdatengenerierung zu verwenden.
Schließlich benötigen wir bei der Verwendung von Testbasisdaten in der Testautomatisierung einen Mechanismus zum Zurücksetzen der Testdaten, nachdem ein Test die Daten geändert hat. Wir werden sehen, wie Sie wiederverwendbare Testdaten erhalten und wie diese Ihre Testautomatisierung beschleunigen können.

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? Wwhat is the daily business of a test architect? 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.

Target Audience: Testers, Developers, Architects, Project Leads, Test Managers, Team Leads
Prerequisites: Knowledge about test organization and responsibilities, Knowledge about software architects responsibilities
Level: Advanced

Extended Abstract:
Test architects have something in common with Managers. they should be both superflous. But as nothing is perfect and context is normally complicated to complex we need people either taking care about management tasks or about things like test architecture. But what is the difference of a test architect to a commonly known software architect? What do they have in common and where do they differ? Wwhat is the daily business of a test architect? 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 AG and Siemens Healthineers and build up a network of test architects and how the perception and interaction with them changed over the past years.

CI/CD gilt in der Software-Entwicklung als unverzichtbar, auch die Automobilzulieferer haben diesen Trend entdeckt. Sie wollen Produkte von der Stange anbieten, aber OEMs wollen Alleinstellungsmerkmale. Wie kommt man in dieser Multiprojektlandschaft zu effizientem CI/CD? Die Versuchung ist groß, Jenkins Pipelines zu erstellen und 24 h Nightly Builds zu etablieren. Aber wer hat Lust, am nächsten Morgen Fehler zu analysieren, die weder nachvollziehbar noch reproduzierbar sind? Wir nicht! Unser Weg zum Glück führt über sauberes Dependency Handling mit CMake und nachvollziehbaren Tests in Python hin zu schnellen Builds mit reproduzierbaren Ergebnissen.

Zielpublikum: Spezielle Vorkenntnisse sind nicht erforderlich. Das Thema betrifft CI/CD-Anfänger und -Experten gleichermaßen. Wir möchten die Hochs und Tiefs unserer CI/CD-Reise in der Automobilindustrie darstellen.
Voraussetzungen: Für die verwendeten Beispiele können Kenntnisse in Jenkins Pipelines und Python hilfreich sein, sind aber nicht notwendig.
Schwierigkeitsgrad: Basic

Testing is not enough to ensure software quality. It only verifies the existing level of quality. To truly improve, we need to consider the product as a whole and collaborate with the business, engineering, and process optimization. In this session, Finn will share how he applied this holistic approach with diverse teams across multiple projects and achieved significant improvements in product quality. He will also reveal his insights from the pandemic. You will learn how to adopt this approach and deliver better software faster with a stronger team culture.

Target Audience: Test-*, Quality Analysts, anyone who is thinking about a high quality Product (not just code)
Prerequisites: Basic agile knowledges about processes in teams, approach to testing testing and knowledge about how feedback loops in teams work
Level: Advanced

Extended Abstract:
Did you know you can enable your team to build better software faster while having a stronger team culture? Too good to be true? In recent years, agile has influenced the early involvement of testing in the development cycle. With this more and more testers are testing new functionality as soon as a commit is pushed. Yet such teams still fail to deliver high-quality software. Why? What is missing? Working with various diverse teams across multiple projects, Finn realized that testing doesn’t actually improve software quality. It’s just a bar assuring a certain level of quality that already exists. In order to actually improve we must get involved in much more than simply testing and think about the product as a whole. In this session, Finn will share specific examples of how engaging with the business, engineering, and process optimization as well as the entire cross-functional team can lead to significant improvements in the product’s quality. He will also dive into recent learnings during the pandemic. At the end of the talk, you will know how to start with a holistic approach to improving product quality throughout the entire software delivery lifecycle.

Bei langlebiger Software treten die meisten Fehler dort auf, wo viel geändert wird. Wenn wir richtig testen wollen, müssen wir daher sicherstellen, dass keine wichtigen Änderungen ungetestet bleiben. Hierbei hilft uns Test-Gap-Analyse, ein Analyseverfahren, das ungetestete Änderungen vollautomatisch ermittelt.

Nach einer Einführung in Test-Gap-Analyse zeigen wir den Einsatz der Test-Gap-Analyse mit unserem Analysewerkzeug Teamscale. Wir zeigen einerseits, wie Test-Gaps auf Gesamtsystemebene betrachtet werden könnten, um beispielsweise die Testqualität über alle Teststufen (von automatisierten Unit Tests bis hin zu manuellen Systemtests) für ein Software-Release zu bewerten. Außerdem demonstrieren wir, wie sich Test-Gaps auf die Ebene einzelner Issues (User Stories, Change Requests, Bug Reports, etc.) herunterbrechen lassen, um bereits während der Entwicklung den Überblick zu behalten, wie gründlich getestet wurde und, nicht zuletzt, wo aufgrund von nachfolgenden Code-Änderungen nochmal nachgetestet werden sollte.

Wir versprechen wir eine praxisnahe und ungeschönte Demo!

Zielpublikum: Tester, Entwickler, Test Manager, Qualitätsverantwortliche
Voraussetzungen: Keine
Schwierigkeitsgrad: Basic

Organisationen ähneln Organismen, sie besitzen einen Überlebenswillen, fressen Dinge, haben Ausscheidungen und hoffentlich auch eine Absicht und Intelligenz. Leider ist die Intelligenz der Organisation oft nur ein Bruchteil der Summe der Intelligenz der einzelnen Teilnehmenden. Eine Organisation, die gestern noch schlau agierte, kann morgen schon dumm sein, wenn sich das Umfeld schnell ändert.
Was macht eine dumme Organisation aus? Kann eine dumme Organisation ihre Ziele gut erreichen? Warum verdummt eine Organisation? Geht es einem Einzelnen in einer dummen Organisation gut?
Beispiele aus dem praktischen Leben und Inspirationen zu intelligenten Schritten und Berichte über Organisationen, die schrittweise schlauer wurden.