It's tempting to use BDD as a way to describe and run acceptance tests on the UI. Our experience has shown, that BDD is more beneficial, when used in earlier testing stages instead.

Target Audience: Test managers, testers, developers, ... so for the whole team
Preriquisites: Knowledge in BDD advantageous, but not mandatory
Level: Basic

Extended Abstract:

BDD is well established way to provide abstract description of expected system behaviors to developers. But, due to years of siloed mindsets, BDD is often described as the next big thing to describe and automate testcases for QA teams. This talk gives a small insight, in why using BDD in later testing stages (System-Integration and Acceptance Testing) could create additional overheads and more complicated test automation setups. You will learn how BDD can be beneficial when used correctly, but also how it can disrupt team velocity if introduced at the wrong places.

Mehr Inhalte dieses Speakers? Kein Problem, schaut doch mal bei sigs.de vorbei:
https://www.sigs.de/autor/dehla.sokenou

Cypress ist ursprünglich als Alternative zu Selenium gestartet. Inzwischen füllt es mit Component Testing auch die Lücke zwischen Unit- und End-2-End-Tests in der Webentwicklung, die bisher nur ungenügend besetzt war.
Lässt man Cypress Component Tests in sein Projekt, dann automatisieren sie schnell nicht nur Komponententests, sondern bieten sich auch als Ersatz für typische Unit-Test-Werkzeuge wie Jest an.
Kann Cypress wie ein Schweizer Taschenmesser wirklich den kleinen Zoo der bisher verwendeten Werkzeuge ablösen? Wir haben es ausprobiert und berichten über Erfahrungen positiver Art, aber auch über die Grenzen, an die wir gestoßen sind.

Zielpublikum: Tester, Entwickler, Testautomatisierer
Voraussetzungen: Projekterfahrung, Testautomatierungserfahrung, Basiskenntnisse in der Webentwicklung
Schwierigkeitsgrad: Advanced

Extended Abstract:
Das Open-Source-Werkzeug Cypress ist ursprünglich als Alternative zu Selenium im Bereich der End-2-End-Tests in der Webentwicklung gestartet. Inzwischen füllt es mit Component Testing auch die Lücke zwischen Unit- und End-2-End-Tests in der Webentwicklung, die bisher nur ungenügend besetzt war, also bei den Komponenten- und Integrationstests.
Lässt man Cypress Component Tests in sein Projekt, dann automatisiert man damit schnell nicht nur Komponententests, sondern auch Unit-Tests. Sie bieten sich damit als Ersatz für typische Unit-Test-Werkzeuge für Webanwendungen wie Jest oder Karma an. Cypress etabliert sich damit als Automatisierungswerkzeug für alle Teststufen, von den Unit- bis hin zu den End-2-End-Test.
Kann Cypress wie ein Schweizer Taschenmesser wirklich den kleinen Zoo der bisher verwendeten Werkzeuge ablösen? Wir haben es ausprobiert und berichten über Erfahrungen positiver Art, aber auch über die Grenzen, an die wir gestoßen sind. Unter anderem zeigen wir, wie einfach bestehende Tests migriert werden können, und haben evaluiert, was unter welchen Bedingungen schneller und stabiler ist, die Unit-Tests in Jest oder die in Cypress.

Ein Adrenalinkick für QA Experten - mussten Praktiken, Testansätze und -"Software muss stabil funktionieren und bei der Beurteilung von Softwarequalität ist das sicherlich das wichtigste Kriterium. Langfristig darf aber auch die Wartbarkeit der Software nicht vernachlässigt werden, denn das führt zu Mehraufwänden bei Fehlerbeseitigungen und Weiterentwicklungen, auch bekannt als technische Schulden.  Fehlende, nicht-kontinuierliche oder nicht-automatisierte Testfälle dürfen ebenso zu technischen Schulden gezählt werden.
In diesem Vortrag wird erklärt, was genau unter Softwarequalität zu verstehen ist.
Ergebnisse und Erkenntnisse aus einem Jahr der Qualitätsüberwachung in einer CI-Pipeline werden vorgestellt.

Zielpublikum: Tester:innen, Entwickler:innen, Testmanager, Projektleiter
Voraussetzungen: Keine
Schwierigkeitsgrad: Basic

