RÜCKBLICK AUF DAS PROGRAMM 2021

Thema: Testing & Quality

Nach Tracks filtern
Nach Themen filtern
Alle ausklappen
  • Montag
    08.02.
  • Dienstag
    09.02.
  • Mittwoch
    10.02.
  • Donnerstag
    11.02.
  • Freitag
    12.02.
, (Montag, 08.Februar 2021)
10:00 - 13:00
Mo 5
(AUSGEBUCHT) Future Testing with Built-in Quality
(AUSGEBUCHT) Future Testing with Built-in Quality

We know that quality cannot be tested into our products afterwards, but we typically could do much more in our testing approach to built-in quality right from the beginning. But how does this look like in practice?

This interactive tutorial provides practical guidance on the needed strategies, tactics, and practices in different areas, and shares experiences and lessons learned to do better testing in the future!

Maximum number of participants: 25

Target Audience: Test Architects, Software Architects, Test Engineers, Product Owners, Quality Managers, Developers
Prerequisites: Basic knowledge about testing and quality engineering
Level: Advanced

Extended Abstract:
Today we have to deal with shorter time-to-market, increasing complexity and more agility while keeping quality and other key system properties high. Our test systems increase in size, volume, flexibility, velocity, complexity and unpredictability. Additionally, digitalization requires more than just a face lift in testing.

We know that quality cannot be tested into our products afterwards, but we typically could do much more in our testing approach to built-in quality right from the beginning:

  • This means even an improvement to classical defect prevention: defect prevention is good, but just “avoiding” some defects does not mean that we build something really “right”.
  • This is more than just the trendy shift-left approach in DevOps.

But how does this look like in practice?

This interactive tutorial provides practical guidance on the needed strategies, tactics, and practices in different areas, and shares experiences and lessons learned:

  • Requirements and test-driven approaches (xTDD)
  • Utility trees and quality models
  • Scenario descriptions and test design techniques
  • Design strategies and design tactics
  • Design for Testability and test architectures
  • Mindset by example

Attend this tutorial and do not only learn what built-in quality really means but be enabled to apply the strategies, tactics, and practices as a major lever for better testing in the future!

Peter Zimmerer is a Principal Key Expert Engineer at Siemens AG, Corporate Technology, in Munich, Germany. For more than 25 years he has been working in the field of software testing and quality engineering. He performs consulting, coaching, and training on test management and test engineering practices in real-world projects and drives research and innovation in this area. As ISTQB® Certified Tester Full Advanced Level he is a member of the German Testing Board (GTB). Peter has authored several journal and conference contributions and is a frequent speaker at international conferences.

Peter Zimmerer
Peter Zimmerer
Vortrag: Mo 5
flag VORTRAG MERKEN

Vortrag Teilen

, (Dienstag, 09.Februar 2021)
09:00 - 10:45
Di 3.1
I Have 99 Problems - Where Do I Start? The Theory of Constraints Applied
I Have 99 Problems - Where Do I Start? The Theory of Constraints Applied

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

Tobias Goeschel started his career as a freelance web developer in 1997, and has since worked on hundreds of projects in many roles, contexts, and industries.

He strives to help customers to build and improve not only their product, but also how it is made.

He is a passionate advocate for collaborative work environments, knowledge sharing, and diversity.

Thierry De Pauw is an Engineer at the fintech startup PaxFamilia.

On the side, he founded ThinkingLabs where he advises organisations in the adoption of Continuous Integration and Continuous Delivery.

Thierry is a lean software engineer, junior ops engineer, CI/CD advocate and jack-of-all-trades with a passion to help teams create meaningful software, with a keen eye for code quality and the software delivery process, from customer interaction to continuous delivery. Instead of balancing quality and delivery, he believes and practices, that better quality is actually a way to more and better deliveries.

Lean Quality Management – How to Integrate Quality Assurance into Scaled Agile Projects
Lean Quality Management – How to Integrate Quality Assurance into Scaled Agile Projects

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

