35 years ago, Eliyahu Goldratt introduced the Theory of Constraints (ToC) in his seminal book "The Goal" as a new management paradigm for manufacturing plants, struggling with excess inventory, late deliveries, poor quality. The ToC solved this through five focusing steps - a guideline to systematic improvement and continuous learning.

Today, the ToC is one of the pillars of the DevOps movement. This talk will present its principles, and how it applies to the software industry, through a mix of theory, stories and experiences, and practical advice.

Target Audience: Architects, Developers, Project Leaders, Managers, Decision Makers
Prerequisites: Some previous knowledge of software delivery is helpful, but not required
Level: Basic

This talk will provide insights for a successful integration of lean-quality management to scaled agile projects. We will show based on our project experience that by improving process quality, higher product quality is achieved, resulting in significantly increased customer satisfaction. We will share how the lean principles and an easy-to-use toolkit helped us to tackle complex problems by providing a proven and scalable approach for continuous improvement and boost business agility at the same time.

Target Audience: Quality & Test Engineers, Agile Coaches, Project Managers, Quality Managers
Prerequisites: Solid agile knowledge, basic lean understanding, basic understanding of quality assurance
Level: Advanced

Das Projekt läuft, die Rahmenbedingungen sind abgesteckt, die Performance des Systems ist gut - ideale Bedingungen also. Leider ist die Realität oft anders. Der Nutzungskontext ändert sich und plötzlich muss ein Vielfaches der ursprünglichen Last bewältigt werden, natürlich in Erwartung gleichbleibender Qualität.

Wie man diese Herausforderung mit gezielten Maßnahmen aus dem Baukasten der Qualitätssicherung beherrschen kann, zeigen wir am Beispiel verschiedener Systeme, die wir auf dem Weg vom Projekt zum Produkt begleitet haben.

Zielpublikum: Tester:innen, Qualitätsmanager:innen, Entwickler:innen
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Das Projekt läuft, die Rahmenbedingungen sind abgesteckt, neue Anforderungen bewegen sich in diesem Rahmen, die Performance des Systems ist gut - ideale Bedingungen also. Leider ist die Realität oft anders. Die Software kommt auch in anderen Abteilungen der Kund:innen gut an und schnell erweitert sich der Nutzerkreis. Oder neue Kund:innen interessieren sich für die gleiche Software und schon wird aus einem Projekt für einen Kunden schnell ein Produkt, das verschiedene Kunden im Einsatz haben. Der Nutzungskontext ändert sich, die Anforderungen verlassen den gesteckten Rahmen und plötzlich sieht sich die Entwicklung damit konfrontiert, ein Vielfaches der ursprünglichen Datenmengen oder Anfragen managen zu müssen. Und natürlich gibt es die Erwartung gleichbleibender Qualität, insbesondere gleichbleibender Performance.

Wie schafft man es, die Hotspots schnell zu identifizieren? Wie helfen architekturelle Entscheidungen? Was sagt man den Kund:innen, welche Probleme die neue Last bedeutet, und wie schätzt man schnell ab, in welchem Zeitraum man diese beheben kann. Wie misst man, wie stark der Host skalieren muss, um zukunftsfähig zu bleiben? Wie muss man Last- und Performancetests gestalten, dass sie wirklich Antworten auf die Fragen geben?

Wie man diese Problemstellungen beherrschen kann, zeigen wir anhand verschiedener Beispiele, bei denen wir Systeme auf dem Weg vom Projekt zum Produkt begleitet haben. Wir stellen insbesondere die Maßnahmen vor, mit denen wir die Herausforderungen erfolgreich gemeistert haben.

Bevor wir uns in die Zukunft bewegen, in der wir unsere schicke neue Applikation oder unsere neuen Features auf echte Benutzer loslassen, sollten wir wissen, ob sie mit den zu erwartenden Anfragen umgehen kann.

Moderne Performance-Test-Tools unterstützen hier nicht nur durch einmalige manuelle Tests, sondern auch mit der Möglichkeit, Lasttests als Teil der Continuous-Integration-Pipelines durchzuführen. Dieser Vortrag soll mit Live-Demos eine Einführung in nötige Voraussetzungen bieten und aufzeigen, wie man Ergebnisse visualisieren kann.

