Der Wert von Software-Reviews wird allgemein akzeptiert. Bei klassischen Methoden steht diesem gleichzeitig ein erheblicher Aufwand gegenüber. Das macht es Entwicklungsteams schwierig, ihre Vorhaben zum richtigen Zeitpunkt angemessen zu beleuchten, um Risiken aufzudecken und die Architektur abzusichern. In diesem Vortrag skizziere ich praktikable Ansätze, mit denen Sie und Ihr Team mit überschaubarem Aufwand und im Extremfall im Alleingang wertvolle Ergebnisse erzielen.

Zielpublikum: In erster Linie Architekt:innen und Entwickler:innen, ansonsten alle in Softwarevorhaben Beteiligte
Voraussetzungen: Erfahrung in Software-Entwicklungsvorhaben
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Der Wert von Software-Reviews wird allgemein akzeptiert. Bei klassischen Methoden wie ATAM steht diesem gleichzeitig ein erheblicher Aufwand gegenüber. Das macht es Entwicklungsteams schwierig, ihre Vorhaben zum richtigen Zeitpunkt angemessen zu beleuchten, um Risiken aufzudecken und die Architektur abzusichern. In diesem Vortrag skizziere ich praktikable Ansätze, mit denen Sie und Ihr Team mit überschaubarem Aufwand und im Extremfall im Alleingang wertvolle Ergebnisse erzielen.
Zur Motivation: Es gibt einige "große" Methoden zur Architekturbewertung wie ATAM oder CBAM, oder sehr "flapsige", die nur Bauchgefühl haben. Da einen Mittelweg zu finden ist nicht leicht.
Aus der Praxis von 50+ Reviews konnten wir aber einen funktionierenden Kern ableiten, der fundiert und trotzdem schlank ist. Das Ergebnis stelle ich in dieser Session vor und gebe Orientierung, wie Sie das Schritt für Schritt auf Ihre eigenen Softwarelösungen anwenden.
Der Clou: Die gezeigte Methodik ist darauf getunt, durch Fokussierung bereits früh verwertbare und vorzeigbare Ergebnisse zu liefern. Weitere Schritte liefern wo nötig tiefere Erkenntnisse und mehr Sicherheit.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/stefan.zoerner

Test coverage: 100% - Check!
And why do we still have bugs?
OK, tests don't prove the absence of errors.
And at the end of the day, they are just code which could contain bugs as well.
And perhaps they give us a false sense of security.
But how do I know, that my test are good?
One way to find out is using Mutation Testing.
In this talk I want to explain, what Mutation Testing is, how to do it and when it is helpful.

Target Audience: Developers, Achitects, Testers
Prerequisites: Basic knowledge in Programming, some experience in writing tests
Level: Basic

Extended Abstract:
More and more teams are writing tests for their production code, be it by applying concepts like TDD or BDD or by just writing them "after the fact". Sometimes there is also a test coverage metric that needs to be met. The positive effect is definitely that there are tests. Be it for my future self or a future colleague or as a form of documentation.
Tests are a means of telling something about the quality of production code. Mutation testing can help tell something about the quality of tests. It helps to find missing tests and potential bugs.
The concept of mutation testing is already more than 50 years old, but its application has not yet become widespread.
This talk should encourage you to take a closer look at mutation testing to find out what possibilities it offers in your own project, but also to see what disadvantages or pitfalls there are.

How often have you heard that ‘Yes this is important, but we don’t have the capacity right now’ or ‘sure let’s put it in the backlog’?
This is something we should not brush off or take lightly. Accessibility testing is vital especially when your product is a user facing application.
We need to be socially aware as a team and build quality towards our product with making it more accessible.

Target Audience: Everyone as Accessibility is for social awareness
Prerequisites: None
Level: Basic

Extended Abstract:
At least 1 in 5 people in the UK have a long term illness, impairment or disability. Many more have a temporary disability. A recent study found that 4 in 10 local council homepages failed basic tests for accessibility.
This is quite vital and the sooner we as testers can advocate this into our teams, we make our product more accessible, reduce the risk of bad product reviews, reputation and also be more socially aware. Let's shift left and make accessibility testing built-in our teams.

1. Understand why accessibility testing is important?
2. How I adapted accessibility mindset?
3. How to coach team and bring accessibility into your teams?
4. Demonstrate various tools available to perform accessibility testing (with demo)

Wenn man eine gute Übersicht über eine komplette Domäne mit einem einfachen Event-Storming-Workshop bekommt, warum machen wir dann nicht etwas Ähnliches, wenn wir eine Teststrategie entwickeln? Wir haben einen neuen kollaborativen Ansatz in Projekten erprobt und gute Ergebnisse erzielt. Am Ende hatten wir ein gemeinsames Bild, wie man mit dem Testen startet, sowie ein Backlog von offenen Punkten. Der Vortrag zeigt die Schritte, wie man in der Praxis zu einer "Minimum Viable Test Strategy" kommt.