Thomas Karl ist Enterprise Agile Coach und Advisor mit Schwerpunkt auf organisatorischem Wandel, Qualitätsmanagement und Prozessverbesserung. Er unterstützt Kunden bei großen agilen Transformationen. Als Anwender, Trainer und Coach befasst er sich umfassend mit agilen Methoden wie SAFe, Scrum, Kanban und Lean Six Sigma auf der einen Seite. Auf der anderen Seite bringt er aber auch sein Wissen als Systemischer Coach und Business Trainer in den Transformationsprozess ein. Darüber hinaus befasst er sich auch wissenschaftlich im Rahmen seiner Dissertation mit dem Themenbereich Agiles Management und agile Methoden. Als Sprecher auf Fachkonferenzen und Autor von -artikeln ist er stets im regen Austausch mit der Agilen Community.
Bettina Hillringhaus is a Lean QM expert with focus on complex large-scale agile SAP S/4HANA delivery projects. She has deep knowledge in test automation, QM & test automation strategy and quality architecture.
Tobias Goeschel, Thierry de Pauw
Thomas Karl, Bettina Kathrin Hillringhaus
Tobias Goeschel, Thierry de Pauw
Vortrag: Di 3.1-1

Vortrag Teilen

Thomas Karl, Bettina Kathrin Hillringhaus
Vortrag: Di 3.1-2
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:45
Di 8.1
Performance ist nicht statisch
Performance ist nicht statisch

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.

Dr. Dehla Sokenou promovierte 2005 an der TU Berlin über UML-basiertes Testen. Sie fühlt sich in allen Phasen der Software-Entwicklung zu Hause, einen besonderen Schwerpunkt bilden allerdings auch weiterhin alle Themen rund um Qualitätssicherung und Testen. Bei WPS - Workplace Solutions ist sie als Test- und Qualitätsmanagerin sowie Software-Architektin tätig. Daneben ist sie ein aktives Mitglied der GI-Fachgruppe TAV und im Sprechergremium des Arbeitskreises Testen objektorientierter Programme.
Continuous-Performance-Testing - Regelmäßig prüfen, ob man noch mit den Anfragen mitkommt
Continuous-Performance-Testing - Regelmäßig prüfen, ob man noch mit den Anfragen mitkommt

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.

Christian Kühn ist Softwareentwickler bei dmTECH
Er freut sich über das beste aus den beiden Welten Development und Operations und beschäftigt sich mit Java, Cloud-Infrastruktur und Sicherheitsthemen. Er organisiert das DevOps Meetup Karlsruhe und twittert unter: @CYxChris
Dehla Sokenou
Christian Kühn
Dehla Sokenou
Vortrag: Di 8.1-1

Vortrag Teilen

Christian Kühn
Vortrag: Di 8.1-2
flag VORTRAG MERKEN

Vortrag Teilen

14:00 - 14:45
Di 8.2
Back to the Data - Now That We (Machine) Learned From Test Results, What Else Did We Gain?
Back to the Data - Now That We (Machine) Learned From Test Results, What Else Did We Gain?

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.

Gregor Endler holds a doctor's degree in Computer Science for his thesis on completeness estimation of timestamped data. His work at codemanufaktur GmbH deals with Machine Learning and Data Analysis.
Marco Achtziger is Test Architect working for Siemens Healthcare GmbH in Forchheim. He has several qualifications from iSTQB and iSQI and is a certified Software Architect by Siemens AG.
Gregor Endler, Marco Achtziger
Gregor Endler, Marco Achtziger
flag VORTRAG MERKEN

Vortrag Teilen

16:15 - 17:15
Di 8.3
Kann uns AI helfen, besser zu testen?
Kann uns AI helfen, besser zu testen?

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

Dr. Elmar Juergens hat über statische Codeanalyse promoviert und für seine Doktorarbeit den Software-Engineering-Preis der Ernst Denert-Stiftung erhalten. Er ist Mitgründer der CQSE GmbH und begleitet seit zehn Jahren Teams bei der Verbesserung ihrer Qualitätssicherungs- und Testprozesse. Elmar spricht regelmäßig auf Forschungs- und Industriekonferenzen und wurde für seine Vorträge mehrfach ausgezeichnet. Elmar wurde 2015 zum Junior Fellow der Gesellschaft für Informatik ernannt.
Elmar Juergens
Elmar Juergens
flag VORTRAG MERKEN