Zielpublikum: Entwickler:innen, QA, Projektleiter:innen
Voraussetzungen: Basiswissen über Java, APIs und Continuous Integration sind von Vorteil, aber nicht dringend
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Regelmäßige Lasttests, auch schon während der Entwicklung, helfen dabei, möglichst gut einschätzen zu können, wie sich eine Anwendung samt ihrer Infrastruktur unter Last verhält, ob sie der anstehenden Nachfrage standhalten kann, oder ob sie vielleicht zu groß definiert ist.

Anhand von Demos mithilfe des Last-Test-Simulators "Gatling" wird gezeigt, wie man zu erwartende Last-Szenarien für eine (Web-)App als Code darstellen kann und wie sie je nach Anwendungsfall skaliert werden können.

Die Demo wird sich auch (kurz) damit beschäftigen, wie man mit Mocking für Dritt-Services umgehen kann, etwa wenn ein Service-Anbieter keine Performance-Tests gegen seine Dienste zulässt.

Die Ergebnisse lassen sich über Metrik-Exporte auch in modernen Visualisierungs-Tools wie Grafana anzeigen, auswerten und vergleichen.

80% of machine learning is said to be data wrangling. Is all this wasted effort? Hardly - often the journey really is its own reward.

In this talk, we'll briefly describe a machine learning project that predicts the outcome of test cases in a large-scale software development cycle. We'll then show what we gained from collecting the necessary data and how these insights can have lasting impact on the day-to-day work of developers, testers and architects. This includes a quick answer to the well-known question: Whose defect is it anyway?

Target Audience: Developers, Testers, Architects
Prerequisites: Basic knowledge of software development and testing and an interest in data analytics
Level: Basic

Extended Abstract:
Data science folk wisdom holds that at least 80% of machine learning consists of data wrangling, i.e. finding, integrating, annotating, and cleaning the necessary data.

While sometimes viewed as less "glorious" than the deployment of powerful models, this journey has its own rewards as well.

Benefits may sometimes be somewhat expectable, if still non-trivial, like data cleaning potentially exposing errors in underlying data bases.

In other cases, though, there may be some low-hanging fruit a casual glance might miss even though they are indeed rewarding.

Data integration often reveals opportunities for statistical analyses that are relatively simple, but may still have high impact.

In this talk, we'll start at the destination: the result of a machine learning project where we successfully predicted test results from code changes.

A necessary task was the integration of several data sources from the full software development cycle - from code to testing to release in a large industry project with more than 500 developers.
Naturally, this required all typical steps in the data science cycle: building up domain knowledge and problem understanding, both semantic and technical data integration, data base architecture and administration, machine learning feature design, model training and evaluation, and communicating results to stakeholders.

These steps yielded several benefits, on which we will focus in our talk.

Among others these include data quality insights (e.g. about actual "back to the future" timestamps), and new analyses which were made possible by a unified view of the data (e.g. survival analysis of defects).

Last but not least, we demonstrate a simple answer to a well-known question, especially in larger software development contexts: Whose defect is it anyway - how can we avoid assigning defects to teams that have nothing to do with them?

Thanks to the integrated information sources from systems concerned with version control, test result logging, and defect management, we are able to support the claims made in this talk with statistics taken from 6 years of real-world data.

Machine Learning hat uns privat längst erreicht: Netflix schlägt mir Filme vor, die mir oft sogar gefallen. Warum gibt es keine Software, die mir fundiert vorschlägt, was ich testen soll?

Es gibt Forschungsansätze, die das versprechen: Defect Prediction nutzt Machine Learning auf historischen Fehlerdaten, um vorherzusagen, wo am meisten Fehler sein sollen. Aber wie gut funktioniert das in der Praxis?

Wir haben solche Ansätze selbst implementiert und eingesetzt. In diesem Vortrag stelle ich die Ergebnisse aus Forschung und Praxis vor.

Zielpublikum: Entwickler:innen, Testende, Verantwortliche für Entwicklung und Test
Voraussetzungen: Interesse an Software-Test
Schwierigkeitsgrad: Fortgeschritten

Unsere Welt wird zunehmend von Technik geprägt. Technologie und Menschen sind stärker verwoben denn je - und die Tendenz steigt weiterhin. Dabei gibt es jetzt schon zu viele Beispiele, wie dieses Zusammentreffen schlecht funktioniert. Was bedeutet das für unsere technologische Zukunft? Was bedeutet das für Teams, Zusammenarbeit und Qualität?

