Konferenzprogramm

Konferenzprogramm 2020

Track: German Testing Night

Nach Tracks filtern
  • Dienstag
    01.09.
  • Mittwoch
    02.09.
09:00 - 10:05
Eröffnung + Keynote: Delivery is still all about people
Eröffnung + Keynote: Delivery is still all about people

Have you ever wondered why the same problems seem to keep trickling down to the testing phase?  The specification was misinterpreted, the test case wasn’t right, the software didn’t meet requirements...

Lindsay’s work on organizational alignment puts this down to ‘The Fog’: a confusion caused by misunderstandings, biases, assumptions, different interpretations, behaviours, and information gaps, among other things.  While a certain amount of Fog is inevitable, it can build up between people to cause serious misalignment, leading to cost and frustration. But it doesn’t have to be this way.

Lindsay’s conference opener takes us through a story of how she began to recognize The Fog, understand what’s behind it, and see what can be done to clear it. This is a keynote about complexity, empowerment, learning and organizational maturity for today’s dynamic workplaces.
Lindsay Uittenbogaard (ABC) is Founder and Principal Consultant of the Mirror Mirror team alignment process. She started her career managing small businesses before spending 15 years in employee communication roles with multinational organisations in the energy, IT, and telecommunications industries. It was the difference between micro and macro working environments that sparked an insatiable curiosity in how people perceive things differently and the profound implication of that on business performance.

An IABC Accredited Business Communicator, Lindsay is also a certified member of the Reputation Institute and a published author in the Gower Handbook on Internal Communication 2008. She holds a Creative Arts degree with honours, post-graduate diplomas in International Business Communication Management, and Broadcast Journalism, and is certified by the CIPD.
Lindsay Uittenbogaard
Lindsay Uittenbogaard
Track: Keynote
Vortrag: KeyDi
Themen:
10:05 - 10:35
Pause
Pause

10:35 - 11:10
Ein paar Millionen Worte später - Text Analytics für die Qualitätssicherung von Tests in der Praxis
Ein paar Millionen Worte später - Text Analytics für die Qualitätssicherung von Tests in der Praxis

In Wissenschaft und Praxis herrscht mit Sprachassistenten und automatischen Übersetzern die Stimmung einer Zeitenwende - alles ist möglich, oder? Wir setzen Natural Language Processing (NLP) Techniken seit vielen Jahren bei mittlerweile über 60 Projekten in Automotive und Versicherungsbereich täglich zur Qualitätssicherung ein. Beispiele sind die automatische Prüfung von Anforderungen und Tests, Testgenerierung aus User Stories oder Traceability Analysen. Dabei ergibt sich ein etwas differenzierteres Bild.

In diesem Vortrag zeigen wir auf, was der Stand der Technik ist, was praktisch noch nicht geht und was niemals gehen wird.

Zielpublikum: Tester, Entwickler, Testmanager
Vorraussetzungen: Grundkenntnisse Test Management sind von Vorteil
Schwierigkeitsgrad: Basic

Extended Abstract:
In Wissenschaft und Praxis herrscht Revolutionsstimmung. Sprachassistenten simulieren natürliche Gespräche, automatische Übersetzer gibt es mittlerweile in Googles Excel oder man schiebt gleich das ganze Word-Dokument in einen automatischen Übersetzer und bekommt den Text zurück als ob ein Dolmetscher involviert wäre. Dieser Eindruck drängt sich auf, aber vielleicht ist die Revolutionsstimmung auch nur eine Goldgräberstimmung.

In unserer täglichen Arbeit versuchen wir u.a. automatisch potentielle Sprachprobleme in Test aufzudecken - wie eine schlauere Rechtschreibprüfung. Wir arbeiten dabei bereits seit sechs Jahren mit Natural Language Processing (NLP) Techniken, insb. Lemmatization, Part-of-Speech Tagging, Syntax Parsing und Co-Reference-Resolution, und zuletzt stärker Topic Modelling. Weiterhin führen wir immer wieder Studien mit unterschiedlichen Machine-Learning-Ansätzen durch. Das Herausfordernde in unserem Kontext: Mit den Ergebnissen unserer Analysen werden Menschen zum Teil auch kritisiert und gemessen und Sprache wird allgemein als etwas sehr persönliches wahrgenommen. Dadurch kommen zwei Faktoren ins Zentrum der Bewertung: Hohe Präzision und Erklärbarkeit.

In diesem Vortrag möchte ich diese modernen Ansätze in der konkreten Anwendung aufzeigen und sowohl Chancen als auch die Probleme aus der Anwendung heraus diskutieren und reflektieren. Dabei wird auf Buzzwords garantiert verzichtet, stattdessen wollen wir uns anschauen, was die End-Nutzer dazu sagen. Wir schließen mit einer versöhnlichen Analyse wo und unter welchen Umstände aus unserer Erfahrung heraus, NLP und Machine Learning für Systemtests sinnvoll anwendbar ist und wo nicht.
Benedikt Hauptmann hat Software Engineering und Informatik studiert und an der TU München über Qualität von Software Tests promoviert.
Er ist Mitgründer und Geschäftsführer von Qualicen. Seine Ambition ist es, Tests zu erstellen, die einfach zu verstehen, auszuführen und zu warten sind. Zu diesen Themen hält er regelmäßig Vorträge für Forschung und Industrie.
Benedikt Hauptmann
Benedikt Hauptmann
Vortrag: Di 1.1
Themen:
10:35 - 11:10
Continuous Integration? I Don't Think That Word Means What You Think It Means
Continuous Integration? I Don't Think That Word Means What You Think It Means

