Behavior driven development kann ein ein mächtiger Verbündeter im Softwarelebenszyklus sein, aber auch mächtig im Wege stehen. In diesem Talk werde ich auf die Quintessenz von BDD eingehen und eine Abgrenzung zu ähnlichen Konzepten wie TDD, ATDD oder auch SBE machen. Weiterhin werde ich einige Verhaltensweise aufzeigen, die einer gelungenen Umsetzung im Weg stehen und dafür sorgen, dass BDD seine Stärken nicht ausspielen kann. Gezielt werde ich auf drei Probleme eingehen, die mir in der Praxis begegnet sind. Ich werde berichten, was mir in der Vergangenheit geholfen hat, Teams wieder auf den rechten BDD Kurs zu bringen.

Zielpublikum: Tester, Entwickler, Product Owner, Projektleiter
Vorraussetzungen: Grundlegendes Verständnis von Softwareentwicklung
Schwierigkeitsgrad: Basic

Extended Abstract:
Behavior driven development kann ein ein mächtiger Verbündeter im Softwarelebenszyklus sein. Genauso gut kann es aber auch mächtig im Wege stehen und den Prozess verlangsamen, verkomplizieren und zum reinen Selbstzweck verkommen.

Im Rahmen dieses Talks werde ich auf die Quintessenz von BDD eingehen und eine Abgrenzung zu ähnlichen Konzepten wie Test Driven Development, Acceptance Test Driven Development oder auch Specification by Example machen. Unabhängig vom gewählten Softwareentwicklungsmodell, kann es gerade in agilen Umfeldern seine Stärken ausspielen. Weiterhin werde ich einige Verhaltensweise aufzeigen, die einer gelungenen Umsetzung mächtig im Weg stehen können und dafür sorgen, dass BDD seine Stärken nicht ausspielen kann. Gezielt werde ich auf drei Probleme eingehen, die mir in der Praxis bereits häufiger begegnet sind. Dem Reflex widersprechend, diese Probleme mittels Workarounds zu umschiffen, werde ich berichten, was mir in der Vergangenheit geholfen hat, Teams wieder auf den rechten BDD Kurs zu bringen, damit BDD nicht zu einem reinen Selbstzweck verkommt und das Team verlangsamt.

I have been working on a project with an extremely intricate users' roles structure for more than a year and during that time I've noticed many things that I could have done better and issue that I could have avoided.

I will drag your attention to: importance of creating and reviewing documentation on a regular basis; unification of roles restrictions; admin panel testing; merging of roles; priorities in system roles testing; how not be lost in permissions testing.

Absence of critical issues in roles and permissions is crucial for business, thus shouldn`t be neglected.

Target Audience: Testers
Prerequisites: experience with access rights testing would be nice but not necessary
Level: Basic

Extended Abstract:
Most of websites have at least 3 system roles - admin, logged in user and guest. Testing of users' access rights doesn`t seem to be too complicated in this case. However, what if there are multiple roles? What if there are more than 10 roles and some of their functionalities overlap?

I want to tell a story of the project with an intricate users' access rights system.

I am going to raise the following topics:

- What to do if you are hired when the project is already ongoing and there is no documentation for user roles;

• Conflicts in logic when we have combinations of permissions;
• Prioritizing roles and permissions that affect business the most;
• Unreasonable distribution of time resources due to insufficient research;
• Unification of the restrictions applied to users;
• In what cases you should automate tests for user roles;
• Danger of checking going through access right flows on front-end only;
• Admin panel testing.

In my opinion sometimes roles and permissions testing is underestimated and is not tested separately. Instead it's expected that a tester will cover all roles while testing a feature. This is a justified approach when a new feature is tested, but not effective during regression or for automated tests.