Dieser Talk betrachtet die Zukunft durch die Augen eines Testers. Wir schauen gemeinsam in die Kristallkugel, um zu sehen, welche Faktoren zur vernünftigen Qualität in der Zukunft beitragen werden.

Zielpublikum: Testende, Entwickler:innen, Product Owner, Architekt:innen
Voraussetzungen: None
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Ich muss leider den Stereotyp eines Testers bestätigen: Ich habe schlechte Nachrichten über die Qualität der Zukunft.

Unsere Welt wird zunehmend von Technik geprägt. Nicht nur in der Industrie, sondern auch im privaten Umfeld. Technologie und Menschen sind stärker verwoben denn je - und die Tendenz steigt weiterhin.

Als Testerin seit über 12 Jahren sehe ich hier Risiken (nicht überraschend!). Und diese Risiken werden durch Erfahrung und aktuelle Beispiele bestätigt. Sind die Risiken und deren Wirkung noch vermeidbar? Sind es die Tester, die uns davor retten werden? Oder liegt die Antwort darin, der technischen Komplexität mit weiteren Technologien entgegenzuwirken? Und wenn ja, sind es nur noch Entwickler, die für Qualität sorgen können?

Dieser Talk betrachtet die spannende Zukunft durch die Augen eines Testers. Wir schauen gemeinsam in die Kristallkugel, um zu sehen, welche Faktoren zur vernünftigen Qualität in der Zukunft beitragen werden.

Nicht nur Menschen, auch Testsuiten geraten unter Stress. Solche Tests sind fragil, langsam in der Durchführung oder kosten auf andere Art Zeit und Nerven.In diesem Vortrag beschreibe ich, wie man diesen Stress abbauen kann. Dazu gehören:- Tägliche *A*temübungen mit *A*utomatischen Analysen, die Probleme in Tests beim Erstellen verhindern- *M*editation über einfache *M*etriken zur Früherkennung von Stress in Testsuiten- Yoga-*P*ositionen in Form von *P*rozessen und Aktivitäten, um die Qualität von Tests von Anfang an in den Griff zu bekommen.

Zielpublikum: Testende, Qualitätsmanager:innen, Entwickler:innen
Voraussetzungen: Grundkenntnisse Testen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Nicht nur Menschen (vor allem Software-Entwickler und -Tester), sondern auch Testsuiten geraten im Laufe ihres Lebens unter Stress. Woran zeigt sich das? Tests, die unter Stress stehen, sind fragil (also schlagen häufig fälschlich Alarm), langsam in der Änderung und Durchführung oder kosten auf andere Art Zeit und Nerven. Konkrete, messbare Symptome von Stress sind u. a. mehrdeutige Testfallbeschreibungen, eine unverständliche Struktur, unklare Testabdeckung oder zahlreiche Duplikate. Folgen des Stresses für das Projekt sind schlechte Software-Qualität und hohe Test- und Wartungskosten.In diesem Vortrag zeige ich Gründe für den Stress in Testsuiten auf. Vor allem aber beschreibe ich, wie man in Projekten diesen Stress abbauen kann. Dazu gehört:- Tägliche *A*temübungen mit *A*utomatischen Analysten, die Probleme in Testsuiten schon bei der Erstellung verhindern- *M*editation über einfache *M*etriken zur Erkennung von Stress in Testsuiten- *P*ositionen in Form von *P*rozessen und Aktivitäten, um die Qualität von Tests von Anfang an konstruktiv in den Griff zu bekommen.Wir haben diese Techniken seit etwa 5 Jahren in über 60 Projekten im Einsatz. In dem Vortrag berichte ich aus unseren Erfahrungen: Wann helfen diese Techniken der Testsuite Stress abzubauen? Und was steht auf dem Pfad zum inneren Gleichgewicht im Weg?

Mittlerweile wird die Infrastruktur immer mehr mithilfe von Code beschrieben und automatisiert. Klassische Betriebler mutieren auf einen Schlag zu Entwicklenden und müssen programmieren, um an ihre Infrastruktur zu kommen.