Zielpublikum: Architekt:innen, Test Manager:innen, Tester:innen, Projektleiter:innen
Voraussetzungen: Grundkenntnisse Testen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Der Vortrag liefert ein Vorgehen, wie man eine grobe Teststrategie visualisieren kann und wie man sie mit den wesentlichen Stakeholdern kollaborativ entwirft. Als erster Schritt werden Teststufen und Testarten festgelegt. Danach werden Details wie Verantwortlichkeiten, Werkzeuge, Umgebungen und Metriken diskutiert. Dabei entstehen die ersten Regeln für das Testen und gleichzeitig ein Backlog für das Klären offener Punkte.
Die Methode ist analog zum Event Storming sehr leichtgewichtig, so dass sie direkt anwendbar ist.

Die Abstände zwischen Entwicklungsphase und Release werden kürzer. Das betrifft neue Produkte gleichermaßen, wie zusätzliche Features in App-/Webanwendungen. In der Projektleitung mangelt es oft an Integrations- und Abnahmeverfahren sowie einem Device-Setup passend zur Zielgruppe. Der Schlüssel: Kontinuität und Agilität. Am Beispiel des App-Testings für das ZDF beleuchten wir die größten Mythen über externes Testing und Automation und werfen einen Blick auf die Zukunft kombinierter QA-Verfahren.

Zielpublikum: Entscheider:innen, Projektleiter:innen, Product Owner:innen, Berater:innen, Softwareentwickler:innen
Voraussetzungen: Interesse an der Entwicklung von QA und Teststrategien
Schwierigkeitsgrad: Anfänger

Extended Abstract:
In diesem Vortrag erweitern wir die Perspektive der fachlichen Umsetzung von Testing und Automation um die Herausforderungen im agilen Prozess. Welche Anforderungen birgt eine schwer einzugrenzende Zielgruppe? Die Apps des ZDF stehen durch den öffentlich-rechtlichen Verbund in besonderer Weise auf dem Prüfstand. Wie gelingt es hier auf Seiten der Qualitätssicherung, effiziente und langfristige Lösungen zu schaffen? Unter dem Stichwort agile Testverfahren geben die Speaker Einblicke und Impulse und öffnen das Gespräch für die Seiten der Projektleitung, Entwicklung und des Testmanagements, um auf neue Methoden und die Zukunft der QA zu blicken.

Come and hear the story of a company that is on the journey from the old monolithic, on-premise, waterfall world to the new modular, agile, domain-driven, multi-tenant, cloud-based microservices world. The challenges come from different directions: both technical and organizational aspects have to be mastered. The domain has to be understood, so that the system can be structured right. The big bang has to be avoided.
In this talk we will look at how our “fictional” company has struggled with and finally overcome those challenges.

Target Audience: Architects, Developers, Project Leaders, Managers
Prerequisites: Programming Experience
Level: Advanced

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/henning.schwentner

Prozessunterstützende Werkzeuge erleichtern uns die tägliche Arbeit. Sie helfen uns, Software zu entwickeln und zu testen oder das Projekt zu steuern. Doch es gibt einen blinden Fleck: das Testdesign. Gute Tests scheinen vom Himmel zu fallen. Man muss sie nur niederschreiben oder programmieren.
Tatsächlich gibt es ein enormes Verbesserungs- und Einsparungspotenzial, welches in den meisten Organisationen ungenutzt liegen gelassen wird. In diesem Vortrag zeigen wir, welche das sind und wie modellbasiertes Testen zur Lösung beitragen kann.

Zielpublikum: Tester:innen, Testmanager:innen, Manager:innen, Projektleiter:innen Entscheider:innen
Voraussetzungen: Erfahrung mit Tests in Projekten
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Während die Industrialisierung der Software-Entwicklung in vielen Bereichen vorangekommen ist (Stichwort „CI/CD“), gibt es im Test noch immer einen grauen Fleck: das Testdesign. Von außen wenig wahrgenommen, bemühen sich Fachexperten – meist völlig ohne Werkzeugunterstützung – ihr Bestes zu geben. Das ist bestenfalls Handwerk, wenn nicht gar Kunst!
Wieso „ohne Werkzeugunterstützung“? Wir haben doch ein ALM-Tool eingeführt! Sehr gut, nur war nicht von Testmanagement die Rede, sondern von Testdesign; also von der Erstellung geeigneter Testfälle, die mit möglichst wenig Aufwand möglichst viele Aspekte abprüfen. Testdesign ist eine entscheidende Aktivität im Testprozess, die obendrein hohes Verbesserungspotenzial besitzt. Es gibt also keinen Grund, weshalb Tester sich mit einem Text-Editor zufriedengeben sollten, während die Kollegen aus der Entwicklung diverse Tools zur Unterstützung ihrer Arbeit einsetzen.
Dieser Vortrag macht auf ein Manko aufmerksam, welches nicht länger akzeptiert werden sollte, und zwar weder von Testern noch von Managern. Wieso verbringen wir Stunden mit Besprechungen zur Klärung von Anforderungen, wenn es etablierte Methoden gibt, dies zu verbessern (Stichwort: modellbasiertes Testdesign)? Wieso überarbeiten wir Testfälle und Testskripte mühsam per Hand, wenn es auch hier Werkzeuge gibt, die uns einen Teil der Arbeit abnehmen könnten?
Wir werden zeigen, welche Aktivitäten dringend Werkzeugunterstützung benötigen und wie diese aussehen kann. Ein ganz wichtiger Aspekt ist dabei selbstverständlich der Einsatz von KI, die auf vielfältige Weise hilfreich sein wird. Doch es gibt auch andere, eher prozess-basierte Ansätze wie ATDD.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Anne_Kramer

