Gamification bringt Spaß in den Projektalltag. Aber lohnt es sich überhaupt?
Um dies einschätzen zu können, geben wir einen Überblick über verschiedene spielerische Ansätze, die auf die Qualitätssicherung von Software fokussieren.
Wir gehen darauf ein, wie man Gamification gezielt und im richtigen Maß in Projekte einführt, welche Schwerpunkte gesetzt werden sollten und wie skeptische Kollegen überzeugt werden können.
Damit kann der Vortrag als Entscheidungsgrundlage dienen. Richtig eingesetzt, lohnt sich Gamification!

Zielpublikum: Projektleiter:innen, Manager, Entscheider
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Anfänger

Extended Abstract
Spielerische Ansätze in der Software-Entwicklung sind nicht neu und finden immer häufiger ihren Platz im Projektalltag. Doch kosten diese nicht einfach nur Zeit und Geld? Bringt es überhaupt Vorteile, das Team „spielen“ zu lassen? Und wie misst man Erfolg oder auch das Scheitern einer Spielidee?
Wir zeigen am Beispiel von Gamification-Ansätzen in der Qualitätssicherung, dass diese das Potenzial haben, nicht nur den Projektalltag aufzulockern und den Teamzusammenhalt zu stärken, sondern auch die Softwarequalität spielend zu verbessern. Gezielte Produktverbesserung, z. B. durch Bug-Hunting, wird ebenso adressiert wie systematische Prozessverbesserung, z. B. durch Maturity Poker.
Voraussetzung ist, dass Gamification gezielt eingesetzt wird, um effizient zu sein. Der spielerische Ansatz muss zum Team und zum Projekt passen, Schwächen beheben und auf Lösungen für bestehende Probleme fokussieren.
Der Vortrag will eine Entscheidungshilfe geben, wann sich spielerische Ansätze lohnen und wann man eher auf sie verzichten sollte. Denn nur, wenn sich Erfolge einstellen und Gamification das Projekt voranbringt, stehen alle Beteiligten hinter dem Vorgehen, und die investierte Zeit ist nicht „verspielt".

Schon von Quarkus gehört, dem neuen und effizienten JVM-Framework? Das - nicht unerfolgreich - etablierten Frameworks wie Spring Boot Konkurrenz macht?
Und bist Du daran interessiert, wie man eine Quarkus-App erstellt und - noch wichtiger - Teile davon isoliert testet?
Interessiert? Dann lass mich von unseren Erfahrungen berichten, wie sich Quarkus-Apps mit Kotlin, JUnit und MockK testen lassen. Praktische Einblicke garantiert!

Zielpublikum: Developers
Voraussetzungen: Basic knowledge about JVM languages, JVM frameworks and the microservice architecture pattern
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Das relativ junge Quarkus konnte sich zu einem ernst zu nehmenden Konkurrenten für etablierte Microservice-Frameworks wie Spring Boot entwickeln. Das liegt insbesondere daran, dass das leistungsfähige und dennoch leichtgewichtige JVM-Framework es schafft, Startzeiten und Speicherverbrauch von Anwendungen erheblich zu reduzieren. Damit ist es nicht nur für die Entwicklung von Microservices in containerisierten Cloud-Plattformen wie Kubernetes interessant, sondern auch für Serverless Computing.
Und es unterstützt meine Lieblings-Programmiersprache: Kotlin!
Wenn man eine Anwendung mit Quarkus und Kotlin entwickelt, kommt man früher oder später (hoffentlich früher ;-) ) nicht umhin, isolierte Tests zu schreiben. Nur so lässt sich bekanntermaßen automatisiert feststellen, ob sich der Anwendungscode wie erwartet verhält. Und als Kotlin-Entwickler will man dazu bekannte Technologien wie z. B. JUnit und MockK nutzen. Es gibt dabei aber einige wesentliche Aspekte, die beim Testen und Mocking von CDI-Beans in Quarkus beachtet werden müssen.
Interessiert? Dann habt teil an unseren Erfahrungen, wie sich Quarkus-Apps mit Kotlin, JUnit und MockK testen lassen. Praktische Einblicke garantiert!

<provocative statement>Manuelles Testen ist die Abarbeitung einzelner definierter Testschritte. Hierfür benötigt es keine speziellen Skills, wir brauchen nur Click-Monkeys – oder?!</provocative statement
<mind change>Falsch! Wir müssen den Menschen in den Fokus stellen. Manuelles Testen sollte vielmehr als “Human Testing” betrachtet werden. Die Tester:innen nutzen all ihre Stärken zum Durchführen der Tests - eigenständiges Denken, neue Ideen entwickeln, sowie kollaborative Ansätze stehen hierbei im Zentrum des „Human Testing“.</mind change>