Doch ist auch allen Beteiligten klar, dass sie zu Programmierern geworden sind? Wenn man sich Entwicklungsprozess und Code anschaut, erinnern beide stark an die Fricklermentalität der 2000er: Juhuu, es läuft irgendwie.

Dieser Vortrag zeigt, was helfen kann, den Infrastruktur-Code qualitativ hochwertiger zu machen.

Zielpublikum: Entwickler:innen, Operation
Voraussetzungen: Grundkenntnisse aus IaC
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Mittlerweile wird die Infrastruktur immer mehr mithilfe von Code (Provisionierungsskripte, Dockerfiles, (Shell-) Skripte etc.) beschrieben und automatisiert. Klassische Betriebsabteilungen mutieren auf einen Schlag zu Entwicklungsabteilungen und müssen programmieren, um an ihre Infrastruktur zu kommen.

Doch ist auch allen Beteiligten klar, dass sie zu professionellen Programmierern geworden sind? Wenn man sich Entwicklungsprozess und Code anschaut, erinnern beide stark an die Fricklermentalität der 2000er: Juhuu, es läuft irgendwie, kein VCS, keine Qualitätssicherung mit Test oder Review.

Wenn es sich stark nach “normaler” Software-Entwicklung anfühlt, warum dann auch nicht die Best Practices und Lessons Learned der letzten 30 Jahren auf Infrastructure as Code adaptieren und somit die Qualität erhöhen? Müssen die frisch gebackenen OpsDevs die alten Fehler der Devs wiederholen? Kann man Infrastruktur-Code vielleicht sogar testgetrieben entwickeln?

Dieser Vortrag lädt zu einer Zeitreise ein, welche Best Practices in der Software-Entwicklung zur einer höheren Qualität geführt haben und wie diese Erkenntnisse helfen können, die Entwicklung von Infrastruktur-Code qualitativ hochwertiger zu machen.

Architekturbewertungen sichern Lösungsansätze ab, zeigen Risiken auf und schaffen Transparenz. In dieser Session wenden wir ausgewählte Bewertungsansätze passgenau auf eine aktuell im Rampenlicht stehende Software an: die deutsche Corona-Warn-App. Als Ergebnis erhalten Sie einen umfassenden Überblick über zeitgemäße Bewertungsmethodik mit den jeweiligen Vor- und Nachteilen der Ansätze und spannende Einblicke in die Funktionsweise des technisch anspruchsvollen, verteilten Softwaresystems.

Zielpublikum: Primär Software-Entwickler:innen und -architekt:innen, im Grunde alle mit Interesse an Software-Entwicklung
Voraussetzungen: Erfahrung in Software-Entwicklungsvorhaben (Rolle eigentlich egal)
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Architekturbewertungen sichern Lösungsansätze ab, zeigen Risiken auf und schaffen Transparenz. Im Juni 2020 hatte das Virus die Welt fest im Griff, als die deutsche Corona-Warn-App zum Download bereitstand. Das Vertrauen der Bevölkerung in die Software war entscheidend — ohne breite Beteiligung wäre sie zum Scheitern verurteilt.

Was kann Architekturbewertung hier leisten? Der Softwarehersteller hat neben umfassender Dokumentation immerhin auch den kompletten Quelltext offengelegt. Das eröffnet die Möglichkeit einer fundierten Analyse. Im Umfeld der Architekturbewertung gibt es ein reiches Arsenal an Methoden und Werkzeugen. Sie reichen von qualitativen Ansätzen wie ATAM bis zum Auswerten von Metriken oder dem Messen von Antwortzeiten, Durchsatz oder ähnlichem.

In dieser Session wenden wir ausgewählte Bewertungsansätze passgenau auf die Corona-Warn-App an. Unsere Zuhörenden nehmen daher gleich zwei Dinge mit: Einen umfassenden Überblick über zeitgemäße Bewertungsmethodik mit den jeweiligen Vor- und Nachteilen der Ansätze. Und Einsichten in die Funktionsweise der Corona-Warn-App. Mit ihren Stärken, Schwächen und Kompromissen. Hätte man das nicht auch alles ganz anders machen können. Klar, aber was wären die Konsequenzen gewesen? Finden Sie es gemeinsam mit uns heraus!