Absence of critical issues in roles and permissions is crucial for business, thus shouldn`t be neglected.

Jeder Tester kennt und benutzt Testmethoden im Projekt - sollte man meinen.Und denoch stellen wir in unseren Projekten immer wieder fest, dass Tester in der Praxis nicht aufbewährte Verfahren (die sie in den ISTQB-Schulungen gelernt haben) zurückgreifen oder sie gar nicht mehr kennen oder beherrschen.Auch werden in agilen Projekten viele Testfälle direkt durch Programmierer in Form von Unittests geschrieben, denen oft ein tiefes Verständnis für etablierte Testmethoden und methodische Heransgehensweisen fehlt.Wir zeigen, wie einfach es tatsächlich ist, solche Teammitglieder abholen. Durch gezieltes Vorleben eines methodischen, konsequenten Vorgehens gemäß ISTQB im Projekt. Durch "Coaching by doing", durch Weiterbildungsmaßnahmen, und vor allem praxiserprobten Einsatzmöglichkeiten dieser Testverfahren auch zu anderen Zwecken als der Testfallerstellung.Und wie wir - und Sie - damit die Qualität im Projekt regelmäßig und verlässlich verbessern können.Einfach.Effektiv.Vielseitig.Konsequent erfolgreich.Freuen Sie sich auf eine halbe Stunde komprimierte Praxiserfahrung mit Erfolgsfaktor.

Ever wondered how experienced testers provide feedback quickly, discover unknown unknowns, and find that issue yet again on the first touch of the application? Let's lift the curtain together and discover the magic behind exploratory testing - as an ensemble. Whether you identify yourself as a developer, product person, tester, or anything else, whether you consider yourself a newbie or rather experienced, you are welcome to join this ensemble. Let's practice and explore together!

Maximum number of participants: 25

Target Audience: Testers, developers, product owners, UX, business analysts - anyone on a product development team
Prerequisites: Participant required equipment: Laptop
Level: Basic

Wir zeigen, dass spielerische Ansätze in der Qualitätssicherung nicht nur positive Effekte auf die Qualität durch Steigerung der Kreativität haben. Zusätzlich stärken sie die Kollaboration, den Teamzusammenhalt und die Position von QS-Verantwortlichen durch das gemeinsame Erlebnis und die Challenge. Wir stellen einige Ansätze aus der Praxis vor und liefern Tipps, wie man Spiele z.B. für das manuelle Testen oder kollaborative Risikoanalysen gezielt und effizient gestalten kann.

Zielpublikum: Fachleute, Entwickler, Tester, Test Manager, Architekten, Betriebsteam
Vorraussetzungen: Grundlegendes Verständnis von Test und QS
Schwierigkeitsgrad: Basic

Extended Abstract:
Testautomatisierung ist heute Standard, macht Spaß und wird selbstverständlich in Projekten gelebt. Daneben gibt es aber viele andere Aufgaben in der Qualitätssicherung, die eher unbeliebt, doch notwendig sind. Dazu zählen u.a. manuelle Tests. Wie schafft man es auf einfache Art und Weise, dass alle Stakeholder, von den Entwickler/innen bis hin zu den Kund/innen, das System manuell testen? Ganz einfach - man macht ein Spiel daraus! Ausgehend von spielerischen Ansätzen zum explorativen Testen erweitern wir den Fokus und widmen uns auch anderen QS-Themen wie der Risikoanalyse und weiteren agilen Praktiken für QS. Unsere Erfahrung ist: Fängt man einmal damit an, so können die Mitspieler/innen nicht genug davon haben - mit positiven Effekten auf den Teamzusammenhalt und die Qualität.

Seven years ago the author got for the first time exposed to agile product development. Last year he joined his current company believing to 'have seen it all'. One year later he has experienced agile development at a whole new level. This experience report shares the technical and organizational challenges faced in the development, testing and test automation of complex banknote processing systems, and how they have been overcome as part of a second agile transformation program. The author believes that this journey has been more than worthwhile and should inspire others - in particular testers - to go 'all agile'.

Target Audience: Testers, test architects, product owners, scrum masters. decision makers
Prerequisites: Basic understanding of agile working methods
Level: Advanced

Extended Abstract:
Giesecke + Devrient Currency Technology is a leader in the development of high speed banknote processing systems that process millions of banknotes each day all across the world. These systems must be 100% accurate - even in jam situations -, and are realized using a combination of multiple complex software components - including everything from classic embedded software, to real time image processing, to database processing software - as well as custom 'hardware' components, i.e., mechatronic components. Multiple products are built from different common software platforms, and extensive, sophisticated test automation is used to run and evaluate regression tests as part of nightly continuous integration.

G+D started its agile journey already many years ago with agile teams in software development. In our presentation, we will explain multiple challenges we faced during this initial phase, both on an organizational as well as a technical level. In particular, the challenge of marrying traditional requirement management with agile software development. We will then present how a second agile transformation, i.e., going 'all agile', helped to resolve most of our initial challenges and how we address those remaining. With this change we witnessed that not only the awareness of testing and test automation, but also its consideration during product development gained a significant boost in our organization. We believe our findings can help other companies and testing teams that develop complex systems with highest quality and reliability standards to understand why going 'all agile' is so essential for a successful transformation of product development, and how it can even help them to strengthen testing as a discipline in their company.

Microservices sollen autark entwickelt und ausgeliefert werden. In der Realität können sie aber fast immer nur in Kombination sinnvoll benutzt werden.

Daher müssen sie auch integriert getestet werden - am besten automatisiert in einer CI/CD-Pipeline. Wenn aber die E2E-Teststufe fehlschlägt, dann ist die Auslieferung aller(!) beteiligter Microservices blockiert, bis die Ursache behoben ist.

An dieser Stelle zeigt sich der Widerspruch zwischen Qualitätssicherung mittels E2E-Tests und schnellen, unabhängigen Deployments.

In diesem Vortrag teilen wir unsere praktischen Erfahrungen mit diesem Problem, unsere Lösungsstrategien und alternative Ansätze.

Zielpublikum: Tester, Entwickler, Testmanager
Vorraussetzungen: Grundkenntnisse Testing, Grundkenntnisse Microservices
Schwierigkeitsgrad: Advanced

Extended Abstract:
Microservices sind noch immer in aller Munde. Sie sollen autark entwickelt, ausgeliefert und deployed werden. In der Realität können sie aber fast immer nur in Kombination sinnvoll benutzt werden.

Aus der Perspektive des Softwaretesters ist die Sache daher klar: wir wissen aus Erfahrung, dass Softwarekomponenten, die miteinander interagieren, auch integriert getestet werden müssen. Jeder musste sicher einmal die schmerzliche Erfahrung machen, dass es an dieser Stelle nicht genügt, eine einzelne Komponente in Isolation zu testen, um sicherzustellen, dass die Komponenten auch im Zusammenspiel sauber funktionieren.

Ein weiterer Vorteil von Microservices besteht in der hervorragenden Tauglichkeit für CI und insbesondere CD. Hier werden sämtliche Teststufen vollständig automatisiert in einer CI/CD-Pipeline durchlaufen. Wenn nun aber die E2E-Teststufe fehlschlägt, dann ist die Auslieferung von allen(!) beteiligten Microservices blockiert, bis die Ursache identifiziert und behoben ist!

An dieser Stelle zeigt sich der Widerspruch zwischen dem Ziel, über E2E-Tests die Qualität der Software sicherzustellen und dem Ziel, schnell und unabhängig einzelne Komponenten ausliefern zu können.

In diesem Vortrag teilen wir unsere Erfahrungen im Umgang mit diesem Dilemma aus einem Projekt mit über 200 Entwicklern und einer Microservices-Landschaft mit über 60 Services.

Dabei diskutieren wir die Vor- und Nachteile von E2E-Tests für Microservices, die wesentlichen Probleme und Hindernisse, denen wir begegnet sind, welche Lösungsstrategien wir entwickelt haben, und was es für alternative Ansätze gibt, die man bedenken sollte.

Der Kunde ist König - jedoch nicht nur beim Einkaufen, sondern auch wenn es darum geht digitale Produkte zu entwickeln. Niemand kann Ihnen besseres Feedback geben als Ihre Kunden selbst - warum fragen Sie sie nicht von Anfang an? Die Einbindung der Zielgruppe in einem frühen Stadium der Produktentwicklung ist entscheidend dafür, dass die Customer Experience nicht länger ein Rätselraten ist, sondern zu einer wissensgetriebenen Strategie wird. Lernen Sie im Vortrag, wie scheinbar unwichtige Faktoren signifikante Entscheider sein können und warum Sie nie aufhören sollten, den Status quo in Frage zu stellen.

Zielpublikum: Product Owner, Product Manager, Product Success Manager, Lead Testing & Development, Entscheider, Projektleiter
Vorraussetzungen: Keine speziellen Voraussetzungen benötigt
Schwierigkeitsgrad: Advanced

Extended Abstract:
Die Customer Experience reicht vom ersten Kontakt mit einer Marke über (hoffentlich) den Kauf, die Lieferung, das Auspacken, über viele weitere mögliche Touchpoints bis hin zur Benutzung - und endet eigentlich nie wirklich. Nach-Kauf-Erfahrungen wandeln sich zu Vor-Kauf-Erfahrungen und niemand kann Ihnen besseres Feedback zur erlebten Customer Experience geben als Ihre Kunden selbst - warum fragen Sie sie daher nicht von Anfang an und binden ihre Wünsche und Erwartungen direkt in die Produktentwicklung ein?

Wir bei Testbirds sind Experten darin, Kunden nach ihrer Meinung zu befragen. Mit 400.000 Remote-Testern auf der ganzen Welt haben wir rund um die Uhr Zugang zur größten Crowdtesting-Community weltweit. Wir haben fast 10 Jahre Erfahrung darin, aus Kundenfeedback die richtigen Schlüsse zu ziehen, diese auf die praktische Ebene zu übertragen und die Kundenerfahrungen für jede Art von digitalen Produkten auf das nächste Level zu heben. Dabei ist die Einbindung des Zielpublikums in einem frühen Stadium der Produktentwicklung entscheidend, um in die richtige Richtung zu gehen und von Anfang an dafür zu sorgen, dass die Customer Experience nicht länger ein Rätselraten ist, sondern zu einer wissensgetriebenen Strategie wird. Denn nur, wenn die Benutzerfreundlichkeit, Usability und Funktionalität unter realen Bedingungen getestet worden sind, können Sie sichergehen, dass sie auch unter realen Bedingungen funktionieren und Ihre Zielgruppe glücklich machen.

In unserer Präsentation nehmen wir die Qualität der Customer Experience und ihre außergewöhnlichen Einflussfaktoren unter die Lupe. Wir beantworten in unserer Präsentation:

• Was & warum Sie Kunden über Ihre Kundenerfahrung befragen sollten
• Wie Faktoren, die unwichtig erscheinen mögen, einen signifikanten Einfluss haben können
• Warum Sie nie aufhören sollten, den Status quo in Frage zu stellen

FMC und Spirit-Testing zeigen anhand eines konkreten Fallbeispiels, wie mit der cleveren Kombination zweier innovativer Tools die wichtigsten Herausforderungen im Test-Prozess erfolgreich gelöst werden können.

Für den Erfolg von Software-Projekten gewinnen effiziente automatisierte Testprozesse und ein qualitativ hochwertiges Testdatenmanagement angesichts stetig schneller wandelnder Rahmenbedingungen wie Digitalisierung, Customer Experience, KI und Cloud-Strategien immer mehr an Bedeutung.

FMC und Spirit Testing haben ihre Expertise gebündelt, um Unternehmen bei diesen Herausforderungen optimal zu unterstützen. Mit der Integration von succest und testOFFICE bieten sie den entscheidenden Mehrwert im Testprozess – insbesondere in SAP-Projekten.

succest von FMC Feindt Management Consulting GmbH ist eine innovative, branchenunabhängige Lösung für die Erstellung von passgenauen synthetischen Testdaten - auch für komplexe Testdaten-Konstellationen und historische Testdaten.

testOFFICE ist eine technologieübergreifende Testautomatisierungs- und Testmanagement-lösung – konzipiert sowohl für FachtesterInnen als auch für TesterInnen mit Entwicklungshintergrund. Auf Basis eines modernen modularen schlüsselwortgetriebenen Baukastens („sog. TCDL-Testing 2.0“) wurde mit testOFFICE eine anwenderfreundliche effektive Lösung für die Automatisierung von Testfällen im End2End-Test geschaffen.

Do you use test automation in your company, but still facing huge manual maintanance efforts in many other areas of the test life-cycle? Do you, for example, have this annoying daily routine of checking hundreds of failed test cases before the real problem is found? 

AI4T (Advanced Intelligence for Testing) is aiming to go beyond just automating test execution. Cutting-edge techologies like machine learning are leveraged to take a big step towards the vision of a fully automated test life-cycle.

In this talk, we focus on how to maximize automation in many testing activities to reduce boring and repeditive tasks.

Target Audience: Test automation engineers, developers, test and project managers
Prerequisites: A basic knowledge in software testing and test automation is beneficial. No development knowledge required.
Level: Advanced

Extended Abstract:
To keep up with today's fast-paced software development world, automation is essential to provide rapid feedback on software quality. One of the key drivers for businesses to succeed is the need for faster time to market and lean quality assurance. For this reason, processes throughout the entire test lifecycle must be accelerated through advanced intelligent automation.

In this talk, we move beyond automated test execution by making QA-related processes more comprehensive, scalable, and faster. With AI4T, we have developed approaches that take big steps towards a fully automated test life cycle.

We will tackle the following questions that often occur in a usual day of a test engineer and / or developer:

• Did your number of automated test cases grow so much that it takes way to long  till all the tests are complete?
• Are you facing this huge maintenance efforts to keep your tests up to date and functional after code changes?
• Do you have this annoying daily routine of having to sometimes check hundreds of failed test cases before finding what the actual problems were?
• Do you have this weak spot, that old systems and legacy code nobody dares to touch?

Our use-cases aim to provide new cutting-edge inspirations and solutions to these research questions.

Das GTB hat zusammen mit der TH Köln und der HS Bremerhaven sowie dem ATB eine Neuauflage der 2011 und 2015/16 erfolgreichen Umfragen zum Status-Quo und der Entwicklung von »Softwaretest in Praxis und Forschung« durchgeführt.

An der Befragung 2020 haben ca 1300 Personen teilgenommen und Fragen zur Qualitätssicherung aus Sicht des Managements, der operativen Umsetzung und der Forschung beantwortet. Die Umfrageergebnisse lassen in den letzten 10 Jahren einen deutlichen Trend in Richtung agiler Prozesse erkennen. Wo verorten sich in diesem Umfeld die grundlegenden Testkompetenzen? Dieser Frage werden wir in dem Beitrag nachgehen.

Zielpublikum: Management und Personen aus dem operativen Bereich zum Benchmarking des eigenen Unternehmens
Vorraussetzungen: keine
Schwierigkeitsgrad: Basic

Extended Abstract:
Das German Testing Board (GTB e.V.) hat zusammen mit der Technischen Hochschule Köln (Prof. Dr. Mario Winter) und der Hochschule Bremerhaven (Prof. Dr. Karin Vosseberg) sowie dem Austrian Testing Board (ATB) eine Neuauflage der 2011 und 2015/16 erfolgreichen Umfragen zum Status-Quo und der Entwicklung von »Softwaretest in Praxis und Forschung« durchgeführt. Bei der aktuellen Befragung haben 1307 Teilnehmende die Fragen zur Qualitätssicherung aus Sicht des Managements, der operativen Umsetzung und der Forschung beantwortet. Die Ergebnisse der aktuellen Umfrage sowie der zurückliegenden Umfragen stehen allen Interessierten im Internet unter der URL www.softwaretest-umfrage.de zur  freien Verfügung.

Ein Großteil der Fragen von 2011 und 2015/16 wurden für die aktuelle Umfrage übernommen, sodass eine sehr gute Abschätzung der Entwicklung in den letzten 10 Jahren gegeben werden kann: Was hat sich verändert? Wie sieht der Test-Alltag heute in den Unternehmen aus? Was hat sich im Test- Alltag etabliert? Diese und weitere Fragen waren Ausgangspunkt für die Umfragen.  Die bisherigen Auswertungen der Umfragen zeigen deutlich, dass sich der erkennbare Trend zu agilen Softwareentwicklungsprozessen bestätigt. Die Praktiken jedoch, die mit agilen Vorgehensmodellen verbunden sind und das agile Mind-Set prägen, scheinen noch nicht im täglichen Handeln und den Organisationsstrukturen flächendeckend verankert. Außerdem verlieren grundlegende Testkompetenzen, die eine systematische Vorgehensweise unterstützen, an Sichtbarkeit und einige Testverfahren sind häufig nicht einmal bekannt. Bis zum Vortrag werden weitere detaillierte Auswertungen durchgeführt, um die ersten Auffälligkeiten zu untermauern.

Optimieren Sie Ihren DevOps Value Stream, indem Sie Ihre bisherigen Investitionen in DevOps effizient nutzen. Ihre Daten werden konsolidiert, Engpässe dadurch identifiziert und Ihr Durchsatz wird verbessert.
 
HCL Accelerate ist ein Softwareprodukt zur Visualisierung, Orchestrierung und Optimierung Ihres kontinuierlichen Value Stream. Entwicklungsteams, Release-Manager und Transformationsverantwortliche verfügen jetzt über ein einziges Tool, mit dem sie Daten konsolidieren und Maßnahmen über viele agile, kontinuierliche Integrations- und kontinuierliche Bereitstellungssysteme hinweg vorantreiben können. HCL Accelerate wurde für Unternehmen entwickelt, die über die Automatisierung hinausgehen möchten, um den Kulturwandel voranzutreiben und die Vorteile ihrer Investitionen in die DevOps-Transformation voll auszuschöpfen. Visualisieren Sie den kompletten Value Stream, beispielsweise von eingehenden Service-Ticket über die Entwicklung eines Bugfix, den Test des neuen Codes bis hin zur Anwendung des Updates – und das mit Daten aus einer Vielzahl von Anwendungen, wie Jenkins, Jira, ServiceNow u.v.A.m.
 
Sehen Sie in der Demo, wie in HCL Accelerate alle Artefakte Ihres Value Streams in einer einzigartigen Sicht veranschaulicht werden und alle verknüpften Informationen & Daten zur Verfügung stehen.
Trends hinsichtlich aller Metriken, wie Zeit, Qualität, Security Scans etc. werden automatisch ermittelt und liefern Ihnen eine Visualisierung in Echtzeit.
Verbesserungsmaßnahmen werden dadurch zielgerichtet und können als Best Practice unternehmensweit genutzt werden.

Continuous Integration, Continuous Delivery, Continuous Deloyment, Testen im agilen Team, Unittest – überall begegnet man „dem Test”. Aber was heißt das eigentlich – „der Test”? Häufig fehlt die nötige Test-Expertise im Entwicklungsteam. Was tun? Eine wichtige Hilfestellung kann hier der an praktischen Codierungsaufgaben orientierte Kurs „Testing Foundations for Developers“ (A4Q-TF4D) schaffen. Das German Testing Board, das für den Certified Tester in Deutschland verantwortliche Mitgliedsboard des ISTQB® hat dieses Curriculum entwickelt und bringt dieses nun in Kooperation mit der Alliance for Qualification (A4Q) auf den Markt. Der „A4Q Testing Foundations For Developers“ (A4Q-TF4D) verknüpft in eleganter Weise das grundlegende Verständnis zu systematischer Testmethodik und Einbindung der Testaufgaben in die Projektarbeit mit praktischen (Codierungs-)Übungen zur konkreten Erstellung von Tests.
Erhardt Wunderlich und Armin Metzger geben einen kurzen Einblick und stehen anschließend für Fragen und Antworten zur Verfügung.

Testsuite Yoga - Software Tests zurück ins Gleichgewicht bringen

Nicht nur Menschen, auch Testsuiten geraten unter Stress. Dann sind sie fragil, langsam zu ändern und durchzuführen, oder kosten auf andere Art Nerven. Um Stress abzubauen hilft folgendes:

• Tägliche *A*temübungen mit *A*utomatischen Analysten, die Probleme in Testsuiten verhindern
• *M*editation über einfache *M*etriken zur Früherkennung von Stress in Testsuiten
• *P*ositionen in Form von *P*rozessen und Aktivitäten, um die Qualität von Tests von Anfang an in den Griff zu bekommen.

Dieser Vortrag berichtet von unseren Erfahrungen in über 60 Projekten: Wann helfen diese Techniken? Und was steht auf dem Pfad zum inneren Gleichgewicht im Weg?

Zielpublikum: Tester, Testmanager, Projektleiter
Vorraussetzungen: Jeder der schon einmal bei der Erstellung und Wartung von manuellen Testfällen beteiligt war kann diesem Vortrag folgen und wertvolle Informationen daraus beziehen.
Schwierigkeitsgrad: Advanced

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 Stress' 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?

Wusstet Ihr, dass das komplexeste Device der Welt ohne Gebrauchsanweisung ausgeliefert wird? Wir alle benutzen es Tag für Tag intuitiv, doch so bleibt häufig auch viel des mitgelieferten Potentials auf der Strecke. Wie dieses Device Daten verarbeitet und wie wir mit diesem Device eine Hochleistung bringen können, ist der Fokus dieses Vortrags. Die Neurowissenschaftlerin Dr. Karolien Notebaert vermittelt verblüffende Einsichten und zeigt auf, wie wir das eigene Gehirn hacken können – exploratives Testen garantiert!