Self-Healing Tests ist ein Ansatz, bei dem maschinelles Lernen bei der Wartung von automatisierten Tests hilft.

Self-Healing, die Automation der Testautomation, erkennt Änderungen im 'System under Test' und passt die Testdurchführung automatisch an, damit die Tests funktionsfähig bleiben. Kommerzielle Tools, wie TestIM und Tricentis Neo Engine, sind vielversprechend und rechtzeitig auf den Zug aufgesprungen. Es gibt aber auch vielversprechende Open-Source Alternativen, wie Healenium.

Dieser Vortrag erklärt die Pro & Cons von Self-Healing Tests und zeigt anhand eines konkreten Beispiels, die Umsetzung mit der Open-Source Bibliothek Healenium.

Zielpublikum: Tester, Test Automation Engineers, Test Manager, Developer, DevOps Engineers
Vorraussetzungen: keine
Schwierigkeitsgrad: Advanced

Extended Abstract:
Eine der wichtigsten und aufwändigsten Tätigkeiten in der Testautomation, ist die Wartung von Testscripts. Keine anderen Testartefakte beanspruchen so viel wertvolle Zeit und Mühe in der Pflege, wie die zu Code gewordenen Testfälle.

Nun stellt sich die Frage ob es einen Ansatz gibt, in dem sich künstliche Intelligenz gepaart mit Machine Learning, um die Wartung der Testscripts kümmern kann. Die Entwickler der Testscripts hätten so mehr Zeit, sich um die Automation neuer Tests zu kümmern und damit die Testabdeckung durch Testautomation zu erhöhen. Die Antwort auf die Frage lautet: 'Ja, es gibt eine Lösung: Self-Healing Tests'.

Auf den Punkt gebracht ist Self-Healing die Automation der Testautomation. Testwerkzeuge mit Self-Healing Eigenschaften, erkennen Änderungen in der grafischen Benutzeroberfläche und passen die automatisierten Testfälle automatisch an, damit die Tests funktionsfähig bleiben. Kommerzielle Tools wie TestIM , Mabl  & Tricentis Neo-Engine  sind vielversprechend und rechtzeitig auf den Zug aufgesprungen. Es gibt aber auch vielversprechende Open-Source Alternativen wie Healenium.

Der Vortrag erklärt die Grundlagen von Self-Healing Tests und zeigt anhand eines Beispiels die Umsetzung mit der Open-Source Bibliothek Healenium.

Test automation, continuous integration, pipelines... the need for speed increased exponentially over the last decade.

Applying Darwin's theory, it is quite simple: only the fittest -in this case the fastest- will survive. Traditional, manual testers are like a rhinoceros... in danger of extinction.

But even those fast rages have their shortcomings, like the automation fake news or automation paradox. In this presentation, Wim explains why 'slow' testing is still there and which survival techniques (like Transform to a no-sheep tester, Think glocally) you need as a manual tester to secure your position for the future.

Target Audience: Testers, test managers, technical testers (test automators), stakeholders involved in testing
Prerequisites: None
Level: Basic

Extended Abstract:
The world of testing has evolved a lot over the last decade. Manual testing is under pressure by a lot of fast rages like test automation, CI/CD, pipelines, ... And so one can wonder if traditional manual testers still have their place and will remain relevant within the future.

But those fast rages are not always 'hallelujah'. And that is for me one of the main arguments why manual testing will always remain relevant.

Especially when we look to test automation, it is a fact that this is not always successful. To my opinion, this is due to 3 main reasons: automation fake news, automation blindness and automation paradox. Automation fake news is about the promises -made by tool vendors, test automators to customers, management- but aren't always fully realised in practice. Some examples : unattended testing, one-click automation. Automation blindness is about the tunnel vision test automators have by ignoring questions like 'Which data combinations are relevant to automate? Do we really need to execute all data combinations?'. Furthermore, test reports are not always analysed in depth. Why do we get a fail? Is this an application failure or a failure introduced due to our own automation code?

Another argument for the relevancy of manual testing is the increased complexity of things. This makes it in some cases even not possible or not efficient to automate things (e.g. how do test an airplane?).

But... manual testing has evolved and needs to be adapted to this changing world. For manual testers, this require other or adapted skills.

I see 4 main skills we should have:

- Transform to no-sheep tester

  = stop with complaining like bleating sheeps that we don't have proper, complete requirements or builds are not stable. Instead use those situations by showing your added value as manual tester by applying techniques like exploratory testing, sanity & smoke testing.

- Get a fika