AI is maybe the most powerful tool our generation has available. Andrew NG called it "the new electricity". But what does it take to build AI enabled products? What are the key elements to achieve production grade AI? How does it impact your development process? How can quality be achieved? These are the questions this talk tries to answer. You will get an idea why the industry is talking about nothing less than a paradigm shift when it comes to developing AI based products.

Target Audience: Everyone interested in the shift from classical software engineering to data driven AI applications
Prerequisites: Interested in AI, how it works and its impact on engineering departments
Level: Advanced

Extended Abstract:
AI is maybe the most powerful tool our generation has available. Andrew NG called it "the new electricity". Most likely you used an AI based product within the last 3 hours, maybe without even noticing it. But what does it take to build AI enabled products? What are the key elements to achieve production grade AI? How does it impact your development process? How can quality be achieved? These are the questions this talk tries to answer. In addition we will look into the different stages of AI development and the tools which can help to make this process more efficient. You will get an idea why the industry is talking about nothing less than a paradigm shift when it comes to developing AI based products.

Whether evolution or revolution, or yet old wine in new skins, for more than 10 years, DevOps is changing how we develop and deliver software. This session looks back on the roots of DevOps, its movement until today, and current as well as possible future directions. This interactive session aims to offer a set of fruitful starting points for reflection and discussions.

Target Audience: Anyone interested in developing and delivering software
Prerequisites: Knowledge in DevOps and agile software development
Level: Advanced

Ein halbes Jahrhundert der Software-Entwicklung ist von einem überraschenden Phänomen geprägt: Wir, die Entwickler:innen + Architekt:innen, haben nicht nur immer wieder neue Technologien und Architekturansätze geschaffen, sondern auch Methoden entwickelt, die über die reine Programmierung hinausgehen. Projektleiter, Anwender, Betrieb und Tester haben von unseren Innovationen profitiert. Dieser Vortrag berichtet über die erstaunlichen Beiträge, die unsere Disziplin konzipiert und entwickelt hat, und wagt einen Blick in die Zukunft unserer Disziplin.

Zielpublikum: Alle
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Nach diesem Vortrag werden die Teilnehmenden voller Motivation ihre Reise durch die OOP antreten.

Neben dem Blick in die Vergangenheit wird die Zukunft unserer Disziplin den Schwerpunkt dieses Vortrags bilden.

Unter „Resilienz“ versteht man die Fähigkeit von Systemen, auch unter massiven Störungen von außen ihre Funktionsfähigkeit zu erhalten. Die Coronakrise mit ihren massiven Einschnitten und Opfern hat uns vor Augen geführt, dass Resilienz von Unternehmen entscheidend sein kann für das weitere Überleben. In diesem Vortrag betrachten wir Situationen, in denen Resilienz von besonderer Bedeutung ist, und leiten daraus ab, welche Voraussetzungen Unternehmen erfüllen müssen, um Resilienz zu zeigen. Spoiler: Auch Agilität spielt dabei eine Rolle ...

Zielpublikum: Manager:innen, Entscheider:innen, Organisations-Entwickler:innen, Coaches
Voraussetzungen: Verständnis über Unternehmenssteuerung und Agilität
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Roter Faden dieses Talks ist eine Analogie zwischen der Situation, in der sich Unternehmen während der Coronakrise befanden und noch immer befinden, und den (frei interpretierten) Phasen der Behandlung lebensbedrohlicher medizinischer Notfälle, für die sich in den letzten 50 Jahren weltweite Standards etabliert haben (nein, es wird keine Schockfotos geben. Mir geht es um Taktik und Strategie, nicht um Sensationslust).

Für jede der Phasen (unmittelbare Existenzsicherung, Ursachenfindung, Aufbau von Handlungsoptionen, Ausprobieren der Optionen, Einrichten auf die neue Normalität) wird analysiert, welche Eigenschaften und Praktiken Unternehmen dabei unterstützen oder behindern und wie man sie fördern kann. Dass dabei viele Ähnlichkeiten mit agilen Ansätzen aufscheinen, ist nicht überraschend, wichtig sind aber auch die Bereiche, in denen Agilität alleine nicht ausreicht.

