Die im Konferenzprogramm des GTD digital 2021 angegebenen Uhrzeiten entsprechen der Central European Time (CET).
Per Klick auf "VORTRAG MERKEN" innerhalb der Vortragsbeschreibungen können Sie sich Ihren eigenen Zeitplan zusammenstellen. Sie können diesen über das Symbol in der rechten oberen Ecke jederzeit einsehen.
Gerne können Sie die Konferenzprogramm auch mit Ihren Kollegen und/oder über Social Media teilen.
Der Track+ besteht aus Präsentationen der Sponsoren und unterliegt somit nicht der Qualitätssicherung des Conference Boards.
Bitte beachten Sie, dass es für vereinzelte Workshops eine Teilnehmerbeschränkung gibt. Weitere Infos hierzu finden Sie in den Workshop-Beschreibungen.
Konferenzprogramm 2021
- Montag
03.05. - Dienstag
04.05.
As a tester, I don’t break your code, I break your *illusions* about the code. And illusions come in many forms. Illusions may be about the code doing what it’s supposed to; about the product doing what it would need to; about your process being able to deliver with change in mind; people having the skills to deliver well and about the business growing with uninformed risks on the product and the business model around it.
This talk goes through examples of illusions that need to be broken and skills that you need to build to break them. As a tester, you may have these skills but use them on a scale smaller than their potential. Testing is not just the technical checks but more relevantly it’s about discovering information about threats to value you’re trying to create.
We will address:
- Types of illusions with examples grounded in the speakers 25 years of hands-on experience as a tester
- How skills to breaking basic software illusions enable breaking software illusions on organizational scale
- Hierarchy of disillusionment: how building the right things precedes building things right
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.
„Wo ist unser Test geblieben?“ – Alle sprechen von Qualität, der Wichtigkeit der IT sowie Automatisierung. Ist Lean Quality Management die Antwort auf die Frage nach der Zukunft des Tests? Ja, auf jeden Fall! Die Arbeit in unseren Qualitätsdepartments hat sich in den letzten Jahren und Jahrzehnten stetig weiterentwickelt und steht nun davor, wieder eine neue Schwelle zu erreichen.
Wir möchten Ihnen in diesem Vortrag einen Überblick und Einblicke in die zukünftigen Werkzeuge, Herausforderungen und Methoden des Testens geben. In diesem Zusammenhang fällt immer wieder der Begriff „Lean Quality Management“. In unseren Augen ist Lean Quality Management der „Hidden Champion“ – der „verborgene/unsichtbare Champion“ auf dem Weg zum Idealzustand der Qualitätssicherung und der Enabler für „Business Agility”, „Organisational Agility“ und „Enterprise Agility“.
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
<provokative Statements>Im regulierten Umfeld sind die Anforderungen an Test- und Qualitätssicherung so hoch, dass man dies nicht mit explorativen Testmethoden lösen kann.</provokative Statements><Lösungsansatz>Unser Ansatz: Sessionbasiertes Testmanagement. Anhand unserer bisherigen Erfahrungen zeigen wir auf, wie man explorative Testmethoden auch im regulierten Umfeld einsetzen kann. Gemeinsam tauchen wir in unser Projektvorgehen ab und zeigen klassische Stolpersteine auf.</Lösungsansatz>
Target Audience: Tester, Testmanager, Product Owner, Scrum Master, Stakeholder, Fachbereich
Prerequisites: Grundlegende Kenntnisse im Testing. Einordnung explorativer Testmethode
Level: Grundlegend / Basic
Extended Abstract:
Wir Beide beschäftigen uns seit langer Zeit mit kollaborativen und explorativen Testmethoden. Da wir nun beide für die Carl Zeiss Digital Innovation GmbH tätig sind, kamen wir natürlich auch direkt im regulierten Umfeld (Medizintechnik) an. Da wir auch hier gerne unsere positiven Erfahrungen mit explorativen Testen einbringen wollten, war der kundenseitige Widerstand sehr groß. Exploratives Testen ist im regulierten Umfeld nicht möglich, zu hoch sind die Anforderungen an Test- und Qualitätssicherung. Dieser Widerstand war unsere Motivation uns genauer mit dem Thema auseinander zu setzen und einen Lösungsansatz zu erarbeiten, wie man auch im regulierten Umfeld explorativ testen kann. Gerne möchten wir unsere Erfahrungen auch an andere Leidensgenossen weitergeben und vielleicht können wir auch den ein oder anderen Weg etwas ebnen.
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.
Vortrag Teilen
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.
Vortrag Teilen
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
In diesen Rollen unterstützt sie Kollegen, Kunden und Teams auf ihrer Reise, bessere Qualität zu liefern: in Produkten, in Prozessen und in der Kommunikation.
In früheren Rollen war sie für die Befähigung von Teams und qualitativ hochwertige Systeme verantwortlich. Nun befähigt sie andere, genau das zu machen, und sorgt für eine Umgebung in der Firma, wo jede(r) aufblühen kann.
Alex schaut mit neugierigen Tester-Augen auf die Welt und möchte immer dazu lernen. Sie teilt ihr Wissen und ihre Erfahrungen in Workshops, Coachings und als Sprecherin oder Keynote-Sprecherin auf Konferenzen.
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)
Vortrag Teilen
Lean Coffee ist ein strukturiertes agenda-loses Meeting-Format, bei dem die Teilnehmer:innen die Tagesordnung durch die Themen, die sie einbringen, selbst bestimmen. Um möglichst viele Themen zu besprechen, wird die Länge der Diskussion pro Thema durch eine Zeitbegrenzung limitiert.
Treten Sie in den Austausch mit Gleichgesinnten und diskutieren die aktuellen Themen rund um das Thema "Testen".
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.
Vortrag Teilen
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.
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.
Viele Teams müssen immer mehr Funktionalität in immer weniger Zeit testen. Historisch gewachsene Test-Suites stoßen dabei oft an ihre Grenzen, da sie gleichzeitig Zuviel und Zuwenig testen. Zuviel, da sie Tests enthalten, die Kosten erzeugen, aber kaum Mehrwert gegenüber ähnlichen Tests bieten. Zuwenig, da trotzdem wichtige Funktionalität ungetestet bleibt.
Im Vortrag stelle ich Analysetechniken vor, um diese Probleme im eigenen System aufzuzeigen. Historienanalyse des Versionskontrollsystems zeigt, wo in der Vergangenheit im System am meisten Fehler aufgetreten sind. Test-Gap-Analyse deckt auf, welche Code-Änderungen noch ungetestet sind. Und Pareto-Test-Analysen identifizieren die Tests, die das schlechteste Kosten-Nutzen-Verhältnis haben. Ich zeige für jede Analyse die zugrundeliegenden Konzepte und unsere Erfahrungen im Einsatz in der Praxis.
Der Vortrag fasst dabei mehrere Vorträge zusammen, die in den letzten Jahren dem German Testing Day, den Software Quality Days und dem QS-Tag mit Best Presentation Awards ausgezeichnet wurden. Anders als diese Einzelvorträge stellt er aber keine neuen Analysen oder neue Forschungsarbeiten vor, sondern gibt einen konsolidierten Überblick für diejenigen, die sich für das Thema Test Intelligence neu interessieren.
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
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.
Raiffeisen Bank International (RBI) started in 2017 with “Group Digital Solutions” a journey in order not to oversleep the digitization of the banking industry.
Due to new approaches such as DevSecOps & Continuous Testing, the topic of software tests, whether manual or automated, had to be completely redesigned and implemented.
This talk gives insights into the test strategy & the fullstack test automation architecture that were used.
Target audience: testers, developers, architects, managers
Prerequisites: none
Level: Advanced
Extended Abstract:
So that Raiffeisen Bank International can keep up with digitization in the banking sector, the company relies on the use of native apps, microservices and REST APIs in the Amazon cloud when implementing its mobile banking strategy.
In order to support the DevOps mantra "Automate everything", a full stack test automation strategy was developed that is based on open source tools and takes all components of the system architecture into account.
The independent services of the microservice architecture make additional interfaces visible that are not available in a monolithic architecture. The advantage is that they can be deployed and tested independently of each other.
Testing these systems is much more complex than testing a conventional monolithic application and needs additional demands on test automation, with classic integration tests being even more important for the overall structure.
These integration tests were usefully supplemented by consumer contract tests. But end-2-end tests should not be missing either, since an effective test strategy must take into account both the isolated testing of individual services and the verification of the overall system behavior.
Aligning test automation with the classic test pyramid is a very useful approach if the individual layers are seen as the basis for “what is being tested” and not as a measure of the number of tests. Because the old wisdom still counts: “Quality over quantity!”.
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?
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.
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!