While AI systems differ in some points from "traditional" systems, testing them does not have to be more difficult - knowing the right questions to ask will go a long way. In this talk we will:

• Arm you with a checklist of questions to ask when preparing to test an AI system
• Show you that testers and data scientist have common ground when testing AI systems

Keep calm and test on - AI systems are not that different from "normal" systems.

Target Audience: Testers, Data Scientists, Developers, Product Owners, Architects
Prerequisites: Basic knowledge of software testing
Level: Advanced

Extended Abstract:
If you're a tester about to test your first AI system, or wanting to move into that area, you're probably wondering how you can prepare for the role. While we usually do not deal with complexity in the magnitude of Large Language models like chatGPT, AI systems still seemingly offer different challenges than "traditional" systems.
You're not the first person to deal with these questions. In fact, a group of us got together to explore it in more detail. Is there a general framework of questions that testers can use to help develop a quality strategy for systems that use AI? We wanted to see if we could design one. To this end, we got together a group with diverse roles: tester, test architect, data scientist, project lead and CEO.
Join us in this talk to hear how we approached the task and what our results are, including an example of using our checklist of questions to analyse a system that uses AI. Along the way we also addressed questions like "What is the role of a tester in such projects?" and "How much math do I need?" - we'll talk about those discussions, too. We encourage participants to use our checklist and give us feedback on it!

The introduction of ChatGPT, CoPilot X brings in a lot of hype over developer experiences, especially documentation. But are we ready to chat with our documentation, instead of reading, using these tools? How can we, as maintainers, leverage these tools to offer a better experience in documentation for developers as our users? Join my talk and let's find out.

Target Audience: Engineers, Developers
Prerequisites: Programming
Level: Advanced

Discover the transformative power of GenAI in software testing. This lecture showcases a powerful GenAI-powered test framework that enhances testing efficiency. Learn how GenAI analyzes applications to generate automated test cases, uncover hidden defects with generative AI's random exploratory tests. Experience AI-powered peer reviewers for code analysis and quality evaluations. Explore Smart Report AI, providing comprehensive analysis and insights into test execution, results, and defects. Join us to revolutionize your software testing with GenAI.

Target Audience: Quality Engineers, Architects, Developers, Project Leader, Managers
Prerequisites: Basic knowledge on modern software development
Level: Advanced

Extended Abstract:
In the rapidly evolving landscape of software development Generative AI holds immense potential to revolutionize the field of software testing. This lecture aims to explore the transformative capabilities of GenAI in software testing by showcasing the powerful GenAI powered test framework and its key components.
The lecture begins by introducing the main framework, which combines the power of GenAI and automation to enhance the efficiency and effectiveness of software testing. Attendees will learn how GenAI can analyze the application under test and generate automated test cases based on a predefined test framework. These test cases can be executed locally or seamlessly integrated into DevOps processes, allowing for efficient and comprehensive testing of applications.
Furthermore, the lecture delves into the utilization of generative AI for the generation of random exploratory tests. By leveraging the capabilities of GenAI, testers can uncover hidden defects and vulnerabilities that may go unnoticed with traditional testing approaches. This demonstration highlights the innovative potential of GenAI in driving comprehensive test coverage.
Additionally, the lecture showcases the Smart Peer AI component of the framework. Attendees will discover how AI-powered peer reviewers can anticipate functional and non-functional issues, providing insightful code analysis and quality evaluations. By incorporating specific coding best practices, architectural standards, and non-standard attributes, Smart Peer AI enhances code quality and accelerates the development process.
Finally, the lecture concludes by presenting the Smart Report AI, an AI-powered solution that analyzes test reports generated from automated testing processes. This component provides a comprehensive analysis of test execution, environment configuration, test results, defect severity automated analysis, reproducibility steps, and suggestions for fixes. Smart Report AI empowers testers with valuable insights and facilitates effective decision-making in the testing and development lifecycle.

Agile Transformation wird oft als obligatorische Aufgabe gesehen, ohne den tatsächlichen organisatorischen Bedarf zu berücksichtigen. Doch sie bietet Chancen zur
Prozessverbesserung. Der Haken ist aber oft, dass der genaue, eigene Bedarf im Unternehmen oft nicht bekannt ist und nach "best practices" der Industrie gehandelt wird.
Frei nach dem Motto „was bei anderen funktioniert, ist für uns nur recht“ werden Gilden und Tribes initiiert, Communities of Practice gebildet und die Re-Organisationen in die Wege geleitet.

Doch wie können wir die eigenen Bedarfe identifizieren? Woher bekommen wir das Wissen über den Status Quo in der Organisation? Als Tester im Herzen hinterfragen wir gerne den Systemzustände und wie es dazu kam. In diesem Vortrag möchten wir gerne praktische Beispiele aus unserer Projekterfahrung mit Behörden und privaten Unternehmen einfließen lassen und aufzeigen, wie wir als Coaches und Berater einen nachhaltigen, individuellen Wandel begeleitet haben.

Zielpublikum: Tester:innen, Testautomatisierer:innen, Manager:innen, Führungskräfte, Entscheider:innen
Voraussetzungen: Projekterfahrung, Kenntnisse Software-Entwicklungs-Teams, Change-Management
Schwierigkeitsgrad: Anfänger