Was hat das mit Tintenfischen zu tun? Diese kommen aus einer Analogie der "Supporting Agile Adoption"-Arbeitsgruppe der Agile Alliance, in der Oktopusse als Beispiel für einen völlig anders organisierten Organismus dienen, der dezentral mit neun Gehirnen kognitive Leistungen erbringt, die sich mit intelligenten Säugetieren messen lassen können. Es zeigt sich, dass die Fähigkeit von Organisationen, Entscheidungen verteilt fällen zu können, ihre Resilienz wesentlich verbessern kann.

The Test Pyramid is an efficient and effective approach for Software Testing but does not come with any details about concrete test methods or fixtures.

In my talk I will show you how to combine the principles of the Test Pyramid and the C4 Model for Software Architecture to elaborate a specific test strategy for your software product in a simple manner.

Target Audience: Architects, Developers, QA Engineers
Prerequisites: Basic knowledge in Software Architecture and QA Engineering
Level: Advanced

Extended Abstract:
Software tests have to specify the behaviour of your product as extensive and reliable as possible. At the same time their implementation and maintenance costs should be kept at a minimum.

As Kent Beck said before: "I get paid for code that works, not for tests".

The Test Pyramid is a proven approach for this problem but leaves a lot of room for interpretation when elaborating a test strategy for your product.

Furthermore there are a lot of partly contradictory definitions of Unit, Service and Integration Tests and variations like “Test Diamond” and “Test Trophy” make it even more confusing. So, how do we get from the Test Pyramid to a concrete test strategy?

In my talk I will show you how to combine the principles of the Test Pyramid and the C4 Model for Software Architecture to obtain a test concept tailored for your product. Examples taken from a recent project will demonstrate how this approach balances test coverage, maintainability and development costs.

Raiffeisen Bank International (RBI) started in 2017 with “Group Digital Solutions” a journey in order not to oversleep the digitization of the banking industry.

Due to new approaches such as DevSecOps & Continuous Testing, the topic of software tests, whether manual or automated, had to be completely redesigned and implemented.

This talk gives insights into the test strategy & the fullstack test automation architecture that were used.

Target audience: testers, developers, architects, managers
Prerequisites: none
Level: Advanced

Extended Abstract:
So that Raiffeisen Bank International can keep up with digitization in the banking sector, the company relies on the use of native apps, microservices and REST APIs in the Amazon cloud when implementing its mobile banking strategy. 

In order to support the DevOps mantra "Automate everything", a full stack test automation strategy was developed that is based on open source tools and takes all components of the system architecture into account.

The independent services of the microservice architecture make additional interfaces visible that are not available in a monolithic architecture. The advantage is that they can be deployed and tested independently of each other.

Testing these systems is much more complex than testing a conventional monolithic application and needs additional demands on test automation, with classic integration tests being even more important for the overall structure. 

These integration tests were usefully supplemented by consumer contract tests. But end-2-end tests should not be missing either, since an effective test strategy must take into account both the isolated testing of individual services and the verification of the overall system behavior.

Aligning test automation with the classic test pyramid is a very useful approach if the individual layers are seen as the basis for “what is being tested” and not as a measure of the number of tests. Because the old wisdom still counts: “Quality over quantity!”.

Throw a line of code into many codebases and it’s sure to hit one or more testing frameworks. There’s no shortage of frameworks for testing, each with their particular spin and set of conventions and, but that glut is not always matched by a clear vision of how to structure and use tests — a framework is a vehicle, but you still need to know how to drive.

Compared to many languages, C++ has had slower widespread adoption of unit testing. This talk takes a deep dive into the practices and issues, looking at examples and counterexamples in C++.

Target Audience: C++ developers
Prerequisites: C++ programming
Level: Advanced

Autonomous and automated systems are increasingly being used in IT such as finance, but also transport, medical surgery and industry automation. Yet, the distrust in their reliability is growing. This presentation introduces the validation of autonomous systems. We evaluate in practical situations such as automatic driving and autonomous robots different validation methods. The conclusion: Classic methods are relevant for coverage in defined situations but must be supplemented with cognitive test methods and scenario-based testing.

Target Audience: Testers, Quality assurance, Architects, Requirements Engineers, Product Owners, Software Engineers
Prerequisites: Testing basic know-how
Level: Advanced