Zielpublikum: Tester:innen, Testmanager, Product Owner, Scrum Master, Stakeholder
Voraussetzungen: Grundlegende Kenntnisse im Testing
Schwierigkeitsgrad: Anfänger

Extended Abstract
In vielen Projekten erleben wir immer mehr, dass manuelles Testen nur als Abarbeitung diverser Testfälle gesehen wird. Hierfür werden lediglich “dumme” Click-Monkeys benötigt, Tester:innen die Testfälle Schritt für Schritt durchführen und diese nicht hinterfragen.
Aus unserer Erfahrung ist dies ein Unding, setzt die Leistung der Tester:innen herab und verschwendet wertvolle Ressourcen. Die einfache Abarbeitung von Testschritten kann in der Regel automatisiert werden.
Durch den erhöhten Automatisierungsgrad wird mehr Kapazität für den/die Tester:in geschaffen. Manuelles Testen suggeriert die oben beschriebene Abarbeitung einzelner Testschritte, wohingegen Human Testing mehr den Wert des Menschen in den Mittelpunkt rückt. Hierbei kann er/sie seine/ihre Stärken voll ausspielen und zum Beispiel in Testing Sessions auch mal über den Tellerrand hinausschauen, um eigenen Testideen zu folgen oder sich in Themen zu explorieren (beispielsweise via Testing Touren).
Human Testing rückt nicht nur den Menschen in den Mittelpunkt, sondern drückt auch die Wertigkeit des Testens aus. Es ist eben nicht nur die Durchführung manueller Testfälle, sondern vielmehr eine vertrauensvolle Zusammenarbeit mit Fokus auf Qualität.
In unserem Vortrag erläutern wir zum einen die Vorurteile gegenüber manuellem Testen, die uns in unzähligen Projekten begegnet sind, sowie mögliche Ansätze, wieso das manuelle Testen zukünftig als Human Testing zu betrachten ist. Ebenso zeigen wir auf, welchen Standard wir im Testing zwingend erreichen müssen, so dass die Rolle des Testers den verdienten Respekt erhält.

Wenn ein System wächst, wächst auch die Anzahl automatisierter Tests. Wir sehen immer öfter Test-Suiten, die Stunden oder Tage laufen. Das ist lähmend langsam. Wenn die Ausführung aller Tests zu lange dauert, kann man einen Teil der Tests häufiger ausführen als den Rest. Der Schlüssel ist, diese Teilmenge so zu wählen, dass sie in einem Bruchteil der Zeit einen Großteil der Fehler findet. Im Vortrag stellen wir verschiedene Ansätze hinsichtlich Kosten, Nutzen und Anwendbarkeit und Erfahrungen aus Forschung und Praxiseinsatz vor.

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

Extended Abstract
Mit dem Alter und der Größe eines Softwaresystems steigt typischerweise der Bedarf für ausgiebige und qualitativ hochwertige Software-Tests. Zudem werden für mehr Anwendungscode auch mehr Tests benötigt. Damit steigt die Ausführungszeit der Tests.
In der Praxis führt das immer häufiger zu Test-Suiten, die Stunden bis Tage brauchen, um einmal zu laufen. Das bringt eine Reihe von Problemen mit sich. Für die Entwickler bedeutet es, dass sie Feedback für den geänderten Code erst eine lange Zeit, nachdem sie die Änderungen gemacht haben, bekommen. Das macht es deutlich schwieriger, die Fehler im Code zu finden und zu beheben. Außerdem werden moderne Verfahren, wie zum Beispiel Continuous Integration dadurch deutlich erschwert. All das mindert den Wert der Tests ausgerechnet für die Systeme, in denen sie absolut essenziell sind, nämlich große komplexe Software-Systeme.
Eine naheliegende Lösung für das Problem ist es, einen Teil der Tests häufiger auszuführen, als den Rest. Die Herausforderung dabei ist, diese Teilmenge an Tests so zu bestimmen, dass man möglichst viel Zeit einsparen kann, ohne die Fähigkeit der Tests, Fehler zu finden, erheblich zu mindern. Um das zu erreichen, gibt es verschiedene Ansätze, von denen jeder Vor- und Nachteile mit sich bringt.
Ein Ansatz ist die Test-Suite-Minimierung. Dabei werden verschiedene Kriterien verwendet, wie testfallspezifische Coverage [1] und Ausführungszeit, um ein Subset von Tests zu wählen, das in einem Bruchteil der Zeit einen Großteil der Fehler finden soll. [2] Ziel dieses Verfahrens ist es, eine Liste von Tests zu wählen, die jeden Tag oder öfter ausgeführt werden kann, um schnelleres Feedback zu ermöglichen. Die vollständige Test-Suite sollte dennoch in regelmäßigen Abständen ausgeführt werden.
Der zweite Ansatz, den wir betrachten, ist die Test-Impact-Analyse. Dabei werden Testfälle aussortiert, die bei ihrer nächsten Ausführung höchstwahrscheinlich keine Fehler finden. Die Annahme, dass ein Testfall beim nächsten Testlauf keinen Fehler findet, begründen wir durch die Änderungen seit dem letzten Testlauf. Ein Test, der keinen Code abdeckt, der seit dem letzten Mal geändert wurde, wird voraussichtlich auch keinen neuen Fehler finden. Zudem werden die Testfälle so sortiert, dass innerhalb der kürzest möglichen Zeit eine möglichst hohe Code Coverage erreicht wird. [3]
Im Vortrag gehen wir auf die Vor- und Nachteile der beiden Verfahren ein und präsentieren unsere Erfahrungen aus Forschung und Praxis.