Extended Abstract:
In unserem Vortrag möchten wir skizzieren, wie wir den Wandel der IT-Abteilungen z.B. großer Behörden begleitet haben. Wir werden unsere Erfahrung von Beginn des Projekts
teilen und auch auf Ideen eingehen, die nicht funktioniert haben und wie wir damit umgegangen sind.

• Wie kamen wir an die notwendige Datenbasis? Wie können Interview-Leitfäden aussehen und wen sollte man befragen?
• Kann man überhaupt KPIs eines Change-Projekts bilden?
• Wie sieht eine Kommunikationsstrategie aus, von vorstandsgerechter Management- Summary bis zur detailreichen Kommunikation innerhalb der Abteilungen?
• Konnten wir Ideen generalisieren und wiederverwenden, oder ist alles individuell geschnitten?
• All das und noch viel mehr werden wir anhand eines agilen Lebenszyklusmodells behandeln und unsere Erfahrung mit Ihnen teilen.

Wir wollen in diesem Vortrag betonen, warum Quality Coaches in einer strategischen Position sind, um als Schnittstelle zwischen Test-Abteilungen, Management und Mitarbeiter:innen, den Wandel aktiv mitzugestalten.

Stell dir vor, wie viel Zeit UND Nerven du sparen könntest, wenn Kommunikation einfach mal funktionieren würde! Klingt wie ein Märchen für dich? Kennen wir. Richtige Kommunikation ist ein Skill, den unsere "T-Shape Teams" häufig erst noch erlernen müssen. Eine Möglichkeit ist durchs Coaching. Bei uns schlüpft der Quality Coach schnell mal in die Rolle des Übersetzers - ob von Wasserfall-Sprech zu Agile, von emotional zu sachlich, von technisch zu fachlich oder von kompliziert-chaotisch zu einfach-strukturiert. Geht nicht? Geht doch!

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager:innen, Entscheider:innen, Testmanager:innen, Quality Coaches, Tester:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Stell dir vor, wie viel Zeit UND Nerven du sparen könntest, wenn Kommunikation einfach mal funktionieren würde! Klingt wie ein Märchen für dich? Kennen wir.
Selbst mit einem Studium im Kommunikationsmanagement und als erfahrener Redakteur und Regisseur begegnen wir in unserem Alltag der Software-Entwicklung immer wieder Stolperfallen durch misslungene Kommunikation.
Auch Kommunikation ist ein Skill, den unsere "T-Shape Teams" häufig erst noch erlernen müssen. Eine Möglichkeit ist durchs Coaching. Bei uns schlüpft der Quality Coach schnell mal in die Rolle des Übersetzers - ob von Wasserfall-Sprech zu Agile, von emotional zu sachlich, von technisch zu fachlich oder von kompliziert-chaotisch zu einfach-strukturiert.
Und nicht nur das, die Rolle sensibilisiert und bringt den Leuten Tipps bei, ihre Kommunikation nachhaltig zu verbessern.
Setz dich in unser Theaterstück und erlebe ein Live-Coaching, aus dem du direkt einige wertvolle Tipps mitnehmen wirst. Wir werden einen Testmanager aus der Wasserfall-Welt mit einem agilen Tester auf der Bühne diskutieren lassen und schauen dann einem Quality Coach dabei zu, was ihm auffällt und wie sich das Ganze retten lässt. Am Ende schauen wir uns an, ob die beiden was daraus gelernt haben.
Wir werden Antworten auf folgende Fragen finden:
Sind Akzeptanzkriterien gleich Akzeptanzkriterien? Was können wir tun, um Kommunikation zu erleichtern? Wie arbeitet ein Quality Coach? Und warum tun sich Personen, die in der traditionellen Softwarelieferung arbeiten, so schwer, mit denen im agilen Liefermodus zusammen zu arbeiten, und andersrum genauso? Und natürlich: Was kann ich tun, damit mir Kommunikation gelingt?

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Viviane.Hennecke

In the evolving AI landscape, the EU AI Act introduces new standards for assuring high-risk AI systems. This presentation will explore the tester's role in navigating these standards, drawing from the latest research and from our experiences with an Automatic Employment Decision System, a high-risk AI. We'll discuss emerging methodologies, conformity assessments, and post-deployment monitoring, offering insights and practical guidance for aligning AI systems with the Act's requirements.

Target Audience: QA Professionals, AI Engineers/Architects, Business Leaders, POs/PMs, Policy Makers
Prerequisites: Basic Understanding of AI, Familiar with Testing, Awareness of EU AI Act, Interest in AI Asurance
Level: Advanced

Extended Abstract:
As the landscape of Artificial Intelligence (AI) rapidly evolves, the upcoming EU AI Act is set to introduce a new paradigm for assuring high-risk AI systems. This session will allow participants to delve into the pivotal role of testers in this context. We will decode the complexities of the Act and get to see how fostering the Act will ensure robust, transparent, and ethically aligned AI systems.
Drawing on recent research and my own experience in testing high-risk AI systems, I will discuss the emerging methodologies for testing high-risk AI, including explainability methods, robustness testing, and fairness testing. Together, we will also explore the Act's emphasis on conformity assessments and post-deployment monitoring, highlighting the tester's role in these processes. Participants will gain a unique behind-the-scenes look at how we have gone from chaos to order in testing an Automatic Employment Decision System, a high-risk AI.
Joining this session will equip participants with valuable insights and practical guidance on aligning AI systems with the EU AI Act. This is a must-attend for testers, AI developers, and business leaders alike who are navigating this new frontier, exploring the challenges, opportunities, and future directions in the assurance of high-risk AI systems. By the end of the session, participants will be better prepared to face the challenges posed by the EU AI Act and will have a clear understanding of the future directions in the assurance of high-risk AI systems.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/andrei.nutas