Extended Abstract:
Autonomous and automated systems are increasingly being used in IT such as finance, but also transport, medical surgery and industry automation. Yet, the distrust in their reliability is growing. There are many open questions about the validation of autonomous systems: How to define reliability? How to trace back decision making and judge afterwards about it? How to supervise? Or, how to define liability in the event of failure? The underlying algorithms are difficult to understand and thus intransparent. Traditional validations are complex, expensive and therefore expensive. In addition, no repeatable effective coverage for regression strategies for upgrades and updates is available, thus limiting OTA and continuous deployment.

With artificial intelligence and machine learning, we need to satisfy algorithmic transparency. For instance, what are the rule in an obviously not anymore algorithmically tangible neural network to determine who gets a credit or how an autonomous vehicle might react with several hazards at the same time? Classic traceability and regression testing will certainly not work. Rather, future verification and validation methods and tools will include more intelligence based on big data exploits, business intelligence, and their own learning, to learn and improve about software quality in a dynamic way.

Verification and validation depend on many factors. Every organization implements its own methodology and development environment, based on a combination of several of the tools presented in this presentation. It is however relevant to not only deploy tools, but also build the necessary verification and validation competences. Too often we see solid tool chains, but no tangible test strategy. To mitigate these pure human risks, software must increasingly be capable to automatically detect its own defects and failure points.

Various new intelligent validation methods and tools are evolving which can assist in a smart validation of autonomous systems.

This presentation introduces the validation of autonomous systems. We evaluate in practical situations such as automatic driving and autonomous robots different validation methods. The conclusion: Classic methods are relevant for coverage in defined situations but must be supplemented with cognitive test methods and scenario-based testing.

Automatisiertes Testen von Funktionalität ist heutzutage Standard und ermöglicht kurze Releasezyklen. Für die Software-Architektur ist die resultierende hohe Änderungshäufigkeit eine Herausforderung und führt in vielen Projekten zu Architektur Drift und Erosion.

In der Session behandeln wir das systematische Testen von Software-Architektur. Sie bekommen einen Überblick über gängige Methodik und Lösungen anhand von Beispielen aus realen Projekten. Im Praxisteil lernen Sie, wie Architektur einfach automatisiert getestet werden kann.

Zielpublikum: Software-Architekt:innen, Entwickler:innen, Projektleiter:innen
Voraussetzungen: Grundkenntnisse Software-Architektur und Testautomatisierung
Schwierigkeitsgrad: Fortgeschritten

Um agiler auf Kundenbedürfnisse einzugehen und Entwicklungszyklen zu verkürzen, setzt die DATEV in der Breite auf Cloud-native Microservice Architekturen. Teams sollen damit in die Lage versetzt werden, weitgehend autonom an ihren Themen zu arbeiten und dabei kontinuierlich Wert zu liefern.

Wir berichten von unseren praktischen Erfahrungen, wie Teams nun qualitätsgetrieben ihre Systeme entwickeln und durch den Einsatz diverser Testmethoden die Erfüllung der geforderten Qualitätsanforderungen absichern: Architecture Fitness Functions demystified!

Zielpublikum: Entwickler:innen, Architekt:innen, Entscheider:innen, Product Owner, Projektleiter:innen
Voraussetzungen: Architekturkenntnisse, Grundwissen Testing
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Seit einigen Jahren wird das kontinuierliche Prüfen der Architektur und deren Tauglichkeit oder eben Fitness für die Nutzerbedürfnisse unter dem Schlagwort Architecture Fitness Function thematisiert.

Die DATEV eG befindet sich sowohl in einer technologischen als auch organisatorischen Modernisierung. Mit dem Ziel, schneller Wert für den Kunden zu liefern, entwickeln wir mehr und mehr Cloud-native Microservice-Architekturen, auf dessen Grundlage Teams weitgehend autark an ihren Themen arbeiten können. Dabei beschäftigte uns auch der agile Architekturentwurf, der Over-Engineering und aufwendige Big-Upfront-Designs vermeiden soll. Teams starten mit einer schlanken (lean) Architektur, die sich iterativ weiterentwickelt. Die Gratwanderung zwischen Entwickeln auf Sicht und dem nachhaltigen, systematischen Architekturentwurf meistern wir nun durch den frühzeitigen und konsequenten Einsatz der Architecture Fitness Functions.