Vortrag Teilen

17:45 - 18:45
Di 6.4
Wird schon schiefgehen: Qualitätssicherung und die Rolle von Testern im IoT
Wird schon schiefgehen: Qualitätssicherung und die Rolle von Testern im IoT

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.

Alex Schladebeck ist eine Testerin aus Leidenschaft. Ihr Herz schlägt für Qualität, Agilität und ihre Mitmenschen. Sie ist Geschäftsführerin und Leiterin der Qualitätssicherung bei der Bredex GmbH.

In diesen Rollen unterstützt sie Kollegen, Kunden und Teams auf ihrer Reise, bessere Qualität zu liefern: in Produkten, in Prozessen und in der Kommunikation.

In früheren Rollen war sie für die Befähigung von Teams und qualitativ hochwertige Systeme verantwortlich. Nun befähigt sie andere, genau das zu machen, und sorgt für eine Umgebung in der Firma, wo jede(r) aufblühen kann.

Alex schaut mit neugierigen Tester-Augen auf die Welt und möchte immer dazu lernen. Sie teilt ihr Wissen und ihre Erfahrungen in Workshops, Coachings und als Sprecherin oder Keynote-Sprecherin auf Konferenzen.
Alex Schladebeck
Alex Schladebeck
Vortrag: Di 6.4
flag VORTRAG MERKEN

Vortrag Teilen

17:45 - 18:45
Di 8.4
Testsuite Yoga – Software-Tests zurück ins Gleichgewicht bringen
Testsuite Yoga – Software-Tests zurück ins Gleichgewicht bringen

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?

Dr. Henning Femmer ist einer der Gründer von Qualicen. Bei Qualicen hilft Henning unterschiedlichsten Firmen bei der Einführung von Text-Analytics-Ansätzen. Er hat im Bereich Software Engineering an der Technischen Universität München promoviert und ist unter anderem im Steering Committee des Artificial Intelligence for Requirements Engineering Workshops tätig. Henning ist häufig Speaker auf nationalen und internationalen Konferenzen.
Henning Femmer
Henning Femmer
Vortrag: Di 8.4
flag VORTRAG MERKEN

Vortrag Teilen

17:45 - 18:45
Di 9.4
Infrastructure as Code - Muss man nicht testen, Hauptsache es läuft
Infrastructure as Code - Muss man nicht testen, Hauptsache es läuft

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.

Sandra Parsick ist als freiberufliche Software-Entwicklerin und Consultant im Java-Umfeld tätig. Seit 2008 beschäftigt sie sich mit agiler Software-Entwicklung in verschiedenen Rollen. Ihre Schwerpunkte liegen im Bereich der Java-Enterprise-Anwendungen, agilen Methoden, Software Craftsmanship und in der Automatisierung von Software-Entwicklungsprozessen. Darüber schreibt sie gerne Artikel und spricht gerne auf Konferenzen.
In ihrer Freizeit engagiert sich Sandra Parsick in der Softwerkskammer Ruhrgebiet, einer Regionalgruppe der Software Craftmanship Community im deutschsprachigen Raum. Seit 2019 ist sie Mitglied im Oracle Groundbreaker Ambassador Programm.
Sandra Parsick
Sandra Parsick
flag VORTRAG MERKEN

Vortrag Teilen

, (Mittwoch, 10.Februar 2021)
09:00 - 10:30
Mi 1.1
So gehen Architektur-Reviews! Die deutsche Corona-Warn-App unter der Lupe
So gehen Architektur-Reviews! Die deutsche Corona-Warn-App unter der Lupe

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!