One of the fundamental challenges for machine learning (ML) teams is data quality, or more accurately the lack of data quality. Your ML solution is only as good as the data that you train it on, and therein lies the rub: Is your data of sufficient quality to train a trustworthy system? If not, can you improve your data so that it is? You need a collection of data quality “best practices”, but what is “best” depends on the context of the problem that you face. Which of the myriad of strategies are the best ones for you?

Target Audience: Developers, Data Engineers, Managers, Decision Makers
Prerequisites: None
Level: Advanced

Extended Abstract:
This presentation compares over a dozen traditional and agile data quality techniques on five factors: timeliness of action, level of automation, directness, timeliness of benefit, and difficulty to implement. The data quality techniques explored include: data cleansing, automated regression testing, data guidance, synthetic training data, database refactoring, data stewards, manual regression testing, data transformation, data masking, data labeling, and more. When you understand what data quality techniques are available to you, and understand the context in which they’re applicable, you will be able to identify the collection of data quality techniques that are best for you.

Das eigene Software-System in Microservices transformieren? Unabhängig davon, wir Softwerker sollten auch bestehenden Code entlang von Fachlichkeiten besser trennen. Wie gehen wir vor? Strangler-Pattern? Ist keine praktische Anleitung. Den Code in Geschäftsdomänen konzeptionell aufteilen und dann neu zu strukturieren? Klingt nach Big-upfront-Design.
Im Vortrag zeigen wir, wie man die bestehende Datenbasis über Code hinaus nutzen kann. Wie man z.B. die Features (im Issue-Tracker) oder die Beiträge der einzelnen Entwickler dabei berücksichtigt.

Zielpublikum: Architekt:innen, Projekt-/Technische Leiter:innen, Key Developer:innen, Manager:innen, Entscheider:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Das eigene Software-System in Microservices transformieren? Unabhängig davon, wir Softwerker sollten auch bestehenden Code entlang von Fachlichkeiten besser trennen. Wie gehen wir vor? Strangler-Pattern? Ist keine praktische Anleitung. Den Code in Geschäftsdomänen konzeptionell aufteilen und dann refactoren? Klingt nach Big-upfront-Design.
Im Vortrag zeigen wir, wie man die bestehende Datenbasis über Code hinaus nutzen kann. Wie man von Features (im Issue-Tracker) ausgeht, diese probeweise Domänen zuweist und deren Kopplungen (Überlappungen, Aufruf-Abhängigkeiten) im Code evaluiert. Damit dann den Refactoring-Bedarf lokalisieren und den Aufwand bewerten. Und wie automatisierte Refactoring-Vorschläge dabei eine Rolle spielen.
Die Herausforderungen sind die gleichen, wir müssen sie nur anders angehen.

Behandelte Problemstellungen:

1. Wie trennt man bestehenden Code nach fachlichen Verantwortlichkeiten?
2. Wie führt man das Ganze probeweise durch vor dem Refactoring/Coding?
3. Wie nutzt man die Features des Issue-Trackers dafür?
4. Wie nutzt man das Code-Repository dafür?
5. Wie wird der Refactoring/Redesign-Bedarf lokalisiert?
6. Wie bewertet man den Aufwand dafür?

Nutzen für den Teilnehmer:

1. Teilnehmer lernen ein praktisches Vorgehen zur Trennung des Codes entlang fachlicher Verantwortlichkeiten
2. Teilnehmer lernen mehr über architekturelle technische Schulden
3. Teilnehmer wohnen einem unterhaltsamen Vortrag bei :-)

In Projekten treffen wir oft auf zwei Arten von Architekturdokumentation:
Gar keine oder veraltet in gigantischem Umfang. Der Effekt ist der gleiche – es wird nichts mehr dokumentiert, begründet mit "Keine Zeit" oder "Das findet niemand mehr".
Wir stellen Euch den Architecture Communication Canvas (ACC) vor, mit welchem Ihr in kurzer Zeit die wichtigsten Aspekte Eurer Architektur dokumentieren und kommunizieren könnt. Mit Praxisbezug zeigen wir Euch, dass Dokumentation sparsam und dabei nützlich für Stakeholder sein kann – und Spaß macht!

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Grundwissen in Software-Architektur/Architekturdokumentation
Schwierigkeitsgrad: Anfänger