= It is a Swedish tradition to build in fixed moments in the morning and afternoon to drop your work and socialize with colleagues to talk about everything else than work. Manual testers should participate in such fika's because you get indirectly a lot of crucial information that can help you further.

- CRUD the crap

= Just like the English slang expression 'Cut the crap', testers should provide info to the business in a no-nonsense way. No bullshitting and especially no overwhelming the stakeholders by figures. At the end, stakeholders are mainly interested in the fact if the application/software meet the requirements of a C(reate), R(ead), U(pdate), D(elete) test.

- Think glocally (and no, this is not a typo :-)

Manual testers have to oversee the complete picture in complex architecture. Especially with regards to preparation of test data for E2E tests, time travels. In this area they can show off their added value.

Conclusion: survival of the fittest is not about the fastest, but about the smartest both for test automation and manual testing.

Warum ist es so wichtig das der Test schon bei der Bearbeitung von Angeboten beteiligt ist ?

In diesem Vortrag soll dargestellt werden wie ein Angebotsprozess aussehen sollte. Leider haben wir manchmal folgende Situation  - Telefonanruf: 'morgen müssen wir dem Kunden unser Angebot für ein neues Projekt übergeben. '

Schon in der Angebotsphase müssen viele Fragen beantwortet werden die grossen Anteil an den Gesamtkosten des neuen Projektes haben werden:

Wie soll das angebotene Produkt qualifiziert werden ?

Welche Testverfahren können wir wiederverwenden ?

Was muss alles getestet werden ?

Was ist dem Kunden wichtig ?

Zielpublikum: Projektleiter, Testmanager, Entscheider,Tester
Vorraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Basic

Extended Abstract:
Bei der Ausarbeitung von Angeboten wurde in der Vergangenheit meistens nur die Entwicklungsabteilung gebeten entsprechende Aufwandsabschätzungen zu erstellen.

Testaufwände wurden aus vergangenen Projekten übernommen.

Dies führte jedoch bei einigen Projekten dazu das, z. B. aufgrund von geänderten Hardwarebausteinen, die Aufwände unterschätzt wurden.

Aus diesem Grunde wurde die frühzeitige Einbeziehung des Testintegrationsmanagements (TIM) beschlossen, d.h. die TIMs erhalten die Angebotsanfrage zur gleichen Zeit wie die Entwicklungsabteilung. Die TIMs stimmen sich mit den Seniortestern des entsprechenden Aufgabengebietes ab um realistische Aufwandsabschätzungen erstellen zu können.

Bei der Analyse der Angebote ist es auch wichtig Daten aus vergangenen Projekten zu haben, d.h. die Tester dokumentieren ihre Testaufwände in einer Testdatenbank.

Zusätzlich wurden nach Projektabschluss von den TIMs Budgetanalysen erstellt um zu erkennen ob, und wenn ja warum, bestimmte Testaufwände unterschätzt wurden.

Wichtig ist hier auch ein 'lessons learned'-Prozess (auch in der Testabteilung mit der Beteiligung des gesamten Testteams), durch den der Angebotsprozess verbessert werden kann.

Es zeigte sich das auch Aufwände für die Angebotserstellung eingeplant werden müssen. Ca. 10% der monatlichen Arbeitszeit ist für die Testabteilung zur Bearbeitung von Angeboten eingeplant.

You're tasked to work on an existing test automation suite, and you note usual problems:

• Slows down the development process
• Test addition is an afterthought in the dev cycle
• Doesn't point to the problem area in code on failure
• Doesn't actually give you regression confidence
• Rely on just one person to fix or run it (you!)
• Tests get or 'are tagged to be' ignored

You need help. And the help you need is not creating a new framework, but rather learning to tidy it up so that instead of problems, your tests spark joy.

In this talk, we learn to implement rules/techniques to achieve test atomicity, efficient DOM structure naming for tests, tagging XHR calls, the folder structure for better readability and 'what tests to keep' rather than decide 'what tests to discard' to keep your suite clean, lean and mean. You'll learn that your tests, like mine, can spark joy.

Target Audience: Developers and test engineers who want to develop or improve their test automation code
Prerequisites: some background in software development processes and basic tools such as version control systems, IDEs, etc. as well as  an understanding of some automation technology, for example, selenium, RPA or cypress and how they work
Level: Advanced

Im Jahr 2017 hat das German Testing Board (GTB) die Broschüre 'Berufsbild Tester' veröffentlicht, welche dem Leser Ideen und Struktur anbietet, in dem anhand von Testaufgaben und Spezialisierungen im Test ein Modell von Rollen mit zugehörigen Kompetenzanforderungen festgelegt wird.