Stefan Zörner ist Software-Architekt bei embarc in Hamburg. Er wirkt bei Entwurfs- und Umsetzungsfragen mit, unterstützt beim Festhalten von Architektur und beleuchtet Lösungsansätze in Bewertungen.
Falk Sippach ist bei der embarc Software Consulting GmbH als Softwarearchitekt, Berater und Trainer stets auf der Suche nach dem Funken Leidenschaft, den er bei seinen Teilnehmern, Kunden und Kollegen entfachen kann. Bereits seit über 15 Jahren unterstützt er in meist agilen Softwareentwicklungsprojekten im Java-Umfeld. Als aktiver Bestandteil der Community (Mitorganisator der JUG Darmstadt) teilt er zudem sein Wissen gern in Artikeln, Blog-Beiträgen, sowie bei Vorträgen auf Konferenzen oder User Group Treffen und unterstützt bei der Organisation diverser Fachveranstaltungen.
Stefan Zörner, Falk Sippach
Stefan Zörner, Falk Sippach
Vortrag: Mi 1.1
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:45
Mi 5.1
Software 2.0 - Building Production-Grade AI Enabled Products
Software 2.0 - Building Production-Grade AI Enabled Products

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.

Daniel Rödler is a Product Manager at understand.ai with the mission to automate annotations for autonomous vehicles and responsible for the overall product strategy. Before joining understand.ai Daniel worked for LogMeIn, a company focusing on online collaboration. There he was responsible for a part of GoToMeeting, LogMeIns biggest product with more than 2 Million users per month including an AI based voice identification mechanism to achieve much more useful meeting transcripts.
DevOps: State of the Union
DevOps: State of the Union

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

Michael Hüttermann is a freelancing DevOps consultant. Besides that, he is a researcher studying DevOps. 
Daniel Rödler
Michael Hüttermann
Daniel Rödler

Vortrag Teilen

Michael Hüttermann
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:45
Mi 6.1
Wie wir die Software-Entwicklung verändert haben
Wie wir die Software-Entwicklung verändert haben

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.

Dr. Carola Lilienthal ist Geschäftsführerin bei der WPS Workplace Solutions GmbH. Sie hat an der Universität Hamburg studiert und dort zum Thema "Komplexität von Software-Architekturen" promoviert. Seit 2003 analysiert sie im Auftrag ihrer Kunden in ganz Deutschland regelmäßig die Zukunftsfähigkeit von Software-Architekturen und spricht auf Konferenzen über dieses Thema.
Gekommen, um zu bleiben - Über Corona, Tintenfische und Resilienz von Unternehmen
Gekommen, um zu bleiben - Über Corona, Tintenfische und Resilienz von Unternehmen

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.

Jens Coldewey ist Agilist der ersten Stunde und geschäftsführender Gesellschafter der improuv GmbH. Er hat an verschiedene Agilen Transitionen mittlerer und großer Organisationen mitgearbeitet und ist u.a. Mitglied der „Supporting Agile Adoption“ Arbeitsgruppe der Agile Alliance. Jens Coldewey ist Certified Scrum Trainer und Akkreditierter Kanban Trainer.
Carola Lilienthal
Jens Coldewey
Carola Lilienthal

Vortrag Teilen

Jens Coldewey
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:45
Mi 8.1
The C4 Testpyramid - An Architecture-Driven Test Strategy
The C4 Testpyramid - An Architecture-Driven Test Strategy

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.

Christian Fischer works as a Software Engineering Coach at DB Systel and loves TDD, Extreme Programming and Craft Beer.
Testing a Data Science Model
Testing a Data Science Model

What would your first thought be when you are told there is no testing or quality structure in a team? How would you inspire a team to follow vital processes to thoroughly test a data science model?

I would like to share my knowledge about testing a model in a data science team.

Data science is a very interesting area to explore. It presents testing challenges that are quite different from “traditional” software applications. I will share my journey introducing testing activities to help build quality into a data science model.

Target Audience: Testers, QA, Developers, delivery managers, product owners, scrum masters, everyone is welcome
Prerequisites: QA, Testing
Level: Basic

Laveena Ramchandani is a vibrant, motivated and committed individual, whose main aim towards the IT industry is to apply herself and dedicate her energy to becoming the best hire as a Technical and/or Business Consultant. Establish through this experience a bridge of trust between the company and her education.

She has been awarded a Business Computing degree from Queen Mary University Of London. She thoroughly enjoyed the technical aspects of the computing side of her degree applied those skills to the business side of her degree.