Extended Abstract:
ISO 25010 zieht zur Definition von Softwarequalität neben Funktionalität und Stabilität auch Wartbarkeit als Bewertungskriterium in Betracht. Eine Vernachlässigung der Wartbarkeit führt zu Mehr-Aufwänden bei Fehlerbeseitigungen und Weiterentwicklungen, auch bekannt als technische Schulden oder 'Technical Debt'.
Bei der Bewertung von Softwarequalität darf man aber auch das umgebende Test-Setup nicht vernachlässigen, z.B. Code-Abdeckungs-Metriken aus dynamischen Tests. Auch fehlende, nicht-kontinuierliche oder nicht-automatisierte Testfälle dürfen als technische Schulden verstanden werden.
'Continuous Integration' (CI) ermöglicht einen automatisierten, kontinuierlichen Test und definierte Qualitäts-Kontrollpunkte. Durch die kontinuierliche Überwachung kann eine gleichbleibende und hohe Softwarequalität sichergestellt werden, wodurch eine kontinuierliche Bereitstellung der Software, auch bekannt als 'Continuous Deployment' (CD), ermöglicht wird. Probleme können frühzeitig erkannt, adressiert und Kosten-optimal beseitigt werden.
In diesem Beitrag erhalten Sie einen Überblick über Grundlagen der Softwarequalität und eine Umsetzung der kontinuierlichen Überwachung in einer CI Pipeline.
Anhand eines konkreten Projekt-Beispiels werden Ergebnisse und Erkenntnisse aus einem Jahr der Anwendung vorgestellt.

Die IVU hat eine große automatische Testsuite mit mehrere tausend Testfällen. Diese sind zum Teil Sprachübergreifendend aufgebaut (C++, Java). Vorhandene Ansätze zur Testselektion waren bisher nicht sicher genug oder wegen der Struktur der Testfälle nicht anwendbar. Dadurch wurde es immer schwieriger, ein umfangreiches und gleichzeitig zeitnahes Feedback an die Entwickler:innen zu liefern. Gemeinsam mit der TU München haben wir Werkzeuge zur Testselektion entwickelt, die dafür sorgen, dass nur die relevanten Testfälle ausgeführt werden. Ich stelle im Vortrag die grundsätzlichen Konzepte und Ergebnisse dieser Zusammenarbeit vor.

Zielpublikum: Tester:innen, Test-Manager:innnen, Entwickler:innen, Architekt:innen
Voraussetzungen: Grundlegende Kenntnisse zur Testautomatisierung
Schwierigkeitsgrad: Basic

Eine gute Continuous Integration läuft weniger als 10min - etwa die Zeit, um einen Kaffee zu holen. Für Dolby liegt die größte Herausforderung dabei in der Testlaufzeit, denn das sind oft Stunden. Ein Lösungsansatz ist, nur eine Teilmenge der Tests direkt auszuführen und die übrigen Tests in nachgelagerte Test-Builds (z.B. nightly) auszulagern. Wir berichten von den Nachteilen manueller Testauswahl, von technischen und organisatorischen Herausforderungen einer automatisierten Lösung und davon, wie es im Projekt 'Dolby Car Automotive' letztendlich doch gelang, sicherzustellen, dass die CI dauerhaft unter 10 Minuten bleibt.

Zielpublikum: Tester:innen, Testmanager:innen, Entwickler:innen
Voraussetzungen: Basiswissen Softwareentwicklung und -test
Schwierigkeitsgrad: Basic

Extended Abstract:
Eine gute Continuous Integration läuft weniger als 10min - etwa die Zeit, um einen neuen Kaffee zu holen. Diese Ansicht teilen die Entwickler:innen von Dolby mit vielen Kolleg:innen aus anderen Organisationen [1] und Pionieren wie Martin Fowler [2]. Für Dolby liegt die größte Herausforderung dabei in der Laufzeit der (automatisierten) Tests, denn viele dieser Tests müssen wenigstens alle paarweisen Kombination von Konfigurationsoptionen wie dem Lautsprechersystem (5.1, 5.1.2, 7.1, ...) und der Bitrate des Tons durchlaufen. So werden aus 40 Testfunktionen schnell einmal 1300 Testfälle und die Ausführung aller Testfälle dauert mehrere Stunden.

Ein Lösungsansatz ist, eine Teilmenge der Tests für schnelles Feedback direkt auszuführen und die übrigen Tests in nachgelagerte Test-Builds (z.B. nightly) auszulagern, die auch länger brauchen dürfen. Wenn man diese Teilmenge passend zu den konkreten Änderungen auswählt, die getestet werden sollen, lassen sich rund 90% der Testfehlschläge in nur 2% der Testlaufzeit erkennen. Doch wie gelingt eine solche Testauswahl im Alltag?

Lars Kempe (Dolby)  und Sven Amann (CQSE) haben verschiedene Taktiken miterlebt. Sie berichten von den Nachteilen manueller Testauswahl, von technischen und organisatorischen Herausforderungen bei der Eigenentwicklung einer automatisierten Lösung und davon, wie es ihnen im neuen Projekt 'Dolby Car Automotive' letztendlich doch gelungen ist, mit der Test-Impact-Analyse von Teamscale sicherzustellen, dass die Continuous Integration dauerhaft unter 10 Minuten bleibt.

  [1]: Hilton et al.: dl.acm.org/doi/abs/10.1145/3106237.3106270
  [2]: Fowler: martinfowler.com/articles/continuousIntegration.html