Extended Abstract:
In den meisten Projekten treffen wir auf folgende Arten von Architekturdokumentation:
Entweder gibt es gar keine Dokumentation, oder es existiert veraltete Dokumentation in gigantischem Umfang. Unabhängig davon ist der Effekt jedoch der gleiche – es wird nichts Neues mehr dokumentiert. Begründet wird dies meist mit "Das liest doch niemand", "Dafür haben wir keine Zeit" oder "Das findet ja niemand mehr". Kommt Euch bekannt vor? Dann ist dieser Vortrag genau das Richtige für Euch.
Wir stellen Euch heute den Architecture Communication Canvas (ACC) vor, mit welchem Ihr in kurzer Zeit die wichtigsten Aspekte Eurer Architektur dokumentieren und kommunizieren könnt. Der Canvas ist kompatibel zum arc42-Template, jedoch wesentlich kompakter. Mit Beispielen aus der Praxis sowie praktischen Tipps zeigen wir Euch, dass Dokumentation zugleich sparsam erstellt werden und dabei nützlich für Stakeholder sein kann – und das Ganze auch noch Spaß macht!

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/gernot.starke

Das Sicherstellen der Softwarequalität in Microservice-Architekturen ist eine echte Herausforderung: Unsere bewährten Ansätze skalieren nicht mehr für komplexe Systeme mit zahlreichen Komponenten.
Wir präsentieren unseren Ansatz, der die Softwarequalität in komplexen Microservice-Architekturen beherrschbar macht. Wir sammeln und visualisieren verschiedene Metriken an zentraler Stelle, setzen auf Alerting bei Anomalien und unterstützen damit unsere Teams, frühzeitig zu erkennen, wohin wir unsere Aufmerksamkeit gezielt lenken müssen.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Mit einer geschickten Kombination von Open-Source-Tools haben wir unser Problem gelöst, den Überblick über zahlreiche verteilte Repos und Komponenten zu behalten.
Wir betrachten dabei verschiedene Metriken: sowohl die Codequalität, als auch fachliche und technische Schulden, die Einhaltung von Architekturvorgaben und viele weitere.

Eine explizite Softwarearchitektur ist der Garant für erfolgreiche Softwareprojekte. Zur Unterstützung der Kommunikation braucht es eine inhaltlich hinreichende und aktuelle Dokumentation. Der Docs-as-Code-Ansatz unterstützt, indem die Dokumentation in Form leichtgewichtiger Text- und Grafikformate näher an den Quellcode gebracht, in der Versionsverwaltung abgelegt, mit leichtgewichtigen Entwicklerwerkzeugen (IDE/Texteditor, Build-Tools, CI/CD-Pipelines) bearbeitet und in die Softwareentwicklungsprozesse integriert wird.

Zielpublikum: Architekt:innen, Entwickler:innen, Entscheider:innen
Voraussetzungen: Grundlegende Kenntnisse von Architekturdokumentation und für automatisiertes Build-Management
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Der Vortrag stellt leichtgewichtige Methoden, Vorlagen und Tools vor, die zum Erstellen einer hochwertigen, sich selbst validierenden Softwaredokumentation eingesetzt werden. Wir schauen uns Ansätze wie Docs-as-Code, leichtgewichtige Textformate, Ablage in der Versionsverwaltung und die Einbettung in die Build- und Review-Prozesse an. Das Sichtbarmachen von Software-Architekturkonzepten im Code und das Einbinden von Software-Analyse-Werkzeugen ermöglichen den kontinuierlichen Abgleich der Soll- und Ist-Strukturen und machen die Architekturdokumentation lebendiger.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Falk.Sippach

Are you lost when folks talk about "quality" in the context of software? Just when you thought "high quality" means "good" and "QA" means "assure it's good", somebody hits you over the head with ISO 25010, where "quality" is just a neutral property of a software system. It's all a big happy pile of terminology quicksand where you sink faster the more you struggle for unambiguous and clear definitions. But we're here to help you out. We'll be looking at what's relevant about quality from a software architecture perspective.

Target Audience: Architects, Developers
Prerequisites: None
Level: Basic

Extended Abstract:
Among the prominent confusions is "quality requirements" vs. "functional requirements" - someone is sure to tell you that the first one is something not entirely unlike “non-functional” requirements. But if that distinction even is a thing, what's that "functional suitability" category of the ISO 25010 quality model? And where exactly do requirements even enter the picture? Once they do, how do we tell whether they are satisfied or not? And if they're not, how does all this terminology help with devising tactics for making things better? We'll separate out the taxonomy from the metrology, the metrology from the requirements, the functional from the non-functional (as far as this makes sense) and everything in between. We'll survey different ways of looking at quality and identify the murky areas where you need to be explicit about what you mean.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/michael.sperber

Managers and leaders worldwide struggle to decide between projects A, B, or both. Traditional estimation techniques fail because humans can't predict the future. This talk proposes a simulation-based approach inspired by investment strategies, industrial management, and poker playing. By leveraging AI, forecasting, and computing power, simulations offer a reliable and adaptable portfolio planning strategy. Rather than relying on human estimation, simulations streamline decision-making and provide reassurance.

Target Audience: Portfolio Managers, Product Leaders, CPO, CEO, CTO, Product Managers, Product Owners
Prerequisites: Beginner level probabilistic forecasting, familiarity with portfolio level decisions
Level: Basic