She will bring an innovative and valuable contribution to any programme through her aptitude for IT, her interest in the business world and interpersonal skills. She is and will be a practical and valuable member of any team, as she is able to work effectively and efficiently with others to complete any given task.

She has excellent communication skills gained from both academic and non-academic environments.

Christian Fischer
Laveena Ramchandani
Christian Fischer
Vortrag: Mi 8.1-1

Vortrag Teilen

Laveena Ramchandani
Vortrag: Mi 8.1-2
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Mi 8.2
Test Automation in the age of digital banking Darwinism
Test Automation in the age of digital banking Darwinism

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!”.

Rudolf Grötz has been in IT for 30 years and has been a passionate software tester since 2008. He works as an agile engineering coach for the topic & test automation at Raiffeisen Bank International in Vienna and lives the motto "Test automation is not an act, test automation is a habit!". In addition to various author activities, including for IX-Magazin, he organizes the Agile (Test) Automation Meetup in Vienna and the TestBustersNight Vienna 6 times a year. ------------------ Rudolf Grötz ist seit 30 Jahren in der IT unterwegs und seit 2008 passionierter Softwaretester. Er ist als Agile Engineering Coach für das Thema & Test Automation bei der Raiffeisen Bank International in Wien tätig und lebt den Leitspruch „Testautomation is not an act, Testautomation is a habit!“. Neben diverser Autorentätigkeiten, u.a. für das IX-Magazin, organisiert er in Wien das Agile (Test) Automation Meetup und 6x pro Jahr die TestBustersNight Vienna.
Matthias Zax works as an agile engineering coach at Raiffeisen Bank International AG (RBI). Actually a trained software developer, he has been testing software with a focus on test automation in the DevOps environment since 2018 and organizes the RBI Test Automation Community of Practice. ------------------ Matthias Zax arbeitet als Agile Engineering Coach bei Raiffeisen Bank International AG (RBI). Eigentlich gelernter Software Developer, beschäftigt er sich seit 2018 mit dem Testen von Software mit Schwerpunkt Testautomation im DevOps-Umfeld und organisiert die RBI Testautomation Community of Practice.
Rudolf Grötz, Matthias Zax
Rudolf Grötz, Matthias Zax
Vortrag: Mi 8.2
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Mi 4.3
Structure and Interpretation of Test Cases in C++
Structure and Interpretation of Test Cases in C++

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

Kevlin Henney is an independent consultant, speaker, writer and trainer. His development interests are in patterns, programming, practice and process. He is co-author of “A Pattern Language for Distributed Computing” and “On Patterns and Pattern Languages”, two volumes in the Pattern-Oriented Software Architecture series, and editor of “97 Things Every Programmer Should Know” and “97 Things Every Java Programmer Should Know”.
Kevlin Henney
Kevlin Henney
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Mi 8.3
Validation of Autonomous Systems
Validation of Autonomous Systems

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.

Christof Ebert is managing director at Vector Consulting Services. He supports clients around the world in product development. Before he had been working for twelve years in global senior management positions. A trusted advisor for companies around the world and a member of several of industry boards, he is a professor at the University of Stuttgart and at Sorbonne in Paris. He authored several books including the most recent “Global Software and IT” published by Wiley and "Requirements Engineering" published by dPunkt and in China by Motor Press. Since many years he is serving on the editorial Board of the prestigious "IEEE Software" journal.
Michael Weyrich is the director of the University of Stuttgart’s Institute for Automation and Software Systems. Before he spent many years at Daimler and Siemens where he had senior management positions in engineering. Ever since he engages in technology transfer and is heading numerous industry projects on automation and validation. He authored several books including the leading reference book on "Industrial Automation" published by Springer. Since many years he serves on VDI in various leadership positions. He is leading the VDI/VDE committee on testing of connected systems and industry 4.0.
University of Stuttgart - Institute of Industrial Automation and Software Engineering
Academic staff