Weiterführende Literatur
[1] F. Dreier, Obtaining Coverage per Test Case, Masterarbeit (2017)
[2] R. Noemmer, Conception and Evaluation of Test Suite Minimization Techniques for Regression Testing in Practice, Masterarbeit (2019)
[3] E. Juergens, D. Pagano, Test-Impact-Analyse: Fehler früh erkennen trotz großer, langlaufender Test-Suites, OBJEKTspektrum 06/2018,
[4] J. Rott, R. Niedermayr, E. Juergens, D. Pagano, Ticket Coverage: Putting Test Coverage into Context, Proceedings of the 8th Workshop on Emerging Trends in Software Metrics (2017)
[5] E. Juergens, D. Pagano, Haben wir das Richtige getestet? Erfahrungen mit Test-Gap-Analyse in der Praxis, Whitepaper (2016)
[6] R. Noemmer, R. Haas, An Evaluation of Test Suite Minimization Techniques, International Conference on Software Quality (2020)

Der effektive Einsatz einer Testautomatisierungslösung steht und fällt mit den verwendeten Werkzeugen. In dem Vortrag stellen wir die Ergebnisse einer wissenschaftlichen Arbeit zur Erstellung eines Kriterienkataloges für die Auswahl des passenden Testautomatisierungswerkzeugs für unsere Projekte vor. Dabei wurden die Kriterien und deren Gewichtung nach Vorgehensmodellen, Technologie, Einsatzgebiet sowie dem Blickwinkel der Rollen evaluiert. Die Anwendung des Kriterienkatalogs soll leichtgewichtig sein und Vorgaben des agilen Manifests befolgen.

Zielpublikum: Tester:innen, Agile Teams, Testmanager:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheider
Voraussetzungen: Grundkenntnisse Testen/Testautomatisierung, Projekterfahrung, Fachkenntnisse agile Methoden
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Der effektive Einsatz einer Testautomatisierungslösung steht und fällt mit den verwendeten Werkzeugen. Für die gezielte Auswahl der Werkzeuge und besonders für die Begründung gegenüber dem Management benötigen Projekte daher einen Katalog von Kriterien. Dabei unterscheiden sich die Kriterien bzw. deren Gewichtung je nach Einsatzgebiet, Vorgehen, Technologie und besonders der Rolle des Betrachters.
In dem Vortrag stellen wir die Ergebnisse einer wissenschaftlichen Konzeption eines Kriterienkataloges für die Auswahl der passenden Testwerkzeuglösung im Rahmen der Testautomatisierung für die ZEISS Digital Innovation vor. Dabei wurden die Kriterien und deren Gewichtung unter anderem nach den verwendeten Vorgehensmodellen (Agile, Scaled, Klassisch), der verwendeten Technologie, dem Einsatzgebiet sowie den Blickwinkeln der unterschiedlichen Rollen evaluiert.
Als Endergebnis soll es möglich sein, passende Testautomatisierungstestwerkzeuge je nach Projekteinsatz anhand des Kriterienkatalogs evaluieren bzw. empfehlen zu können. Durch die flexible Entscheidungsvorlage soll sichergestellt werden, dass die im Kundenprojekt eingesetzten Testwerkzeuge allen relevanten Anforderungen des Projekts, aber auch des Unternehmens entsprechen. Dabei soll die Anwendung des Kriterienkatalogs leichtgewichtig sein und besonders die Vorgaben des agilen Manifests befolgen.