Extended Abstract:
Right now, around the world, managers and leaders are scratching their heads to try and answer the question “Should we take project A, B, or both?”. The techniques they are using, are woefully inadequate to answer their question because they rely on a skill humans don’t possess: predicting the future!
Estimation as a portfolio and risk management strategy relies on our ability to predict the future. But we don’t have that skill! What can we use instead then?
In this talk, we explore how we can learn from the world of investment (risk management), industrial management (process control), and poker playing (thinking in bets) to create a powerful simulation strategy that will streamline and reassure your portfolio planning team. Unlike humans, simulation can take as many ideas as you can throw at it, and can come up with the most likely winning scenarios quickly, repeatably, and is infinitely adaptable to future surprises.
Why rely on estimation when we can rely on AI, Forecasting, and the near-infinite computing power we have in even the most humble of spreadsheet programs?
Key Learnings

• Basics of simulating portfolio decisions
• Comparing simulation vs estimation for portfolio level decisions
• Examples of simulation use in complex scenario assessment, with N >> 1 options for decision
• How to effectively support decision making with simulation.

Heutzutage erfordern Systeme eine hohe Bandbreite an Qualitäten: immer online, schnell, robust, elastisch, skalierbar und sicher, oder was auch immer Ihre Interessenvertreter unter Qualität verstehen.
Ich erkläre, was Software-Entwicklungsprojekte brauchen: spezifische, konkrete und überprüfbare Qualitätsanforderungen, und warum bestehende Normen (wie ISO) in dieser Hinsicht nicht ausreichen.
Abschließend zeige ich einen pragmatischen, leichtgewichtigen (Open-Source-) Ansatz, der zu spezifischen und umsetzbaren Qualitätsanforderungen führt.

Zielpublikum: Entwicklungsteams
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Heutzutage erfordern Systeme eine beeindruckende Bandbreite an Qualitäten: immer online, schnell, robust, elastisch, skalierbar und sicher, oder was auch immer Ihre Interessenvertreter unter Qualität verstehen.
Und genau hier beginnt das Problem: Die Stakeholder wissen oft nicht genau, was ihre Qualitätsanforderungen sind. Und wenn sie es doch wissen, bleiben diese Anforderungen oft implizit.
Ich erkläre, was Software-Entwicklungsprojekte brauchen: spezifische, konkrete und überprüfbare Qualitätsanforderungen, und warum bestehende Normen (wie ISO) in dieser Hinsicht nicht ausreichen.
Abschließend zeige ich einen pragmatischen, leichtgewichtigen Ansatz, der zu spezifischen und umsetzbaren Qualitätsanforderungen führt.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/gernot.starke

The world is constantly changing. As IT professionals, we are aware of the intrinsic changeability of projects, contexts and our business, but the events of the last years have put this into sharper focus. How will external changes shape our teams and our work?
Alex looks at what factors are at work now, and what kinds of effects will they have on how we work, and the roles of testers and software professionals. She will also look at activities on an individual and company level, to best prepare ourselves for a nebulous future.

Target Audience: Everyone
Prerequisites: None
Level: Advanced

Extended Abstract:
The world is constantly changing, and everything is impermanent. As IT professionals, we are aware of the intrinsic changeability of projects, contexts and our business, but the events of the last years have put this into sharper focus. How will external changes shape our teams and our work?
How can we shape ourselves proactively in order to be able to respond to changes, make changes or our own and even thrive? Alex looks at what factors are at work now, and what kinds of effects will they have on how we work, and the roles of testers and software professionals. She will also look at concrete activities on an individual and company level, to best prepare ourselves for a nebulous future.

Im Architektur-Entwurf treffen wir ständig Architekturentscheidungen, die im besten Fall explizit, dokumentiert und verstanden sind. Aber wie praktisch wäre es, wenn man kontinuierlich prüfen könnte, ob diese Richtlinien auch eingehalten werden? Hier helfen Architecture Fitness Functions. Wir zeigen, wie man mit ArchUnit solche Fitness Functions schreibt, die die Struktur unseres Codes überprüfen, und wie man diese in den Entwicklungsprozess integriert. Außerdem zeigen wir, wie man mit der API von ArchUnit statische Codeanalysen durchführt.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Basis-Kenntnisse Java
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Architekturentscheidungen zu treffen und zu dokumentieren, ist aufwändig und mühsam, mit der Folge, dass Entscheidungen oft nur implizit getroffen werden und dann in Vergessenheit geraten, geschweige denn im Lauf der ständigen Weiterentwicklung eingehalten werden.
Architecture Fitness Functions dienen dazu, Architekturentscheidungen im besten Fall automatisiert zu überprüfen. So bekommt das Entwicklungsteam jederzeit Feedback, ob die Architektur noch den festgelegten Regeln entspricht.
Manche Entscheidungen wie Namenskonventionen lassen sich schon lange über altbekannte Tools wie Checkstyle abtesten. Komplexere Entscheidungen aber lassen sich nicht immer einfach prüfen – oder sie erfordern ein komplexes Metamodell, das aufwändig zu erstellen und zu pflegen ist. Hier kommt ArchUnit ins Spiel.
In unserem Talk stellen wir anhand konkreter Fragestellungen vor, wie man mit ArchUnit automatisiert Architekturentscheidungen überprüft und in einen Standard-Testzyklus einbindet. Dazu bringt ArchUnit von Haus aus eine ganze Reihe von Standard-Hilfsmitteln mit. Besser noch: Eigene Architekturregeln lassen sich leicht in Form von Tests definieren und so im automatisierten Build überprüfen. Zugleich sind die Architekturregeln über die Tests dokumentiert.
Beispiele: Sind Abhängigkeiten zwischen Komponenten richtig definiert? Sind Strukturen innerhalb einer Komponente richtig modelliert, z.B. als Onion-Architektur?
Dieselbe API von ArchUnit kann man aber auch für statische Codeanalyse einsetzen, deren Output nicht in einem Test, sondern als Input in weitere Tools eingeht. Damit lassen sich einfach kleine Helferlein schreiben, um gezielt über statische Code-Analyse Handlungsbedarf identifizieren und analysieren zu können.
ArchUnit lässt sich demnach für kleine, mittlere und komplexe Fragestellungen einsetzen. Das skaliert gut und ermöglicht eine leichtgewichtige und automatisierte Absicherung von Architekturentscheidungen.
Wir zeigen zahlreiche Beispiele direkt im Code und geben damit einen ausführlichen Überblick über die Benutzung der ArchUnit-API.