Das Arbeiten in agilen Organisationen, in agilen Projekten und in selbstorganisierten, multidisziplinären Teams und die Idee der Verantwortung des gesamten Teams für Qualität machen es wert, ein eigenes Berufsbild 'Agiler Tester' zu skizzieren.

• Testen im agilen Kontext
• Ausprägungen von agilen Rollen im Test
• Testkompetenzen machen agiles Arbeiten möglich

Zielpublikum: Entwickler, Tester, Spezialisten, Fachbereiche, Führungskräfte
Vorraussetzungen: klassische und agile Projekterfahrung
Schwierigkeitsgrad: Basic

Back in 2016, I heard about this strange new approach of ensemble programming, having the whole team work on the same task, same place, same time, same computer - which was such an unusual idea that it instantly fascinated me. I told my team about it; they surprisingly agreed to give it a try; and it changed our world.

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

Extended Abstract: 

Back in time, I started out as a strong individual contributor. I loved to have a team around me and collaborate with them, but when it came to doing “my part”, I did it only by myself. I was uncomfortable when another one “peeked over my shoulder” to see what I was doing, or when they even wanted to do it together with me.

But then I heard about this strange new approach of ensemble programming, having the whole team work on the same task, same place, same time, same computer - which was such an unusual idea that it instantly fascinated me. I told my team about it; they surprisingly agreed to give it a try; and it changed our world. 

Join us on our journey and see what we discovered along the way. Learn how our ensembling experience helped us to start pairing, on various tasks across “disciplines”. This is our story of how the whole team is growing even closer together, constantly learning from each other, while delivering our best.

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.

We will show and explain how we enabled and supported global transparency on our defined KPIs within the DevOps process in Siemens MindSphere.

Continuous Transparency is targeting all KPIs starting in Portfolio Management, through Scoping, Implementation, Release and Deployment up to Operation and is continuously feeding back information to interested parties.

Besides the technical and business relevance, our key findings were:

The most important benefit of Continuous Transparency is building trust. Not only in your product or solution but also between loosely coupled units that share a common goal and even extending to customers.

Target Audience: Project Manager, R&D, Architects, Operation, Security Experts and Quality Experts.
Prerequisites: Understanding of Cloud, CI/CD and DevOps.
Level: Advanced

Extended Abstract:
We will show and explain how we enabled and supported global transparency on our defined KPIs within the DevOps process in Siemens MindSphere.

Continuous Transparency is targeting all KPIs starting in Portfolio Management, through Scoping, Implementation, Release and Deployment up to Operation and is continuously feeding back information to interested parties.

Besides the technical and business relevance, our key findings were:

The most important benefit of Continuous Transparency is building trust. Not only in your product or solution but also between loosely coupled units that share a common goal and even extending to customers.

We will share our experience on functional and non-functional as well as release and deployment transparency. Additionally, we will give insights into special cases of operational transparency with focus on live data and postmortem analysis. Beyond that, the session will include an overview on recommendations for governance methodologies.

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

Wenn ein System wächst, wird auch die Anzahl der automatisierten Tests größer. Wir sehen in der Praxis zunehmend öfter Test-Suiten, die mehrere Stunden bis Tage laufen.

Das erschwert die Untersuchung von Testfehlschlägen und mindert den Wert der Tests.

Wenn die Ausführung aller Tests zu lange dauert, kann man einen Teil der Tests häufiger auszufü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 beleuchten wir verschiedene Ansätze hinsichtlich Kosten, Nutzen und Anwendbarkeit.

Wir stellen Erfahrungen aus der Forschung und dem Praxiseinsatz vor.

Zielpublikum: Tester, Entwickler, Testmanager
Vorraussetzungen: Interesse an Software Tests und Optimierung von Test Verfahren.
Schwierigkeitsgrad: Advanced

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 Probleme mit sich. Für die Entwickler bedeutet es, dass sie Feedback für den geänderten Code erst eine Lange Zeit nach dem sie die Änderungen gemacht haben, bekommen. Das macht es deutlich schwieriger, die gefundenen Fehler zu finden und beheben. Außerdem werden moderne verfahren, wie zum Beispiel Continuos 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 Qualität der Test Suite 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, wie per Test Coverage [1] und Ausführungszeit, verwendet, 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 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, <https://cqse.eu/test-impact-analyse-objektspektrum>

[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)