In diesem Vortrag berichten wir von unserem begangenen Weg, diese Methode immer effektiver und effizienter im Projektalltag anzuwenden. Die Einführung und insb. das Demystifizieren des Begriffs Fitness Functions dauerte eine Weile. Wir zeigen unsere Maßnahmen auf: Wie und welches Fundament schufen wir dafür? Wie veränderten wir das Rollenzusammenspiel im Entwicklungsprozess und wie sorgten wir für die entsprechende Vorbereitung und Fokussierung? Leider war auch der Weg zu wirklich überprüfbaren Qualitätsanforderungen steinig. Aber wir konnten durch passende Techniken wie bspw. Quality Fathoming auch dort den Zustand deutlich verbessern.

Wir zeigen unsere ersten Gehversuche mit Tests der Architekturfitness und wie heute unsere Testnetze zur kontinuierlichen Überprüfung und Visualisierung der Architekturfitness aussehen. Zudem demonstrieren wir, wie sich unser agiler Architekturentwurf und die daraus resultierenden Architekturen durch den Einsatz von Fitness Functions verändert haben.

SAP-Projekte werden häufig von Unsicherheiten zum Testumfang sowie langen Testphasen, die die Fachseite blockieren, begleitet.

Um mit diesen Herausforderungen umgehen zu können, wurde im Rahmen eines Projektes eine zusätzliche Testphase eingeführt. In dieser wurde das System, vom verantwortlichen Testmanagement, vor Übergabe an die Fachseite getestet.

Dies war ein ungewöhnlicher Schritt, da SAP als ein System gilt, welches nur von Key-Usern und SAP-Expert:innen getestet werden kann. In diesem Vortrag teilt die Referentin ihre Erfahrung mit diesem Vorgehen.

Zielpublikum: Test-, Projektmanager:innen, Projektleiter:innen, Entscheider:innen
Voraussetzungen: Grundsätzliches Verständnis von Testmanagement
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Die Komplexität von SAP-Projekten ergibt sich durch die Anzahl der betroffenen SAP-Module und ihrer Schnittstellen zu anderen Systemen sowie der Summe der betroffenen Gesellschaften, Länder oder Werke.

Projektteams sehen sich hier vielen Herausforderungen gegenüber, eine davon ist der Testbereich. Sicher, SAP-Expert:innen prüfen die von ihnen angepassten Funktionalitäten technisch und Key-User testen Geschäftsprozesse aus Anwendersicht, doch gerade bei Customizing Einstellungen und individuellen Erweiterungen ergeben sich für alle Beteiligten schnell Unsicherheiten zur Testdurchführung.

Zumeist stellen sich Fragen wie:

• Was soll getestet werden?
• Sind die notwendigen Berechtigungen und Rollen bekannt?
• Wie verhindern wir Redundanzen und stellen sicher, dass die richtigen Testfälle getestet werden?
• Wie managen und bereinigen wir Testdaten?

Die Implementierung eines standardisierten Testmanagement-Prozesses schafft die nötige Transparenz, um Fachabteilungen und ihre Anforderungen zu steuern.

Im Rahmen eines Projektes wurde das System, vor Übergabe an die Fachseite, zusätzlich durch das Testmanagement-Team manuell getestet. Die Rolle des Testmanagers ähnelte damit eher der eines agilen Testers, mit planerischen und operativen Aufgaben. Dieses Vorgehen brachte Vorteile aber auch Herausforderungen mit sich.

Beispielsweise wurde zur Vorbereitung der Testfallerstellung ein Review der Anforderungsdokumente durchgeführt. Hierbei entstanden Fragestellungen, durch deren Klärung die Qualität der gelieferten Software deutlich erhöht werden konnte.

Aber auch in der Testdurchführung ergaben sich spannende Erfahrungswerte. Um mit dieser zusätzlichen Testphase wirkliche Mehrwerte liefern zu können, war eine zeitintensive Abstimmung zwischen Fachseite und Testmanagement entscheidend.

In dieser Session teilt die Referentin ihre Erfahrungswerte zu Herausforderungen und möglichen Lösungen, welche sich durch die Nutzung von Testmanagement in SAP-Projekten ergeben.

Miltenyi Biotec ist ein global agierendes Biotechnologie- und Biomedizin-Unternehmen. Es ist der führende Anbieter von Produkten zur magnetischen Zellsortierung und -analyse (MACS). Die Firma ist eines der größten deutschen Unternehmen der Biotechnologie-Branche.