Die digitale Barrierefreiheit nimmt Fahrt auf und ist ein absolutes Trendthema. Eigentlich ist dazu alles schon gesagt worden, es muss nur noch realisiert werden. Es ist entscheidend, Barrierefreiheit systematisch in Arbeitsabläufe von Designern und Entwicklern zu integrieren. Drei Hauptfragen stehen im Fokus:

1. Warum wird Barrierefreiheit in Projekten oft nicht priorisiert?
2. Welche Bedürfnisse und Herausforderungen haben Designer & Entwickler?
3. Wie kann Barrierefreiheit in Entwicklungsprozesse integriert werden?

Zielpublikum: Designer:innen, Entwickler:innen, Projektleiter:innen, Manager:innen, Entscheider:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Unser Lösungsvorschlag:
Je weiter ein Projekt fortgeschritten ist, desto schwieriger wird es, Barrierefreiheit miteinzubeziehen. Das Problem vieler Ressourcen und Tools ist ihre retrospektive Natur: Sie beurteilen die Barrierefreiheit eines Produkts, wenn es bereits fertig ist. Zu diesem Zeitpunkt sind Änderungen oft zu aufwändig oder die Zeit zu knapp. Doch wie gewährleistet unser Ansatz, dass Barrierefreiheit in jede Prozessphase einfließt?

1. Handlungsorientierte Aufgaben bereitstellen: Designer und Entwickler benötigen umsetzbare Informationen. Oft sind Richtlinien und Standards zu abstrakt formuliert, um sie in Prozessen zu operationalisieren.
2. Klarheit über Verantwortlichkeiten schaffen: Jede Aufgabe wird einer konkreten Rolle zugewiesen. Barrierefreiheit ist die Verantwortung aller Teammitglieder, nicht nur von Entwicklern.
3. Aufzeigen von Aufgabenabhängigkeiten: Das fördert die Zusammenarbeit der Projektbeteiligten. Es wird aufgezeigt, welche Aufgaben voneinander abhängig sind.
4. „On-demand“ statt Informationsflut: Jede Aufgabe wird einer konkreten Projektphase zugeordnet. So stellen wir sicher, dass nur wesentliche Informationen der richtigen Person zum richtigen Zeitpunkt zur Verfügung stehen.

In this interactive training session, we will dive into the fascinating world of exploratory testing. Exploratory testing is a mindset and approach that empowers testers to uncover hidden defects, explore the boundaries of software systems, and provide valuable feedback to improve overall quality.
Through a combination of theory, practical examples, and hands-on exercises, participants will gain a solid understanding of exploratory testing principles and techniques, and learn how to apply them effectively in their testing efforts.

Max. number of participants: 12

Target Audience: Developers, Testers, Business Analysts, Scrum Masters, Project Manager
Prerequisites: None
Level: Basic

Extended Abstract:
In this interactive and engaging 3-hour training session, we will dive into the fascinating world of exploratory testing. Exploratory testing is a mindset and approach that empowers testers to uncover hidden defects, explore the boundaries of software systems, and provide valuable feedback to improve overall quality.
Through a combination of theory, practical examples, and hands-on exercises (with a E-Commerce Platform), participants will gain a solid understanding of exploratory testing principles and techniques, and learn how to apply them effectively in their testing efforts.
Whether you are a beginner or an experienced tester, this training will equip you with the skills and knowledge to become a more effective and efficient explorer of software.
Learning Outcomes:

1. Understand the fundamentals of exploratory testing and its importance in software development.
2. Learn various techniques and strategies for conducting exploratory testing.
3. Develop the ability to identify high-risk areas and prioritize testing efforts during exploration.
4. Acquire practical tips for documenting and communicating exploratory testing findings.
5. Gain hands-on experience through interactive exercises to apply exploratory testing techniques.
6. Enhance critical thinking and problem-solving skills to uncover hidden defects.
7. Improve overall testing efficiency and effectiveness by incorporating exploratory testing into your testing process.
8. Learn how to collaborate effectively with developers, product owners, and other stakeholders during exploratory testing.
9. Gain insights into tools and technologies that can support and enhance exploratory testing activities.
10. Leave with a comprehensive understanding of exploratory testing and the confidence to apply it in real-world scenarios.

Join us for this immersive training session, and unlock the potential of exploratory testing to uncover valuable insights and improve the quality of your software products.