Continuous Integration has become synonymous with CI-Servers and the concept of CI/CD-Pipelines. Unfortunately, you can have continuous delivery without continuous integration. Just as you can check in directly to 'production' without having trunk-based development. (And shouldn't trunk-based development should be called master based development nowadays?).

This session aims to debunk several misconceptions about good engineering practices and proposes some ways to get from cargo-cult agile (aka in-name-only-agile) to tangible results today.

Michael Mahlberg gehört zu den Menschen die die Praktiken hinter Agilität seit vor (sic!) 2001 verbreiten, und seit 2008 aktiv Kanban für Wissensarbeiter vorantreiben. Neben der Arbeit in der Community verbringt er den Großteil seiner Zeit damit, Kunden auf dem Weg zu mehr Effektivität und besserer Zusammenarbeit zu unterstützen - meisten mit Dingen aus den Bereichen Lean, Kanban und Agile.
Michael Mahlberg
Michael Mahlberg
Vortrag: Di 2.1
Themen:
10:35 - 11:10
Vortrag Browser Stack
Vortrag Browser Stack

[weitere Informationen folgen in kürze]
Track: Track+
Vortrag: Di 3.1
Themen:
10:35 - 12:40
Unit Testing und TDD für Tester
Unit Testing und TDD für Tester

Als traditioneller Arbeitsauftrag für Entwickler sind Unit Tests für viele Tester recht unbekannt. Trotzdem sind sie interessant für Tester: um mit daran zu arbeiten, um Entwickler beim Test-Design zu unterstützen, zum Vertiefen unseres Wissens, oder auch zu mehr/besseren Unit-Tests zu motivieren.

In diesem Workshop erarbeitet ihr mit Zeb (Unit-Testing-Begeistertem-Entwickler) und Alex (Unit-Testing-begeisterter-Testerin) Unit Tests und Code (mit TDD) für ein nicht triviales Programm.

Gemeinsam arbeiten wir an Code und Tests gleichzeitig. Als Zusammenfassung schauen wir, wie dieses Format für eure Zwecke anwendbar ist.

Maximale Teilnehmerzahl: 20

Z
ielpublikum: Tester (auch ohne Programmierkenntnisse)
Vorraussetzungen: Keine
Schwierigkeitsgrad: Basic

Extended Abstract:
Als traditioneller Arbeitsauftrag für Entwickler sind Unit Tests für viele Tester recht unbekannt. Gleichzeitig kann es zu unseren Aufgaben gehören, 'die richtige Ebene' mit zu identifizieren oder mit Entwicklern in Pairing an Tests zu arbeiten. Vielleicht interessieren wir uns einfach dafür, wie Qualität auf dieser Ebene aussieht. Oder vielleicht wollen wir Entwickler motivieren, mehr/bessere Unit Tests zu schreiben. 
Was auch immer die Gründe sind: einfache Beispiele sind im Netz überall auffindbar. Aber wie sehen Unit Tests aus, wenn es über den normalen Taschenrechner hinausgeht? Wie schreibt man sie? Wie werden sie verwendet, um Test-Driven-Development zu ermöglichen?

In diesem Workshop erarbeitet ihr mit Zeb (Unit-Testing-Begeistertem-Entwickler) und Alex (Unit-Testing-begeisterter-Testerin) Unit Tests und Code (mit TDD) für ein einfaches, doch nicht triviales, Programm. Die Ziele des Workshops sind zweierlei:
  1.  Echte Erfahrungen in Unit Testing und TDD bekommen oder verstärken
  2. Methoden ausarbeiten, um dieses Format in euren Firmen einzuführen
Gemeinsam als Gruppe wird an den Code und den Tests gleichzeitig gearbeitet. Als Zusammenfassung schauen wir, wie dieses Format für eure Zwecke anwendbar ist.

Programmierkenntnisse sind begrüßenswert, aber keine Voraussetzung. Logisches Denken und Freude am Lernen sind wichtiger!
Alex Schladebeck ist eine Testerin aus Leidenschaft und eine Beraterin für Qualität und Agilität. Sie arbeitet für BREDEX GmbH und leitet dort den Bereich Software Qualität und Test Consulting.
Sie verbringt ihre Zeit in Kommunikation mit verschiedenen Menschen aus der IT. Sie Ob es Trainings und Coachings sind, Pairing-Sessions mit Entwicklern und Testern, oder Kundenberatung
Alex liebt es, in agilen Prozessen zu arbeiten und immer mehr über Qualitätstechniken und Methoden zu lernen.
Alex spricht häufig auf Konferenzen als Speaker oder Keynote-Speaker über Agilität und Qualitätssicherung aus Sicht ihrer Projekterfahrung.


Zeb is a software developer and technical lead at BREDEX GmbH in Germany. He is a huge fan of open source, and was an active Eclipse committer for many years. He works closely with testers in his teams to share understanding about quality and risk. He has a knack for effective code documentation and is not fond of acronyms.
Alexandra Schladebeck, Zeb Ford-Reitz
Alexandra Schladebeck, Zeb Ford-Reitz
Track: Workshop
Vortrag: Di 4
Themen:
11:20 - 11:55
Qualitätssicherung von Künstlicher Intelligenz - Testen eines neuronalen Netzes
Qualitätssicherung von Künstlicher Intelligenz - Testen eines neuronalen Netzes

Es stellen sich grundlegende Fragen zum Testvorgehen von neuronalen Netzen. Gängige Testmethoden mit Ausrichtung auf Blackbox oder Whitebox stoßen bei komplexen neuronalen Netzen auf Komplikationen, da sie ein festes quantifizierbares Ergebnis voraussetzen.

Whitebox-Tests gestalten sich herausfordernd, da die Komplexität der Vorgänge innerhalb der Netze in einer Vielzahl von komplexen Anwendungsfällen  schwer nachvollzogen werden kann. Die Kategorie der Blackbox-Tests scheitert bei bestimmten Ausprägungen von komplexen neuronalen Netzen, da das zu erwartende Ergebnis im Vorfeld nicht in jedem Fall eindeutig quantifiziert werden kann.

Zielpublikum:
Tester, Entwickler, Testmanager
Vorraussetzungen: Grundlegende Testerfahrungen, Whitebox-Test, Blackbox-Test, Neuronale Netze,
Schwierigkeitsgrad: Advanced

Extended Abstract:
Im Zuge der voranschreitenden Digitalisierung der Unternehmen werden verstärkt  neuronale Netze als künstliche Intelligenz (KI) für unterschiedlichste Problemstellungen eingesetzt. Diese Netze ermöglichen es, durch ihre Vorgehensweise bei komplexen Problemen und großen Datenmengen, neue Blickwinkel zu ergründen und schneller auf Veränderungen zu reagieren . Zeitgleich stehen Unternehmen und Mitarbeiter vor neuen Herausforderungen.

Den Anforderungen an die Qualität und der Dokumentation für neuronale Netze ist teilweise nur bedingt nachzukommen. In den neuronalen Netzen lässt sich schwer nachvollziehen, warum eine Entscheidung getroffen wurde, um zum erreichten Ergebnis zu kommen. Durch diese Hürden fehlt es an Transparenz für eine angemessene Qualitätssicherung.  Bestimmte Implementierungsarten von neuronalen Netzen sind nicht-deterministisch, was den Sachverhalt der Nachvollziehbarkeit zusätzlich verschärft.   In der Entwicklung wird die Fehlersuche erschwert, da die Wiederholung eines Vorgangs mit gleichen Eingabebedingungen zu unterschiedlichen Ergebnissen führen kann. Die Fehlererkennung und Behebung stellen daher eine Herausforderung dar.

Neuronale Netze gibt es in verschiedensten Ausprägungen. Die Struktur/Topologien unterscheiden sich grob in sequenziell und rekurrente Netze mit unterschiedlicher Tiefe. Die Art des Lernens ist untergliedert in überwachtes, unüberwachtes und bestärktes Lernen. Jede Kombination von Struktur und Lernart bringt eigene technische und organisatorische Herausforderungen mit sich.

Es stellen sich grundlegende Fragen zum Testvorgehen von neuronalen Netzen. Gängige Testmethoden mit Ausrichtung auf Blackbox oder Whitebox stoßen bei komplexen neuronalen Netzen auf Komplikationen, da sie ein festes quantifizierbares Ergebnis voraussetzen.  Whitebox-Tests gestalten sich herausfordernd, da die Komplexität der Vorgänge innerhalb der Netze in einer Vielzahl von komplexen Anwendungsfällen  schwer nachvollzogen werden kann. Die Kategorie der Blackbox-Tests scheitert bei bestimmten Ausprägungen von komplexen neuronalen Netzen, da das zu erwartende Ergebnis im Vorfeld nicht in jedem Fall eindeutig quantifiziert werden kann. In klassischen Anwendungen von neuronalen Netzen lassen sich die Ergebnisse quantifizieren. Es entstehen zunehmend Anwendungen, bei denen dies nicht mehr der Fall ist, wie der 'Neural Style Transfer'.

In dem Vortrag 'Qualitätssicherung von Künstlicher Intelligenz - Testen in neuronalen Netzen' werden die Handlungsfelder und Herausforderungen benannt sowie analysiert. Nach einer Einführung in die Thematik der neuronalen Netze und des Anwendungsfalls 'Neural Style Transfer', werden die verschiedenen technischen Rahmenbedingungen an die Qualitätssicherung vorgestellt. Bestehende Lösungsansätze werden skizziert und erläutert. Der Vortag endet mit einem Fazit der bisher verfolgten Lösungsmethoden und gibt einen Ausblick auf mögliche zukünftige Entwicklungen.
Christopher Koch ist IT-Berater bei der ITGAIN Consulting Gesellschaft für IT-Beratung mbH.

Er hat ein abgeschlossenes Masterstudium im Bereich der Wirtschaftsinformatik. Christopher Koch verfügt über 6 Jahre Berufserfahrung in den Bereichen Test- und Qualitätsmanagement im Schwerpunkt Banken und Versicherungen.

Seine besondere Expertise liegt in Testmethoden und -automatisierung.
Fachvorträge auf der ITGAIN Akademie, den Software-QS-Tagen, sowie die Teilnahme an dem Global PyTorch Summer Hackathon runden sein Portfolio ab.
Christopher Koch
Christopher Koch
Vortrag: Di 1.2
Themen:
11:20 - 11:55
Vom agilen Testen zur DevOps Test Pipeline - vom klassischen Planungsansatz zur hochautomatisierten Testlinie
Vom agilen Testen zur DevOps Test Pipeline - vom klassischen Planungsansatz zur hochautomatisierten Testlinie

In diesem Vortrag wird ein praxiserprobtes Testarchitekturmodell vorgestellt, das ein normatives Referenzmodell (z. B. ISO29119, ISO25010, IEEE 829) in einem agilen resultatsgetriebenen Entwicklungsvorgehen in eine effiziente Testautomatisierunglinie umsetzt.

Dabei spielt ein aus dem Architekturwürfel abgeleitetes Testebenenkonzept die methodische Brücke zur Absicherung der Softwarebausteine entlang der Testpipeline. Probleme und Lösungen bei der Gewährleistung von Test KPI's und DevOps-Zielen werden herausgearbeitet.

Zielpublikum: Entwicklungs-, Projekt- und Testingenieure
Vorraussetzungen: Kenntnisse in Testautomatisierung, Vorgehensmodelle insbesondere agile Entwicklungsstrategien (z.B. Scrum), lean Manufacturing Methoden, DevOps Paradigmen, Modularisierungskonzepte in der Softwareentwicklung ,KPV, Kaizen.
Schwierigkeitsgrad: Advanced

Extended Abstract:
- klassische Testaspekte (Grundgerüst)
- Voraussetzungen für ein DevOps Vorgehen
- Aufbau einer IT-Fertigungslinie
- IDE,SCM, SVN,CI-Server,DOCKER, ...
- Testobjekte und Testebenenmodell
- Tooling Park für Test Pipeline
- Continuous Test Pipeline
- Testinformationsstrom im SW-Entwicklungs- und Deploymentprozess
- Testen nicht funktionaler Anforderungen in der Pipeline. 
S. Schramm unterstützt bei Sogeti Unternehmen der Automobilbranche bei der Entwicklung sowie der Praxisumsetzung von Methoden der Qualitätssicherung von SW-Produkten und die Einführung agiler Vorgehensmodelle mit DevOps als finales Zielbild.    
Stephan Schramm
Stephan Schramm
Vortrag: Di 2.2
Themen:
11:20 - 11:55
Wie fühlen wir uns heute? Einfache Anamnese der QA-Strategie für agile Teams
Wie fühlen wir uns heute? Einfache Anamnese der QA-Strategie für agile Teams

Vergleichbar mit einem falschen Architekturansatz oder der Verwendung der falschen Programmiersprache kann eine falsche Test- und Qualitätssicherungsstrategie zu Problemen führen. Die agilen Entwicklungsteams bemerken in der Retrospektive, dass etwas nicht stimmt, können aber wegen fehlender QA-Expertise nicht die Ursache erkennen.

Mit Hilfe unseres agilen Visualisierungswerkzeugs, dem sogenannte QA-Schlachtplan, möchte ich eine Methode vorstellen mit der agile Entwicklungsteams eigenständig oder durch einen agilen QA Coach die Möglichkeit bekommen typische QA-Problemfälle und deren Auswirkungen zu erkennen und diese zu beseitigen.

Zielpublikum: Agile Entwicklungsteams, Agile Tester, Scrum Master
Vorraussetzungen: Erfahrungen im Agilen Methoden wie Scrum
Schwierigkeitsgrad: Advanced

Extended Abstract:
Vergleichbar mit einem falschen Architekturansatz oder der Verwendung der falschen Programmiersprache kann eine falsche Test- und Qualitätssicherungsstrategie zu Problemen führen. Die agilen Entwicklungsteams bemerken in der Retrospektive, dass etwas nicht stimmt, können aber wegen fehlender QA-Expertise nicht die Ursache erkennen.

Mit Hilfe unseres agilen Visualisierungswerkzeugs, dem sogenannte QA-Schlachtplan, möchte ich eine Methode vorstellen mit der agile Entwicklungsteams eigenständig oder durch einen agilen QA Coach die Möglichkeit bekommen typische QA-Problemfälle und deren Auswirkungen zu erkennen und diese zu beseitigen. Dies wird durch die Identifizierung von Artefakten wie Testarten, Testwerkzeugen und Ressourcen und deren anschließende Überführung und Darstellung im Entwicklungsprozess. Das so entstandene Bild kann durch einen QA-Experten zur Anamnese der QA-Strategie des Projektes genutzt werden.

Im Vortrag werden verschiedene Konstellationen als negative Beispiele vorgestellt, deren Auswirkung besprochen und Lösungen aufgezeigt. Mit dem QA-Schlachtplan haben die Entwicklungsteams ein visuelles Hilfsmittel, mit dem sie frühzeitig die planerischen Aspekte der Qualitätssicherung beurteilen können. Dabei kann der QA-Schlachtplan innerhalb der Projektlaufzeit auch als Referenz des aktuellen Vorgehens und als Ansatz für potentielle Verbesserung genutzt werden.

Kay Grebenstein arbeitet als Testmanager und agiler QA-Coach für die Carl Zeiss Digital Innovation. Er hat in den letzten Jahren in Projekten unterschiedlicher fachlicher Domänen (Telekommunikation, Industrie, Versandhandel, Energie, ...) Qualität gesichert und Software getestet.
Kay Grebenstein
Kay Grebenstein
Track: Track+
Vortrag: Di 3.2
Themen:
12:05 - 12:40
Programmieren Sie noch Unit-Tests oder generieren Sie schon?
Programmieren Sie noch Unit-Tests oder generieren Sie schon?

Steigende Komplexität von Systemen bedingt, dass immer mehr Tests notwendig sind. Entwickler erstellen meist zu wenige Tests. In guten Fällen werden ca. 30% der Entwicklerzeit für die Unittesterstellung verwendet.

Wir entwickeln im Rahmen eines Forschungsprojekts eine KI-gestützte Lösung zur Testautomatisierung unter dem Motto 'Wir automatisieren die Testautomatisierer!'

Durch diesen Testcode Generator werden ca. 75% der in der Softwareentwicklung notwendigen Testprogrammierarbeiten automatisch mit Hilfe von Artificial Intelligence durchgeführt.

Zielpublikum: Entwickler, Architekten, Testautomatisierer, Entwicklungsleiter, Testverantwortliche
Vorraussetzungen: Gute Kenntnisse in Testen und Unit-Tests
Schwierigkeitsgrad: Expert

Extended Abstract:
Die Verantwortung für Unternehmen, höhere Qualitätsstandards in Softwareentwicklungen zu bringen, wächst ständig und die zunehmende Komplexität von Systemen führt dazu, dass immer mehr Tests notwendig sind. Systeme nach dem Stand der Technik abzusichern und Haftung gegenüber Auftraggebern im Falle von Fehlern zu reduzieren, erweitert die Problemstellung.

Deswegen wächst weltweit die Nachfrage nach der Entwicklung von Technologien und Lösungen zur Verbesserung von Software-Tests.

Entwickler sind 'Mangelware' und werden von Unternehmen händeringend gesucht. Naturgemäß sinkt die Produktivität - und die Motivation- dieser teuren Ressourcen durch zeitraubende Testaufgaben. Entwickler erstellen jedoch fast immer zu wenige Tests. In guten Fällen werden ca. 30% der Entwicklerzeit für die Testerstellung aufgewendet.

Es gibt viele Test-Tools am Markt aber praktisch keine Lösungen, welche basierend auf künstlicher Intelligenz die Entwickler dabei unterstützen, schnell und sinnvoll Software zu testen.

Auf Basis eines Vorprojekts wurde gemeinsam mit der technischen Universität Wien ein Konzept erstellt und prototypisch umgesetzt. Zur weiteren Umsetzung und Fokussierung auf dieses Thema wurde 2019 eine eigene Firma Automated Software Testing GmbH als Startup gegründet. Nun fokussiert sich die Firma in einem Forschungsprojekt ganz auf das Thema Artificial Intelligence in der Testautomatisierung.

Im Vortrag werden die Ideen und Konzepte zur Entwicklung einer KI-gestützten Lösung zur Testautomatisierung dargestellt. Durch diesen Testcode Generator sollen ca. 75% der bei der Unittest Erstellung für den Entwickler notwendigen Testerstellungs- und Programmierarbeiten automatisch mit Unterstützung von Artificial Intelligence bzw. Machine Learning durchgeführt werden.

Zentrale Entwicklungsinhalte sind:
- Automatisiert Testmodelle aus Software-Code generieren
- Testbarkeit feststellen und optimieren
- Automatische Absicherung des Codes
- Wartbarkeit des Codes optimieren
- Lesbarkeit des Codes optimieren
- Automatische Testdatenermittlung
- Effizientes Testdatenset automatisch finden
- Automatisiertes Kapseln von Codeteilen
Ca. 30 Jahre Erfahrung in der SW-Entwicklung in verschiedenen Rollen (Entwickler, Architekt, Projektleiter, Tester, Entwicklungsleiter, Produktmanager, Productowner, Geschäftsführer)
Gründer und Geschäftsführer von Automated Software Testing GmbH
Johannes Bergsmann
Johannes Bergsmann
Vortrag: Di 1.3
Themen:
12:05 - 12:40
Competitive Pair Programming - vier Entwickler für ein Halleluja!
Competitive Pair Programming - vier Entwickler für ein Halleluja!

Anfang der 70er Jahre: Bud Spencer und Terence Hill lassen ihre Fäuste sprechen, während David Parnas seine ersten Arbeiten zu Softwaremodulen vorstellt. Natürlich Zufall. Doch wir wollen in diesem Talk zeigen, wie Wettstreit in einem agilen Team, im Einklang mit Modularisierung und Tests, die Softwarequalität verbessern kann.

Modulkontrakte werden gemeinsam im Team definiert, bevor wettstreitende Entwicklerpaare die Module implementieren. Der Austausch der Modultests vertieft das gemeinsame Verständnis der Aufgaben. Die Entwicklerpaare messen ihre Module gegen die Tests und im System - ganz ohne Fäuste. Halleluja!

Zielpublikum: Entwickler, Tester, Architekten, Projektmanager
Vorraussetzungen: Grundlagenwissen zu agilen Vorgehensmodellen, Interesse an Software-Architekturen, Modularisierung und Software-Qualität.
Level: Basic

Extended Abstract:

Softwareentwickler verstehen die Absichten von gut formulierten User Stories, Use Cases oder Systemanforderungen. Umsetzungen in Systemfunktionen liegen jedoch nicht immer schnell auf der Hand, oder die Konsequenzen von unterschiedlichen Umsetzungen mit mächtigen oft aber schwer zu handhabenden Technologien sind nicht offensichtlich. Wenige Fakten und lückenhafte Argumentation führen zu unsicheren Entscheidungen. Dem wirkt Competitive Pair Programming (CPP) entgegen.
CPP besetzt schnell und flexibel Lücken, die die Variabilität in unklaren Problembereichen schafft. Gruppen von Entwicklern eines Teams erarbeiten unterschiedliche Lösungen. Kontinuierlich bespricht das Team vorliegende Ergebnisse und die gesammelten Erfahrungen. Das Ende ist erreicht - nach einem oder mehreren Entwicklungsabschnitten - wenn die Aufgabe hinreichend einfach und überzeugend umgesetzt ist oder wenn die notwendige und nützliche Information für die eine Produktivimplementierung vorliegt. Damit ist CPP eine agile Entwicklungsmethode mit starkem Fokus auf Qualität und Nachhaltigkeit. CPP verspricht einige Vorteile für die agile und für schlanke (lean) Softwareentwicklung, zum Beispiel:

Motivierender Wettstreit im Team um die am besten zur Aufgabe passende Lösung.

Förderung der Kommunikation durch unterschiedliche Sichten, Ansätze und Lösungen.

Erkenntnisgewinn in kürzerer Zeit durch parallele Implementierungen von alternativen Systemarchitekturen.

Nutzung der gewonnenen Erkenntnisse, um anstehende, weitreichende Entscheidungen fundiert treffen zu können.

Validierung einer Systemfunktion durch Vergleich unterschiedlicher Implementierungen.

Diversifizierte Implementierungen von im Ergebnis hochwertigen Systemfunktionen.

Fokussierung an Entscheidungspunkten, die kritisch sind für die Systemarchitektur und weitere Entwicklung.

Demgegenüber steht der Mehraufwand, den die Funktionenvielfalt naturgemäß mit sich bringt. CPP bietet sich an für die Implementierung und Erprobung von kritischen Systemfunktionen in dynamischen Einsatz- und Entwicklungsumgebungen. CPP fördert und profitiert von modularer Programmierung und Softwaremodulen. Der Vortrag stellt zunächst die Grundzüge von CPP vor. Danach wird CPP agilen Prozessmodellen zugeordnet und Einsatzbedingungen besprochen. Erfahrungen aus dem praktischen Einsatz runden den Vortrag ab.
Markus Lachenmayr, MSc in Software Engineering von der TU München, arbeitet für die Siemens AG und beschäftigt sich mit der Analyse und Sicherung operativer Eigenschaften von Software Architekturen von Cloud-basierten Systemen.
Dr. Joachim Fröhlich, ACM Senior und IEEE Member, arbeitet für die Siemens AG und beschäftigt sich mit Techniken, Methoden und Prozessen für Entwicklung und Test von Software für verlässliche Systeme.
Markus Lachenmayr, Joachim Fröhlich
Markus Lachenmayr, Joachim Fröhlich
Vortrag: Di 2.3
Themen:
12:05 - 12:40
Erfahrungen aus 8 Jahren Test-Gap-Analyse im Praxiseinsatz
Erfahrungen aus 8 Jahren Test-Gap-Analyse im Praxiseinsatz

Durch Tests möchten wir Fehler finden, bevor diese in Produktion gelangen. Leider gelingt das nicht immer. Studien zeigen, dass die meisten Feldfehler dort auftreten, wo viel geändert, aber wenig getestet wurde. Seit 2012 setzen wir deshalb mit unseren Kunden Test-Gap-Analyse ein, wodurch solche ungetesteten Änderungen bereits während der Entwicklung vollautomatisch identifiziert werden, damit Entwickler und Tester frühzeitig und kontinuierlich reagieren können.

In unserem Vortrag stellen wir zunächst kurz die Grundlagen der Test-Gap-Analyse und die benötigten Datenquellen vor. Anschließend diskutieren wir verschiedene Anwendungsszenarien, die sich im Laufe der Zeit aus den Anforderungen unserer Kunden ergeben haben.

Die Bandbreite reicht dabei von Test-Gap-Analyse für automatisierte Unit-Tests einzelner Systemkomponenten bis zu automatisierten oder manuellen End-to-End-Tests, die mehrere unabhängige Systeme in verschiedenen Technologien durchlaufen. Wir sprechen sowohl über die Anwendung von Test-Gap-Analyse durch Test-Manager, die einen Überblick auf Systemebene brauchen, als auch durch Tester und Entwickler, die effizient die Test-Gaps für einzelne Change Requests analysieren wollen.

Im zweiten Teil des Vortrags stellen wir Herausforderungen bei der Einführung der Test-Gap-Analyse vor. Beispielsweise ist in Embedded-Umgebungen die Aufzeichnung von Testabdeckung oft nicht ohne Weiteres möglich, und die neuen Deployment-Paradigmen aus dem Microservice- und Docker-Umfeld erfordern neue Strategien zum Einsammeln und Aggregieren der Testdaten.

Nach mehrjährigem Einsatz der Test-Gap-Analyse bei einigen Kunden können wir zudem erstmals den intuitiv wahrgenommenen Nutzen mit konkreten Zahlen untermauern. So konnten Projekte, die die Analyse kontinuierlich nutzen, die Anzahl der Fehler in Produktion um über 20% reduzieren. Mit einer Analyse dieser Erkenntnisse beschließen wir unseren Vortrag.

Dr. Andreas Göb ist Team Lead Customer Success und Berater für Softwarequalität bei der CQSE GmbH. Er begleitet seit Jahren viele Firmen beim Verbessern ihrer Softwareentwicklungs- und Testprozesse. Er hat eine Promotion im Bereich Softwarequalität der TU München und spricht auf nationalen und internationalen Konferenzen.
Dr. Sven Amann ist Berater für Softwarequalität bei der CQSE GmbH. Er studierte Informatik an der TU Darmstadt und der Pontifícia Universidade Católica in Rio de Janeiro und promovierte in Software Engineering, mit Förderung durch das Führungskräfteentwicklungsprogramm Software Campus. Anfang 2017 gründete er den Blog AcademicsCode.com.
Andreas Göb, Sven Amann
Andreas Göb, Sven Amann
Track: Track+
Vortrag: Di 3.3
Themen:
12:40 - 14:05
Mittagspause
Mittagspause

14:05 - 14:40
TestMaster - der Testmanager der Zukunft?
TestMaster - der Testmanager der Zukunft?

Als Tester in einem großen, agilen Projekt kennst du bestimmt den Gedanken, dass es schneller vorangehen könnte, wenn es jemanden gäbe, der den Blick auf das große Ganze hat. Dass es sinnvoll wäre eine zentrale Person zu etablieren, die teamübergreifend Test-Impediments erkennt und beseitigt, sowie die Testdaten und -aktivitäten sinnvoll managed. Der TestMaster ist eine von uns erarbeitete, neue Rolle, die dir und deinem agilen Projekt dabei hilft, Ziele schneller und koordinierter zu erreichen, indem der TestMaster projektweit alle Aktivitäten so aufeinander abstimmt und koordiniert, dass alles reibungslos ineinandergreift.

Zielpublikum: alle, die mit Test zu tun haben
Vorraussetzungen: Keine
Schwierigkeitsgrad: Advanced

Extended Abstract:
Die Anzahl agiler Softwareprojekte steigt, was häufig zu einer Vielzahl von positiven Resultaten führt, wie beispielsweise eine kundenorientierte Software, eine bessere Abstimmung in den Entwicklungsteams sowie eine kontinuierliche Einbindung des Tests. Jedoch beklagen immer mehr Projekte, vor allem mit einem hohen Grad an Komplexität oder mit vielen unterschiedlichen Playern, die Lücke, die in klassischen Projekten der Testmanager ausfüllt. Wer kümmert sich um die Erstellung der  globalen Teststrategie, die Erstellung und Verwaltung von Testdaten und das Ausfechten von fachlichen Konflikten gegenüber dem Management? Natürlich werden diese Aufgaben häufig von Testern übernommen. Oft findet sich aber niemand, der diese Aufgaben übernehmen kann oder will. Gerade wenn die Anforderungen von zahlreichen Testteams berücksichtigt werden müssen, fehlt eine Rolle, die den Überblick behält und die Bedürfnisse der Testteams aus eigener Erfahrung kennt und nachvollziehen kann. Hier kann der TestMaster helfen. Der TestMaster unterstützt hands-on, koordiniert die Teams testbezogen und beseitigt globale Test-Impediments, er coacht die Tester fachlich und steht bei der Ausübung der Rollen zur Seite. In diesem Erfahrungsbericht stellen wir vor, wie wir den TestMaster in unseren Projekten eingeführt, Prozesse etabliert und welchen Mehrwert wir durch diese Rolle generiert haben.
Bastian ist Testermanager und TestMaster. Er hat es sich zur Aufgabe gemacht bestmögliche Beratung im Hinblick auf Planung, Methodik und Strategie auf den Kunden anzupassen, um Softwarequalität zu optimieren.
Katja ist eigentlich Biologin, zählt aber neuerdings lieber bugs als Moleküle. Neben ihrer Arbeit als Testerin sucht sie Lösungen für die alltäglichen Probleme eines Testers in großen, agilen Projekten.
Bastian Baumgartner, Katja Meyer
Bastian Baumgartner, Katja Meyer
Vortrag: Di 1.4
Themen:
14:05 - 14:40
Better, Faster, Stronger - Delivering High Quality Products
Better, Faster, Stronger - Delivering High Quality Products

Agile software delivery teams have to apply other methods than only testing to ensure the fast and robust delivery of an overall high quality product.

This includes understanding the business value as much as the system architecture of the product. Once the environment is understood the team can apply methodologies like continuous integration/deployments to ensure a quick delivery of a robust product. As a result, on the one side the classic QA role is stretched far beyond managing tests and releases while on the other side entire software development teams.

Target Audience: All people of all roles as this is mostly about the *collaboration* across roles. Only the chosen perspective is the one of a QA.
Prerequisites: Curiosity
Level: Advanced

Finn cares about high quality software from his heart. He is an analyst. Sometimes he analyses client business needs, sometimes teams and their processes and sometimes software. Finn loves being the team driver towards building a high quality product. He strongly believes in the benefits of truly agile environments to achieve this goal. In his previous life he was a physicist: Finn was analysing how to build transistors and hard drives out of single molecules.
Finn Lorbeer
Finn Lorbeer
Track: Agile
Vortrag: Di 2.4
Themen:
14:50 - 15:25
Geht's auch kleiner? Mikroheuristiken im explorativen Testen
Geht's auch kleiner? Mikroheuristiken im explorativen Testen

'Wie wird man Experte in explorativem Testen? Erfahrung und Intuition...

Diese Antwort ist nicht zufriedenstellend! Viele Leute glauben, dass exploratives Testen 'einfach herumklicken' ist. Das schadet unserem Image und wirft Risiken für die Zukunft auf.

In diesem Talk taucht Alex in die tiefe Welt unserer Entscheidungsprozesse ein. Ihr Ziel ist es, Muster zu identifizieren, die unsere Schritte beim explorativen Test lenken. Anhand dieser Muster können wir unser Testen verbessern und es anderen erklären.

Wenn du je gefragt wurdest 'Aber wie hast du das gefunden?' oder du selbst jemandem diese Frage gestellt hast - dann besuch diesen Talk!

Zielpublikum: Tester, Entwickler
Vorraussetzungen: Grundkenntnisse vom explorativen Testen
Schwierigkeitsgrad: Advanced
Alex Schladebeck ist eine Testerin aus Leidenschaft und eine Beraterin für Qualität und Agilität. Sie arbeitet für BREDEX GmbH und leitet dort den Bereich Software Qualität und Test Consulting.
Sie verbringt ihre Zeit in Kommunikation mit verschiedenen Menschen aus der IT. Sie Ob es Trainings und Coachings sind, Pairing-Sessions mit Entwicklern und Testern, oder Kundenberatung
Alex liebt es, in agilen Prozessen zu arbeiten und immer mehr über Qualitätstechniken und Methoden zu lernen.
Alex spricht häufig auf Konferenzen als Speaker oder Keynote-Speaker über Agilität und Qualitätssicherung aus Sicht ihrer Projekterfahrung.


Alexandra Schladebeck
Alexandra Schladebeck
Vortrag: Di 1.5
Themen:
14:50 - 15:25
Qualitätssteigerung durch selbstorganisierte Teams, (k)ein Widerspruch? - Agile QS in agilen Teams
Qualitätssteigerung durch selbstorganisierte Teams, (k)ein Widerspruch? - Agile QS in agilen Teams

Wer legt die Regeln in einem agilen Team fest? Das Team! Wer organisiert die Arbeitsabläufe im agilen Team? Auch das Team! Wer ist verantwortlich für die Qualität des Produkts? Sie ahnen es, wieder das Team! Agile Entwicklung ist nur sinnvoll umsetzbar, wenn sich die Teams selbst organisieren können. Nur wie findet die Abstimmung über agile Teamgrenzen hinweg statt? Richtig, in den Teams.

Selbstorganisation ist mehr Freiheit, aber auch mehr Verantwortung. Aus der Erfahrung als Angestellter und Mitinhaber eines selbstorganisierten Unternehmens heraus kläre ich die Fragen. Wie wird agile Selbstorganisation gelebt?

Zielpublikum: Agile Teams, Tester, Testmanager, POs, Scrum Master
Vorraussetzungen: keine
Schwierigkeitsgrad: Basic

Extended Abstract:
Wer legt die Regeln in einem agilen Team fest? Das Team! Wer organisiert die Arbeitsabläufe im agilen Team? Auch das Team! Wer ist verantwortlich für die Qualität des Produkts? Sie ahnen es, wieder das Team! Agile Entwicklung ist nur sinnvoll umsetzbar, wenn sich die Teams selbst organisieren können. Nur wie findet die Abstimmung über agile Teamgrenzen hinweg statt? Richtig, die Teams. Selbstorganisation ist mehr Freiheit, aber auch mehr Verantwortung. Aus der Erfahrung eines selbstorganisierten Unternehmens heraus kläre ich die Fragen.

Wie findet sich 'der Tester' mit seinen 20 Rollen in der Agilen Welt wieder? Sind etwa die Aufgaben dieser vielen Rollen hinfällig? Brauchen wir keine 'Tester' mehr im agilen Umfeld? Testen die Coder selber alles? Wer hat aber in Projekten mit vielen Teams den Blick für das große Ganze? Genau an diesen Fragen scheitern viele agile Teams.

Die Logische Folge: Die Qualität sinkt und die Fehlerrate steigt. Die schnelle Schlussfolgerung: 'Früher war alles besser'

Wie können agile Teams sich über die Teamgrenzen hinweg selbst organisieren? Wie werden teamübergreifende Entscheidungen getroffen, wenn unterschiedliche Teaminteressen gegeneinander stehen.

Die aktuellen Lehrpläne halten sich dezent zurück bei diesen Fragen. Gemeinsam betrachten wir die unterschiedlichen Teamaufstellungen der aktuellen Lehrmeinung. Welche Vor- und welche Nachteile ergeben sich. Und es gibt noch eine weitere Möglichkeit. Darüber hinaus lernt der Teilnehmer, wie Entscheidungen in Gruppen mit unterschiedlichen Interessen getroffen werden können.
Mein Motto lautet: 'Aus der Praxis für die Praxis!' Denn ich blicke als ISTQB zertifizierter Test- und Qualitäts-Management-Experte auf fast 20 Jahre praktische Erfahrung in den Bereichen Soft- und Hardware zurück. Ebenso weitreichend ist mein Wissen in der Test-Automatisierung, Test-Koordination sowie Test-Analyse.

Ich lege besonderen Wert auf eine ausgewogene Mischung zwischen explorativen und automatisierten Tests. Darüber hinaus biete ich Ihnen praktische Erfahrung in der Einführung von Test- und Testmanagementwerkzeuge.
Georg Haupt
Georg Haupt
Track: Agile
Vortrag: Di 2.5
Themen:
09:20 - 10:05
Where Next for Ethical Tech?
Where Next for Ethical Tech?

Reluctantly, the tech industry has owned up to its deep social, political, and moral impacts. Now the hard work begins. A slew of ethical aids have emerged – toolkits, card decks, playbooks – but the true challenges run deeper, caused by complex human trade-offs, misaligned values, and faulty incentives. Can concerned technologists genuinely shift the moral cultures of high-performing tech firms? Will ethics become a shared industry commitment, or forever remain a mere discussion point?

Cennydd Bowles, author of Future Ethics, explores why nascent ethics initiatives stumble in tech companies, the structural difficulties that lead to unethical decisions, and the questions that most obstruct moral progress: Isn’t the law enough? Does ethics mean slower innovation and less profit? The answers will help illuminate a radical new path that helps ethical advocates to consider hidden stakeholders and harms and that draws on collective power to change entrenched systems.

Cennydd Bowles is a London-based designer with seventeen years experience advising companies including Twitter, Ford, Cisco, and the BBC. His focus today is designing ethical and responsible technology, and helping companies think more constructively about our shared futures. He has lectured on the topic at Facebook, Stanford University, and Google, and is a frequent speaker at technology and design events worldwide. His second book, Future Ethics, was published in 2018.
Cennydd Bowles
Cennydd Bowles
Track: Keynote
Vortrag: KeyMi
Themen:
10:05 - 10:35
Pause
Pause

10:35 - 11:10
Lessons Learned aus 5 Jahren modellbasiertem Testen
Lessons Learned aus 5 Jahren modellbasiertem Testen

Haben wir alle bzw. haben wir die richtigen Test Cases? Welche Testabdeckung haben wir in Bezug auf die Spezifikation? Was müssen wir wirklich testen? Haben wir in unserer Spezifikation noch Lücken?
Alle diese Fragen lassen sich bei dem Einsatz von Testmodellen lösen.

Bei dem Einsatz dieser Testanalyse / -design Methode gibt es aber auch das ein oder andere Stolpersteinchen, über das man stolpern kann.

In diesem Vortrag berichte ich von den Erfahrungen, die ich bei der erfolgreichen MBT Einführung bei einem Luftfrachtkonzern in Frankfurt gemacht habe und was man bei einem Einsatz mit einem gemischten Team (onsite / offshore) beachten sollte.

Zielpublikum:
Tester, Testmanager und jeder der eine effiziente Testanalysemethode kennenlernen möchte
Vorraussetzungen: Keine
Schwierigkeitsgrad: Basic

Extended Abstract:
In diesem Vortrag beschäftige ich mich mit dem Einsatz von MBT in agilen und "klassischen Wasserfall" Projekten. Zu jedem Bereich gibt es einen Teil mit Lessons Learned und abschließend auch noch eine Betrachtung von aktuell noch vorhandenen Stolpersteinen. Ebenso habe ich noch einige Tipps (ein Auszug aus den Modelling Guidelines) dabei, die beim Einsatz und bei der Einführung von MBT beachtet werden sollten. Am Ende erfolgt noch ein kleiner Ausblick was mit MBT noch so alles möglich ist und auch teilweise schon umgesetzt ist.

Oliver Schuhmacher ist Consultant in der cimt objects AG. Er beschäftigt sich seit über 15 Jahren mit dem Thema Softwarequalität und hat in dieser Zeit unterschiedliche Projekte im Bereich Finance und Logistik betreut. Seit mehr als 5 Jahren beschäftigt er sich mit dem Thema modellbasiertes Testen und der Ableitung von Testfällen aus Testmodellen.
Oliver Schuhmacher
Oliver Schuhmacher
Vortrag: Mi 1.1
Themen:
10:35 - 11:10
Usable Fuzzing - Fuzz Testing für Jedermann!
Usable Fuzzing - Fuzz Testing für Jedermann!

In den letzten Jahren haben moderne Fuzz Testing Techniken sehr an Popularität gewonnen. Mit Fuzzing wurden bereits 4000 Bugs im Chrome Browser gefunden. Allerdings ist das große Problem der aktuellen Fuzzer wie AFL, libFuzzer und hongFuzz, dass sie so komplex sind, dass sie sehr spezielle Security Expertise benötigen und deswegen außerhalb von großen Firmen wie Google, Microsoft, Facebook und ähnlichen kaum zum Einsatz kommen.

In diesem Vortrag wird eine wissenschaftliche Studie vorgestellt in der aktuelle Probleme von Fuzzern vorgestellt werden sowie Lösungsansätze die Fuzzing für alle Tester ermöglichen.

Zielpublikum: Tester, Entwickler, Testmanager, Projektleiter, Entscheider
Vorraussetzungen: Grundlegende Programmierkenntnisse
Schwierigkeitsgrad: Basic

Extended Abstract:
Die Komplexität moderner Software wächst ständig und folglich wächst auch der Aufwand für Tests ständig mit. Testing ist essentiell um die Qualität und Sicherheit der Software zu gewährleisten. In den letzten Jahren haben moderne Fuzzing Techniken in Industrie und Akademia sehr an Popularität gewonnen. Bei Google wurden in 2019 die meisten Schwachstellen durch fuzzing gefunden[1].

Mit Fuzzing wurden bereits 4000 Bugs im Chrome Browser gefunden. Im Gegenteil zu statische Code Analyse hat Fuzzing den großen Vorteil, dass alle gefundenen Bugs tatsächliche Bugs und keine False Positives sind. Allerdings ist das große Problem der aktuellen Fuzzer wie AFL, libFuzzer und hongFuzz, dass sie so komplex sind, dass sie sehr spezielle Security Expertise benötigen und deswegen außerhalb von großen Firmen wie Google, Microsoft, Facebook und ähnlichen kaum zum Einsatz kommen.

In diesem Vortrag wird eine wissenschaftliche Studie die in Kollaboration mit der Arbeitsgruppe 'Usable Security And Privacy' der Uni Bonn durchgeführt wurde vorgestellt. Die Studie zeigt Benutzbarkeitsprobleme von aktuellen Fuzzern und erklärt warum der Einsatz bisher nicht weiter verbreitet ist. Darauf aufbauend werden Techniken vorgestellt mit denen Fuzzing  benutzerfreundlicher und effektiver gestaltet werden können. Das Ziel dabei ist, Fuzzing im Softwareentwicklungs- und Testingprozess zu integrieren und automatisieren, sodass ohne besondere Expertise Schwachstellen früh gefunden werden können.

Zentrale Inhalte sind:
- Semi-automatisierte Generierung von Fuzz Tests
- Buildsystem-agnostisches Kompilieren von Code für Fuzzing
- Structure-aware fuzzing um tiefe Bugs zu finden
- Automatisches Testing von Netzwerkschnittstellen
- Unassisted Fuzzing von REST APIs
- Integration von Fuzzing in CI/CD
- Intuitive Monitoring und Analyse von gefundenen Bugs.

Der Vortrag wird zeigen wie mit diesen Techniken Tests deren Einrichtung bisher erhebliche Expertise und Zeit benötigten, innerhalb von wenigen Minuten erstellt werden können und so Fuzzing ein Werkzeug für alle Tester werden kann.
Matthew Smith is a Professor for Usable Security and Privacy at the University of Bonn and Fraunhofer FKIE. His research is focused on human factors of security and privacy with a wide range of application areas, including network security, authentication, mobile and app security and, most recently, usable security for developers and administrators. His work has been published at amongst others IEEE S&P, ACM CCS, USENIX Security, NDSS, ACM SIGCHI and SOUPS the Symposium on Usable Security and Privacy. Matthew Smith is also actively involved in the organisation of top academic conferences and is serving on the steering committees of SOUPS, USEC and EuroUSEC as well as serving as program co-chair for SOUPS 2016 and 2017 and program co-chair for IEEE EuroS&P 2017 and 2018. In 2015 his ERC Starting Grant 'Frontiers of Usable Security' was selected for funding.  In 2017 he co-founded Code Intelligence.
Khaled Yakdan, Matthew Smith
Khaled Yakdan, Matthew Smith
Vortrag: Mi 2.1
Themen:
10:35 - 11:10
Vortrag andagon
Vortrag andagon

Track: Track+
Vortrag: Mi 3.1
Themen:
10:35 - 12:40
Whole team approach to agile testing - Make yourself more popular while training your whole team in agile testing skill
Whole team approach to agile testing - Make yourself more popular while training your whole team in agile testing skill

As a tester, working with other team members without much testing experience, can be full of misunderstandings and missed high expectations. What happens if you introduce the 'whole team' testing approach, include them in your testing activities, sell them the pair and mob testing concepts and train them to find and develop their testing skills?

Is it though possible to achieve lasting and good quality software products while onboarding your whole team in testing in only few weeks or months? In this interactive tutorial you'll learn how to do that while enabling your team members to be productive, successful and happy.

Maximum number of participants: 30

Target Audience:
Testers at all experience levels, managers, POs, designers, developers and all others interested in testing
Prerequisites: Being interested in software testing and open to learn and prove new ideas.
Level: Basic

Extended Abstract:
Let's be honest. Testers are not popular team members. They always find critical issues and risks that prevent the product increment of being delivered on time. What if you're not always the bad guy but rather help them develop into explorers and quality advocates and help them feel the joy of testing?

Getting the shared understanding within your team of what the importance of testing is, can cost you lots of time and energy and in some teams, you will never be able to reach it. But wait, what if you introduce the 'whole team' testing approach and train them to find the 'silver lining' of their testing skills? Training various roles as testers can slow you at the beginning but you will find out the ways to train productive, happy team members in a few weeks while still delivering valuable software to your customers.

Maja will share what she's learned in her experience as test/QA leader in teams with a DevOps culture. In this hands-on tutorial, you'll have the opportunity to practice techniques for delivering good quality while coaching multidisciplinary team members in testing.

One of the main problems she would like to solve together is doing good testing work while training people on the job. Learn to divide and conquer the activities which are going on at the same time, those you use to teach people, understand what risks lie with that approach and what kind of results and problems you might have.

You will leave the tutorial knowing how to build trust, manage time effectively (and teach others how to do that) and accept different personalities and work attitudes.

Applying different techniques and checks presented and practiced, you will be able to significantly improve your leadership skills, inspire and inject your new-to-testing team members with a passion for testing and create the base for future test/QA leads.
Maja Schreiner is a graduate engineer in information systems and technologies with almost 20 years of practical experience in professional software development and quality engineering. Maja's interests include applying agile testing practices in everyday work, advocating for agile methodologies and coaching other testers and developers.
Before she started on her entrepreneur journey, Maja worked as a Product Owner, Test Manager, Test Engineer and software engineer in the public administration, finance and health industry.   Her heart goes for Agile. She's been running the Agile Testing Meetup Zurich for 4 years between 2014 and 2018.
Daria Isaeva (Swisscom) is a graduate engineer of telecommunications and informatics with over 10 years of experience in quality assurance and business requirements engineering.

Daria collected testing expertise within several projects for national telecom providers from USA, Australia, New Zealand, and Switzerland.

Daria's passion goes to agile methods of working, she likes inspiring colleagues for changes and self-growth and promotes the importance of testing.
Maja Schreiner, Daria Isaeva
Maja Schreiner, Daria Isaeva
Track: Workshop
Vortrag: Mi 4
Themen:
11:20 - 11:55
OWASP Top 10 - Wie Webanwendungen angegriffen werden und wie Entwickler sicher entwickeln können
OWASP Top 10 - Wie Webanwendungen angegriffen werden und wie Entwickler sicher entwickeln können

Das Open Web Application Security Project (OWASP) ist eine Non-Profit-Organisation, die die Sicherheit von Webanwendungen verbessern will. Ihre wohl bekannteste Veröffentlichung ist die OWASP Top 10, eine Aufzählung der zehn kritischsten Sicherheitsrisiken in Webanwendungen. Die Liste wurde erstmals 2003 veröffentlicht und zuletzt 2017 aktualisiert.

Der Vortrag stellt anhand der OWASP Top Ten Angriffe auf Webanwendungen vor, ihre Ursachen und welche Maßnahmen bei der Entwicklung dagegen helfen.

Zielpublikum: Entwickler, Tester, Projektleiter
Vorraussetzungen: Teilnehmer sollten mit Grundlagen von Webtechnologien und der Entwicklung von Webanwendungen vertraut sein
Schwierigkeitsgrad: Basic

Extended Abstract:
Sicherheit im Web ist ein wichtiges Thema, das beim Entwickeln und Pflegen von Anwendungen und Schnittstellen noch immer vernachlässigt wird.

Warum sind Eingabevalidierung und Ausgabekodierung wichtige Grundlagen von sicheren Webanwendungen? Was muss ich beim Umsetzen von Mechanismen zur Authentifizierung und Autorisierung beachten? Inwiefern kann eine Anwendung von Injektionsschwachstellen betroffen sein? Warum sollte ich beim Entwickeln auf verlässliche Komponenten von Dritten achten und darauf, dass möglicherweise sicherheitsrelevante Aktionen von meiner Anwendung geloggt werden?

Sicherheit muss beim Entwickeln von Webanwendungen von Anfang an berücksichtigt werden - dieses Bewusstsein und das notwendige Wissen werden jedoch in Studium und Kursen unzureichend vermittelt. Zudem gibt es für jede Plattform und Sprache geeignete Bibliotheken, die beim sicheren Programmieren helfen, aber oft nicht oder unzureichend genutzt werden.

Dieser Vortrag soll helfen, diese Lücken zu schließen, und gibt zum Abschluss Hinweise auf gute weiterführende Quellen zur tieferen Auseinandersetzung mit dem Thema.

Frank Ully studierte Technische Redaktion, baute während seines Studiums die Abteilung Unternehmenskommunikation eines Softwareherstellers auf und leitete sie einige Jahre. Später war er dort für IT-Sicherheit verantwortlich. Berufsbegleitend schloss er den Master Security Management ab und erwarb IT-Sicherheits-Zertifizierungen. Im November 2017 begann er seine Arbeit bei Oneconsult Deutschland. Seit April 2018 ist Frank Ully Senior Penetration Tester & Security Consultant.
Frank Ully
Frank Ully
Track: Security
Vortrag: Mi 1.2
Themen:
11:20 - 11:55
The power of mocking APIs
The power of mocking APIs

Struggling to test failure cases like receiving an invalid response , 5XX errors and so on? Having flaky tests due to slow API responses?

Blocked because the API you depend on doesn't exist yet or isn't completely ready? Facing trouble to test various scenarios due to lack of control over third-party APIs?

These are some very common problems we encounter. We cannot rely on slow APIs, which provide a very narrow range of responses. So how can we test effectively  in such situations? Is there any feasible solution available? Fortunately, there is: mocking of APIs.

If you are less familiar with mocks & want to gain more insight, join this talk.

In this session, I will explain how to mock APIs using Wiremock. With real life example application, we'll explore how  to handle complicated scenarios and formtesting strategy. Join this session to gain insights on how, when, and most importantly why we should mock APIs. Let's find together how development and testing can benefit from mocks. Remember, 'If API testing is the king, mocking APIs is the queen!'

Please note: At the end of this talk, all attendees will get access to the example application used during talk for trying out the mocking themselves.

Target Audience: Developers, testers, test managers, decision maker
Prerequisites: Basic Knowledge of APIs
Level: Advanced

Shivani is a passionate QA Engineer who believes that knowledge sharing boost up all engaged parties and increases their confidence. It was summer of 2013 when Shivani and 'testing' met each other first time and are best friends since then. Holding rich experience in testing domain, she currently works as Senior QA Engineer with XING (the largest business network in German speaking countries). With hands-on in all layers of software testing ranging from UI(frontend), API and backend, functional, non-functional , mobile testing - API remains her all-time favourite.

As a certified scrum master, working in agile manner is always her approach. She believes in idea of spreading her findings about any 'new fancy stuff' she learns. She has worked with multiple international teams and brings forward idea of whole team contributing for quality. She's always up for conversation over email, linkedin, Xing , twitter or beer table :)
Shivani Gaba
Shivani Gaba
Vortrag: Mi 2.2
Themen:
12:05 - 12:40
Spock und AsciiDoc - vom Test zur Spezifikation und zurück
Spock und AsciiDoc - vom Test zur Spezifikation und zurück

Spock ist ein BDD Testframework für Webanwendungen. Der Product-Owner beschreibt das Verhalten einer Applikation und der Entwickler überprüft es über einen automatischen Test.

Wäre es nicht cool, wenn daraus ein verständliches Dokument erzeugt würde?
Kein Problem! Wir generieren einen Testreport mit Screenshots in AsciiDoc und fügen weitere erklärende Texte hinzu um eine les- und ausführbare Spezifikation zu erhalten.

Aber sollte die Spezifikation nicht am Anfang stehen?
Also zurück auf Start und die Tools rückwärts angewandt!

Zielpublikum: Entwickler, Product-Owner, Tester
Vorraussetzungen: Grundwissen über BDD
Schwierigkeitsgrad: Advanced


Extended Abstract:
Spock ist ein Testframework für Webanwendungen, mit dem man unter anderem den Behavior Driven Development Ansatz, kurz BDD, verfolgen kann. Der Product-Owner beschreibt das Verhalten einer Applikation und der Entwickler überprüft es über einen automatischen Test.

Dem Entwickler reicht die Ausgabe 'PASSED' oder 'FAILED', denn er kennt ja den Code seiner Tests. Wäre es nicht cool, wenn auch der Product-Owner ein verständliches Dokument bekäme?

Kein Problem! Wir generieren über ein Template einfach einen Test-Report in AsciiDoc und fügen weitere erklärende Texte hinzu um eine les- und ausführbare Spezifikation zu erhalten. Screenshots aller wichtigen Schritte bereichern die Spezifikation weiter.

Sollte aber die Spezifikation nicht am Anfang stehen? Und warum Spezifikation, wenn wir agil sein wollen?

Richtig! Stellen wir also eine iterative Feature-Beschreibung an den Anfang und verfeinern diese mit automatischen Tests um am Ende eine gut lesbare und verifizierbare Spezifikation des Verhaltens unseres Systems zu erhalten!

Die Vorteile liegen auf der Hand - die Vorgehensweise verbessert die Kommunikation zwischen Product-Owner und Entwicklern und am Ende bekommen wir ein Dokument, welches Ihre wertvolle Software korrekt und überprüfbar beschreibt.

Christian Fischer ist Software Engineering Coach bei der DB Systel und liebt TDD, Extreme Programming und Craft Beer.
Ralf D. Müller ist ambitionierter Groovy & Grails-Entwickler und versucht stetig, seine Arbeit weiter zu vereinfachen. Zurzeit beschäftigt er sich insbesondere mit der Verbesserung der ganzheitlichen Dokumentation von Systemen, vor allem mit Hilfe des arc42-Templates und AsciiDoc.

Er arbeitet als Software Engineering Advocate bei der DB Systel, der IT-Tochter und Digitalpartner der Deutschen Bahn.
Christian Fischer, Ralf Müller
Christian Fischer, Ralf Müller
Vortrag: Mi 1.3
Themen:
12:05 - 12:40
Werkverträge im Testing - ist das wirklich möglich?
Werkverträge im Testing - ist das wirklich möglich?

Im Rahmen des Vortrages werden folgende Fragestellungen behandelt:

- Welche Vertragsarten für externe Unterstützung gibt es?
- Was sind die Vorteile bzw. Nachteile der verschiedenen Vertragsarten?
- Welche Voraussetzungen zur Durchführung von Werkverträgen müssen erfüllt werden?
- Kann man Werkverträge auch im agilen Umfeld einsetzen?
- Welche Hindernisse gibt es im Testing bei der Durchführung von Werkverträgen?
- Wie kann man trotzdem Werkverträge im Testing umsetzen?
- Wie sind die Erfahrungen im Bereich funktionale Fahrzeugtests bei Bombardier Transportation

Zielpublikum: Testmanager, Projektleiter, Entscheider
Vorraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Advanced
Herr Dr. Erhardt Wunderlich ist seit Oktober 2010 bei der Bombardier Transportation GmbH beschäftigt und leitet seit 2019 die funktionalen Fahrzeugtests am Standort Hennigsdorf. In der Zeit von 2007 bis 2010 war er Leiter des Testcenters der BDT AG in Rottweil.
Bis 1999 arbeitete er bei der ALCATEL Deutschland in der Softwareentwicklung für Testsoftware. Von 1999 bis 2002 war er Teamleiter einer Softwaretestgruppe bei der ALCATEL USA. 2003 wechselte er zur BDT AG.
Erhardt Wunderlich
Erhardt Wunderlich
Vortrag: Mi 2.3
Themen:
12:05 - 12:40
Qualitätssicherung unter erschwerten Bedingung - oder wie Sauce Labs die eigene Testing-Infrastruktur testet
Qualitätssicherung unter erschwerten Bedingung - oder wie Sauce Labs die eigene Testing-Infrastruktur testet

Mobile-Tester stehen täglich vor der Herausforderung die Qualität ihrer Testing-Infrastruktur aufrecht zu halten. Dass in immer kürzeren Zeiträumen neue mobile Endgeräte und Betriebssysteme auf den Markt gepusht werden, erschwert die Situation nur zusätzlich.

Aber wie stellt ein Cloud-Testing-Provider wie Sauce Labs sicher, dass alle Features in der Cloud mit über 400 verschiedenen Geräten und OS-Kombinationen zuverlässig nach jedem Release funktionieren?

Bekommen Sie in diesem Talk einen Einblick in die Prozesse und Tools, die Sauce Labs nutzt, um die Real Device Cloud zu testen. Wir werden einen Blick auf funktionale JUnit, XCUI und Espresso Tests werfen, die die Funktionstüchtigkeit aller Features auf den unterstützten OS Version sicherstellt. Des Weiteren werden wir und Last- und Ausdauertests mit Selenium und Appium anschauen, um die Zuverlässigkeit der Cloud auch bei starker Nutzung zu prüfen. Und selbstverständlich dürfen wir synthetische Nutzertests nicht vernachlässigen, die während der Laufzeit überwachen, ob alle Teile des Systems die SLAs erfüllen.

Zusätzlich schauen wir uns an wie alle diese Tools in unseren CI/CD Prozess integriert werden, um möglichst automatisiert und datengetrieben täglich Änderungen in unsere Produktionsumgebung zu deployen.

Zielgruppe:
Tester, Programmierer, Architekten, agile Teams
Prerequisites: none
Level: All

Andreas ist als Director Engineering für die Entwicklung der Mobile Real Device Cloud bei Sauce Labs verantwortlich. Seit mehr als 7 Jahren arbeitet er daran das Testen auf realen mobilen Engeräten einfacher, schneller und zuverlässiger zu machen. Durch seine Rollen als Entwickler, Architekt, Manager und Ansprechpartner für Kunden hat er sich in seiner Karriere aus den verschiedensten Blickwinkeln mit dem Thema Qualitätsicherung auseinader gesetzt.
 

Andreas Lüdeke
Andreas Lüdeke
Track: Track+
Vortrag: Mi 3.3
Themen:
12:35 - 14:00
Mittagspause
Mittagspause

14:05 - 14:40
Professionell Scheitern in 7 Schritten: So ruinieren Sie ihre API durch falsches Testen!
Professionell Scheitern in 7 Schritten: So ruinieren Sie ihre API durch falsches Testen!

Immer häufiger wird Software als verteiltes System mittels Microservices umgesetzt. Während der Programmcode je Service dabei kompakter und leichter testbar ist, werden die Schnittstellen untereinander eher komplexer und schwer zu testen. Allzu oft werden API Tests vernachlässigt, was zu erhöhter Fehleranfälligkeit und schlechtem API Design führt.

Dieser Vortrag zeigt mit einem Augenzwinkern und anhand praktischer Beispiele, welche Fehler sich besonders dazu eignen, APIs aufgrund falscher oder fehlender Tests zu ruinieren. Er soll zum Nachdenken anregen, was man beim API Design und Test in verteilten Systemen alles bedenken sollte.

Zielpublikum: Tester, Entwickler, Architekten
Vorraussetzungen: REST/Messaging APIs, Microservices, Testautomatisierung
Schwierigkeitsgrad: Basic

Extended Abstract:
Immer häufiger werden Softwaresysteme heutzutage als auf Microservices basierende, verteilte Systeme designt, welche sich an den Bounded Contexts der Domäne orientieren. Dabei bringt dieser Architekturansatz neben vielen Vorteilen, wie der leichteren Änderbarkeit einzelner Services und unabhängigerer Entwicklung, auch Herausforderungen durch den höheren Verteilungsgrad mit sich. Ohne Kommunikation zwischen den Services über entsprechende Schnittstellen (APIs) geht es letztlich auch nicht.

Dabei gestaltet sich das Testen jener APIs nicht als trivial, sowohl technologisch als auch aus prozessualen Gesichtspunkten. Schnell wird zum Beispiel der Ruf laut nach integrativen Testumgebungen zur Integration der Schnittstellen. Jedoch widerspricht genau dies der losen Kopplung, die man durch Microservices erreichen wollte.

Dieser Vortrag zeigt mit einem Augenzwinkern und anhand praktischer Beispiele, wo typische Fehlerquellen beim API Testing in verteilten Anwendungen lauern und wie man das Softwaresystem dadurch bestmöglich in den Ruin stürzen kann. Er soll zum Nachdenken anregen, was man beim API Design und Test in verteilten Systemen alles bedenken sollte, um Qualität und Unabhängigkeit zu erhalten.

Florian Pfleiderer beschäftigt sich als Senior Consultant bei Digital Frontiers mit agiler Software-Entwicklung. Seine Kunden berät er in den Bereichen Architektur, Microservices und Craftmanship.
Florian Pfleiderer
Florian Pfleiderer
Vortrag: Mi 1.4
Themen:
14:05 - 15:25
Testcontainers - Integrationstesten mit Docker leicht gemacht
Testcontainers - Integrationstesten mit Docker leicht gemacht

Testcontainers ist der Kleber der Integrationstests mit benötigter Infrastruktur in Docker-Containern verbindet. Seit der Verfügbarkeit von Docker ist es leicht geworden unterschiedliche Datenbanken, Message Broker, Application Server, etc. bereitzustellen.

Die Registry erleichtert die Distribution. Notwendige Konfigurationen wurden in docker-compose oder dem Build-Tool erledigt. Jetzt musste vor der Ausführung eines Tests nur noch kurz der oder die Container gestartet werden. Leider ein weitere Schritt, der bedacht, bzw. ins Vorgehen eingebaut werden musste. Hier setzt Testcontainers mit einer einfachen und zuverlässigen Testintegration an.

Zielpublikum: Primär Entwickler von automatisierten Tests aber auch alle, denen Infrastruktur für diese fehlt und die Impressionen sammeln möchten.
Voraussetzungen: Grundlegende Java Kenntnisse
Schwierigkeitsgrad: Basic

Maximale Teilnehmerzahl: 30

Technische Voraussetzungen:

Es wird ein eigener Rechner benötigt sowie:
  • git (https://git-scm.com/)
  • Java (8 oder 11) (z.B. https://adoptopenjdk.net/releases.html)
  • Docker (https://docs.docker.com/engine/install/)
  • Java IDE z.B. Jetbrains Idea Community Edition (https://www.jetbrains.com/de-de/idea/download)
  • https://plugins.jetbrains.com/plugin/7212-cucumber-for-java
  • Unbeschränkter Netzwerkzugang
Extended Abstract:
Unsere Reise wird mit einem einfachen Datenbanktest beginnen, an dem die wichtigsten Komponenten kurz erklärt werden. Wenn die Grundlagen geklärt sind, starten wir mittels Docker eine Anwendung zum Datenbankzugriff über einen Webbrowser auf dem eigenen Rechner (https://www.adminer.org/de/) und testen diese dann mit Selenium, Cucumber und mehreren unterschiedlichen DBMSen. Zum Schluss können wir einige Rahmenparameter auf Basis der gemeinsamen Erfahrungen besprechen.

Stefan Hildebrandt ist als Softwareentwickler und Berater seit mehr als zehn Jahren in größeren Projekten bei Kunden aus unterschiedlichen Branchen tätig. Seine Schwerpunkte sind Web- und Backend-Entwicklung sowie Werkzeuge zur Test- und Deployment-Automatisierung. Sein Interesse gilt vermehrt der ganzheitlichen Betrachtung des Softwareentwicklungsprozesses und der Potenziale, die außerhalb der eigentlichen Entwicklung schlummern.

Stefan Hildebrandt
Stefan Hildebrandt
Track: Workshop
Vortrag: Mi 2.4
Themen:
14:50 - 15:25
Compatibility Testing of Microservices with Consumer Driven Contracts
Compatibility Testing of Microservices with Consumer Driven Contracts

Business success increasingly depends on the ability to deliver software fast. Microservices architectures and CD pipelines can only fully work to that end if services can be independently put into production. How can we make sure that we won't break our consumers when deploying new versions of an application? Do we need expensive and slow end-to-end tests? How can we keep an overview of who is speaking to whom?

In my talk, I will explain the motivations behind Consumer-Driven Contracts in Microservices, how contract testing can be integrated in your CI/CD pipeline and what frameworks support the implementation of Consumer-Driven Contracts.

Target Audience:
developers/software engineers, test engineers, software architects, project managers
Prerequisites: Basic knowledge of Agile Testing and Microservices.
Level: Basic

Antoniya Atanasova is a Consultant and Agile Quality Engineer at Novatec Consulting with more than five years of experience in Agile Development for various customer projects. She is always looking for new approaches to testing challenges in the ever-changing world of enterprise software development. Antoniya's areas of interest are Microservices Testing and Development, specifically Consumer-Driven Contracts.
Antoniya Atanasova
Antoniya Atanasova
Vortrag: Mi 1.5
Themen:

Zurück