Christof Ebert, Michael Weyrich, Benjamin Lindemann
Christof Ebert, Michael Weyrich, Benjamin Lindemann
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Mi 7.4
Testen Sie Ihre Software-Architektur – Lebe lang und sei erfolgreich!
Testen Sie Ihre Software-Architektur – Lebe lang und sei erfolgreich!

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

Matthias Herbort arbeitet als Principal Key Expert für Software-Architektur bei der Siemens AG. Er hat mehr als 15 Jahre Erfahrung in der Modernisierung und Sanierung von mittleren und großen unternehmenskritischen Software-Systemen. Dabei arbeitet er oft an der Schnittstelle zwischen Architektur und Business.
Matthias Herbort
Matthias Herbort
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Mi 8.4
Architecture Fitness Functions demystified! Unser Weg zur praktischen Anwendung
Architecture Fitness Functions demystified! Unser Weg zur praktischen Anwendung

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.

Andreas Hinkelmann ist ein Lead Architekt bei der DATEV eG. Dabei berät er andere Architekten, zudem schult und übt er mit diesen den systematischen Architekturentwurf und das Domain-driven Design.
Matthias Kindermann ist seit 2017 für die DATEV eg in Nürnberg tätig und agiert in der Rolle als zentraler Systemarchitekt. Sein Schwerpunkt liegt auf Cloud-native Architekturen und Web-Technologien.
Andreas Hinkelmann, Matthias Kindermann
Andreas Hinkelmann, Matthias Kindermann
Vortrag: Mi 8.4
flag VORTRAG MERKEN

Vortrag Teilen

, (Donnerstag, 11.Februar 2021)
09:00 - 10:45
Do 3.1
Exploratives Testen im regulierten Umfeld ist nicht möglich! ... oder doch?
Exploratives Testen im regulierten Umfeld ist nicht möglich! ... oder doch?

<provokative Statements> Im regulierten Umfeld sind die Anforderungen an Test- und Qualitätssicherung so hoch, dass man dies nicht mit explorativen Testmethoden lösen kann.</provokative Statements>

<Lösungsansatz>Unser Ansatz: Sessionbasiertes Testmanagement. Anhand unserer bisherigen Erfahrungen zeigen wir auf, wie man explorative Testmethoden auch im regulierten Umfeld einsetzen kann. Gemeinsam tauchen wir in unser Projektvorgehen ab und zeigen klassische Stolpersteine auf.</Lösungsansatz>

Zielpublikum: Testende, Testmanager:innen, Product Owner, Scrum Master, Stakeholder, Fachbereich
Voraussetzungen: Grundlegende Kenntnisse im Testing, Einordnung explorativer Testmethoden
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Maria und ich beschäftigen uns schon seit langer Zeit mit kollaborativen und explorativen Testmethoden. Da wir nun beide für die ZEISS DIgital Innovation tätig sind, kamen wir natürlich auch direkt im regulierten Umfeld (Medizintechnik) an.

Da wir auch hier gerne unsere positiven Erfahrungen mit explorativem Testen einbringen wollten, war der kundenseitige Widerstand sehr groß. Exploratives Testen ist im regulierten Umfeld nicht möglich, zu hoch sind die Anforderungen an Test- und Qualitätssicherung. Dieser Widerstand war unsere Motivation, uns genauer mit dem Thema auseinander zu setzen und einen Lösungsansatz zu erarbeiten, wie man auch im regulierten Umfeld explorativ testen kann.

Gerne möchten wir unsere Erfahrungen auch an andere Leidensgenossen weitergeben und vielleicht können wir auch den ein oder anderen Weg etwas ebnen.

Benedikt Wörner arbeitet als agiler Testexperte. Seine Leidenschaft ist es, Kunden bei der agilen Transformation zu helfen. Er eröffnet den Kunden neue Wege und Perspektiven, z.B. bei der Einführung kollaborative Testmethoden.
Maria Petzold - ihr Fokus liegt als Testmanagerin auf der Qualitätssicherung von Software. Während ihrer Arbeit hat sie die agilen und kollaborativen Testmethoden kennen und lieben gelernt, sodass sie diese Erfahrungen gern an andere weitergibt.
Testmanagement in SAP-Projekten – Erfahrungsbericht aus einem Biotechnologie-Unternehmen
Testmanagement in SAP-Projekten – Erfahrungsbericht aus einem Biotechnologie-Unternehmen

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.

Josephine Müller-Gorski ist als IT-Testmanager bei Miltenyi Biotec tätig. Hier betreute sie unter anderem die Standardisierung des Testmanagement-Prozesses sowie die Implementierung eines Testmanagement-Tools im Rahmen eines SAP-Upgrade-Projekts. Seitdem ist sie in weiteren SAP-Projekten als Testmanager tätig gewesen. Als Quereinsteiger wechselte sie 2013 in den Bereich Software-Testmanagement. Sie testete bereits unzählige Mobile Apps, Webseiten und Content-Management-Systeme und leitete mehrfach Test-Teams.
Benedikt Wörner, Maria Petzold
Josephine Müller-Gorski
Benedikt Wörner, Maria Petzold
Vortrag: Do 3.1-1

Vortrag Teilen

Josephine Müller-Gorski
Vortrag: Do 3.1-2
flag VORTRAG MERKEN

Vortrag Teilen

, (Freitag, 12.Februar 2021)
09:00 - 16:00
Fr 6
(AUSGEBUCHT) Enabling Whole Team Quality as a Tester in an Agile Team
(AUSGEBUCHT) Enabling Whole Team Quality as a Tester in an Agile Team

Agile testers need to lead the team, other testers, product owners and customers towards better quality. Yet agile teams don’t generally bestow formal authority. And, as testers, we’re often trying to lead from a position that is still not always appreciated.

The workshop will focus on hands-on exercises and activities for achieving enablement for whole team quality. No programming skills are necessary, but we will be doing some work involving code in groups and in a safe learning environment.

Maximum Number of participants: 12

Target Audience: Testers, developers
Prerequisites: None
Level: Basic

Extended Abstract:
The role of a tester on an agile team is so much more than “hey can you test this with your super testing skills”. Testers are, on the one hand, chameleons who need to adapt their skills to new situations within the team. On the other hand, we can’t just react to situations – we need to lead the team, other testers, product owners and customers towards better quality. Yet agile teams don’t generally bestow formal authority. And, as testers, we’re often trying to lead from a position that is still not always appreciated (“agile teams don’t need testers”, “testers are just bad developers”, “you’re just a tester”…).

In complex situations where we’re dealing with unknown unknowns plus sticky, messy humans, communication is key. A degree in psychology would sometimes be helpful. Multiple years of cat-herding too. In this workshop, Alex will focus on communication.

The workshop will consist of the following topics:

- Communicating the value and role of testing

- Testers as the communication glue for various stakeholders and within the team: talking about  testing, risk and quality at the right level for the right audience

- Enablement: Teaching, coaching, coercing and encouraging others within the team to take on quality- related tasks and to support the value of the product through testing

- What testers and other team members can do together, resulting in better and more efficient results

The workshop will focus on hands-on exercises and activities. No programming skills are necessary, but we will be doing some work involving code in groups and in a safe learning environment.

Alex Schladebeck ist eine Testerin aus Leidenschaft. Ihr Herz schlägt für Qualität, Agilität und ihre Mitmenschen. Sie ist Geschäftsführerin und Leiterin der Qualitätssicherung bei der Bredex GmbH.

In diesen Rollen unterstützt sie Kollegen, Kunden und Teams auf ihrer Reise, bessere Qualität zu liefern: in Produkten, in Prozessen und in der Kommunikation.

In früheren Rollen war sie für die Befähigung von Teams und qualitativ hochwertige Systeme verantwortlich. Nun befähigt sie andere, genau das zu machen, und sorgt für eine Umgebung in der Firma, wo jede(r) aufblühen kann.

Alex schaut mit neugierigen Tester-Augen auf die Welt und möchte immer dazu lernen. Sie teilt ihr Wissen und ihre Erfahrungen in Workshops, Coachings und als Sprecherin oder Keynote-Sprecherin auf Konferenzen.
Alex Schladebeck
Alex Schladebeck
flag VORTRAG MERKEN

Vortrag Teilen

Zurück