Konferenzprogramm

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

Track: Vortrag

Nach Tracks filtern
Nach Themen filtern
Alle ausklappen
  • Montag
    03.05.
  • Dienstag
    04.05.
, (Montag, 03.Mai 2021)
10:35 - 11:10
Mo 1.1
Self-Healing Tests / Der heilige Gral der Testautomation ... oder doch nur viel Lärm um Nichts?
Self-Healing Tests / Der heilige Gral der Testautomation ... oder doch nur viel Lärm um Nichts?

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.

Matthias Zax works as an agile engineering coach at Raiffeisen Bank International AG (RBI). Actually a trained software developer, he has been testing software with a focus on test automation in the DevOps environment since 2018 and organizes the RBI Test Automation Community of Practice. ------------------ Matthias Zax arbeitet als Agile Engineering Coach bei Raiffeisen Bank International AG (RBI). Eigentlich gelernter Software Developer, beschäftigt er sich seit 2018 mit dem Testen von Software mit Schwerpunkt Testautomation im DevOps-Umfeld und organisiert die RBI Testautomation Community of Practice.
Matthias Zax
Matthias Zax
Track: Vortrag
Vortrag: Mo 1.1

Vortrag Teilen

10:35 - 11:10
Mo 2.1
Is survival of the fittest only for the fastest?
Is survival of the fittest only for the fastest?

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.

For more than 22 years, Wim Demey has been active in software testing and has evolved to a generalist covering different aspects and roles within testing. Driven by versatility and a great eagerness to learn new things, Wim is always looking how and where he can stretch his comfort zone to manage new challenges. He has a special interest in more technical topics like performance testing, test management tools and AI.
Wim Demey
Wim Demey
Track: Vortrag
Vortrag: Mo 2.1

Vortrag Teilen

11:25 - 12:00
Mo 1.2
Angebotsphase und Testen - das gehört zusammen!
Angebotsphase und Testen - das gehört zusammen!

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.

Dr. Erhardt Wunderlich arbeitet bei Alstom im Center of Expertise an dem Thema Tools and Processes. Dr. Wunderlich hat über 30 Jahre Erfahrung in Software-Entwicklung und -test in verschiedenen Branchen.
Erhardt Wunderlich
Erhardt Wunderlich
Track: Vortrag
Vortrag: Mo 1.2

Vortrag Teilen

11:25 - 12:00
Mo 2.2
Tests that Spark Joy!
Tests that Spark Joy!

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

Divya Rakhiani has more than 8 years of experience in Quality Assurance working in a startup like Beanworks, Service companies like Infosys and Thoughtworks, and Product companies like Dell EMC. She currently heads the Quality Engineering department at a startup called Beanworks that specializes in automating the tedious and paper-heavy accounting process. It's rated the 13th best startup in the Vancouver tech market. Divya sees herself today as a new immigrant to Canada and is building her career helping QA teams to use technologies like UI automation using cypress/selenium, visual testing and CI/CD for each code deployment.
She is passionate about preaching quality as a mindset in the software development cycle and not a stage. She was an active member of the Vodqa meetup group at Thoughtworks, India and has spoken at various meetups in Delhi, India about Testing in Micro-services, contract testing, test pyramid, service virtualization, and automation best practices. When not working, Divya likes to lift weights at the gym! #girlswhocodeandlift. Most of her weekends are spent --running at the beautiful Stanley Park, walking the dog or meal prepping and daydreaming about all the shoes she can buy ;)
Divya Rakhiani
Divya Rakhiani
Track: Vortrag
Vortrag: Mo 2.2

Vortrag Teilen

13:20 - 13:55
Mo 1.3
Agiler Tester - Ein neues Berufsbild?
Agiler Tester - Ein neues Berufsbild?

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

Elke Mai ist Enabler und Unterstützer für Fachbereiche und IT-Abteilungen im Testmanagement. Sie blickt zurück auf jahrzehntelange Erfahrung in Umsetzungsprojekten in den drei deutschen Banksektoren. Durch die Mitarbeit im GTB kann sie Impulse setzen. Als Teilnehmerin von Seminaren und Konferenzen sucht sie aktiv den Austausch zum Thema Softwarequalität und Softwaretest. Für sie ist der Testprozess ein lebendiger Prozess, der von der Zusammenarbeit der Beteiligten lebt.
Elke Mai
Elke Mai
Track: Vortrag
Vortrag: Mo 1.3

Vortrag Teilen

13:20 - 13:55
Mo 2.3
A Story of Ensemble Programming, Testing and Everything
A Story of Ensemble Programming, Testing and Everything

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.

Having graduated in sinology, Lisi fell into agile and testing in 2009 and has been infected with the agile bug ever since. She's especially passionate about the whole-team approach to testing and quality as well as the continuous learning mindset behind it. Building great products which deliver value together with great people is what motivates her and keeps her going. She received a lot from the community; now she's giving back by sharing her stories and experience. She tweets as @lisihocke and blogs at www.lisihocke.com. In her free time you can either find her in the gym running after a volleyball, having a good time with her friends or delving into games and stories of any kind.
Elisabeth Hocke
Elisabeth Hocke
Track: Vortrag
Vortrag: Mo 2.3
Themen: Team Work

Vortrag Teilen

14:10 - 14:45
Mo 1.4
Professionell Scheitern in 7 Schritten: So ruinieren sie ihre API durch falsches Testen!
Professionell Scheitern in 7 Schritten: So ruinieren sie ihre API durch falsches Testen!

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.

Frank Scheffler ist Senior Solution Architect und Mitbegründer bei Digital Frontiers. Er verfügt über langjährige Erfahrung als Berater und Coach in den Themen Microservices, Software Quality und agile Transformation.
Florian Pfleiderer beschäftigt sich als Senior Consultant bei Digital Frontiers mit agiler Software-Entwicklung. Seine Kunden berät er in den Bereichen Architektur, Microservices und Craftmanship.
Frank Scheffler, Florian Pfleiderer
Frank Scheffler, Florian Pfleiderer
Track: Vortrag
Vortrag: Mo 1.4
Themen: API Testing

Vortrag Teilen

14:10 - 14:45
Mo 2.4
Experience Report on Continuous Transparency in Siemens MindSphere
Experience Report on Continuous Transparency in Siemens MindSphere

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.

As portfolio manager he aims to enable Siemens companies for their digitalization transformation by conducting applied research, consulting and operational lead, while envisioning the strategic roadmap for related research questions.
As Lead Test Architect in Siemens MindSphere he was responsible for Test Architecture and Infrastructure, leading related international distributed teams and closely collaborating with R&D, QV, Architecture, Security and Operations Management.
Principal Software Architect for Siemens MindSphere focussing on cloud operations. Facilitating large scale secure designs and analytics to power the use cases of tomorrow.
Florian Krautwurm, Tobias Appl
Florian Krautwurm, Tobias Appl
Track: Vortrag
Vortrag: Mo 2.4

Vortrag Teilen

15:15 - 15:50
Mo 1.5
Geht's auch kleiner? Mikroheuristiken im explorativen Testen
Geht's auch kleiner? Mikroheuristiken im explorativen Testen

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

Alex Schladebeck ist eine Testerin aus Leidenschaft. Ihr Herz schlägt für Qualität, Agilität und ihre Mitmenschen. Sie ist Geschäftsführerin und Leiterin der Qualitätssicherung bei der Bredex GmbH.

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.
Alex Schladebeck
Alex Schladebeck
Track: Vortrag
Vortrag: Mo 1.5

Vortrag Teilen

15:15 - 15:50
Mo 2.5
80/20-Optimierung von Test-Suites: Erfahrungen aus Forschung & Praxis
80/20-Optimierung von Test-Suites: Erfahrungen aus Forschung & Praxis

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)

Raphael Noemmer hat seinen Informatik-Master an der TU München mit einem Fokus auf Software-Engineering und Software-Qualität abgeschlossen. Seine Masterarbeit behandelt das Thema Test-Minimierung.
Dr. Elmar Juergens hat über statische Codeanalyse promoviert und für seine Doktorarbeit den Software-Engineering-Preis der Ernst Denert-Stiftung erhalten.
Raphael Noemmer, Elmar Juergens
Raphael Noemmer, Elmar Juergens
Track: Vortrag
Vortrag: Mo 2.5

Vortrag Teilen

, (Dienstag, 04.Mai 2021)
09:00 - 09:15
Eröffnung
Eröffnung
Eröffnung

Track: Vortrag
Vortrag: Eröffnung

Vortrag Teilen

09:20 - 09:55
Di 1.1
Behavior dropped development - Wie BDD zum Selbstzweck verkommt und dem Team im Weg steht
Behavior dropped development - Wie BDD zum Selbstzweck verkommt und dem Team im Weg steht

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.

Als Trainer und Berater liegen meine Schwerpunkte im Bereich der Qualitätssicherung und Softwaretests.
Über zehn Jahre habe ich in verschiedenen Rollen - vom manuellen Tester in der vergleichenden Warenprüfung  über Testmanager im Automobilsektor bis zum Abteilungsleiter Test für ERP-Software - dazu beigetragen, dass die Kunden die Qualität bekommen, die sie benötigen. Meine Themenschwerpunkte liegen im Bereich des agilen Testens, des explorativen Testens und dem Verankern von Qualitätsbewusstsein im gesamten Softwareentwicklungsprozess.
Auch privat lassen mich die Rollen Trainer und Coach seit über 20 Jahren nicht los, wenngleich es dann nicht um Softwaretests, sondern um Basketball geht.
Christian Kram
Christian Kram
Track: Vortrag
Vortrag: Di 1.1

Vortrag Teilen

09:20 - 09:55
Di 2.1
Lost in Permissions
Lost in Permissions

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.

Yana Shapka is a QA Engineer from Kyiv, Ukraine. A mentor in Women Who Code Kyiv nonprofit organization, helping bridge the gender gap in the tech industry in Ukraine. A mentor in BeQA Today non-profit organization, helping people with disabilities to start their careers in software testing. Gave a speech 'The Truth About Localization Testing' at Moldova Software Testing & Automation Conference in November 2019. Gave a speech 'Being a mediator in a distributed multicultural team' at Hungarian Software Testing Forum in November 2020. Can speak Japanese. Traveled to 25 countries.
Yana Shapka
Yana Shapka
Track: Vortrag
Vortrag: Di 2.1

Vortrag Teilen

10:10 - 10:45
Di 1.2
Let's play! Gamification in der Qualitätssicherung
Let's play! Gamification in der Qualitätssicherung

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.

Dehla Sokenou fühlt sich in allen Phasen der Software-Entwicklung zu Hause, besonders im Testen. Bei WPS - Workplace Solutions ist sie als Test- und Qualitätsmanagerin und Software-Architektin tätig.
Baris Güldali begleitet als Agile Coach und Quality Coach agile Teams und unterstützt diese bei der Erreichung ihrer Sprintziele. Er organisiert Community-Events mit Schwerpunkt Agilität und Qualität.
Dehla Sokenou, Baris Güldali
Dehla Sokenou, Baris Güldali
Track: Vortrag
Vortrag: Di 1.2
Themen: Gamification

Vortrag Teilen

10:10 - 10:45
Di 2.2
Working Effectively Agile in a Large Enterprise - A Testers Perspective
Working Effectively Agile in a Large Enterprise - A Testers Perspective

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.

Dr. Stephan Schulz is a Test Architect at Giesecke + Devrient Currency Technology. For the past 20 years he has been researching, educating, consulting, and authoring numerous publications and standards on testing and model based testing. In addition, he has served for many years as chair of the ETSI TC MTS."
Stephan Schulz
Stephan Schulz
Track: Vortrag
Vortrag: Di 2.2

Vortrag Teilen

11:15 - 11:50
Di 1.3
Automatisierte E2E-Tests von Microservices
Automatisierte E2E-Tests von Microservices

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.

Lukas Pradel arbeitet als Senior Consultant bei der Conciso GmbH. Die Zeit, die er mit der Automatisierung von Tests einspart, nutzt er am liebsten zum Motorradfahren.
Lukas Pradel
Lukas Pradel
Track: Vortrag
Vortrag: Di 1.3
Themen: Microservices

Vortrag Teilen

11:15 - 11:50
Di 2.3
Customer Experience - Schluss mit Rätselraten
Customer Experience - Schluss mit Rätselraten

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
Georg Hansbauer ist Mitgründer und Managing Director des Softwaretesting-Spezialisten Testbirds. Er verantwortet die Weiterentwicklung der Dienstleistungen und der IT-Infrastruktur. Georg verfügt über umfassende Erfahrung im Feld des Enterprise Testing – von automatisierten Tests kompletter IT-Service-Desks bis hin zu Lasttests – und hat zahlreiche IT-Projekte für internationale Konzerne betreut. Er absolvierte den Elitestudiengang „Finanz- und Informationsmanagement“ an der Universität Augsburg und der TU München und besitzt einen Bachelor in Wirtschaftsinformatik
Georg Hansbauer
Georg Hansbauer
Track: Vortrag
Vortrag: Di 2.3
Themen: Crowd Testing

Vortrag Teilen

12:05 - 12:40
Di 1.4
AI4T - A big step towards a fully automated test life cycle
AI4T - A big step towards a fully automated test life cycle

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.

Herr Nößner ist Experte in Machine Learning und Künstliche Intelligenz. Er hat seinen PhD an dem größten Deutschen Institut für Data und Web Science in Mannheim in den Bereichen Machine Learning und Datenintegration absolviert. In seiner frühen Karriere hat er Erfahrungen in Produktionsbetrieben wie dem mittelständigen Unternehmen Fischer GmbH in Sinsheim (Werkzeugbau, Kunststoffteile, und Systembausteine) und Daimler Trucks in Wörth gesammelt. Anschließend hat er als IT Consultant die Kundenkommunikation für ein großes Kundenprojekt bei Capgemini für Daimler maßgeblich gestaltet. In den letzten 5 Jahren war er in Australien als Spezialist für Machine Learning und AI bei verschiedenen Mining Software Firmen beschäftigt (Dassault Systems GEOVIA und Deswik) und hat an Projekten zur Verwirklichung der Vision der vollautomatischen Mine mitgewirkt. 
Nun hat er bei Nagarro begonnen und möchte die Faszination von Machine Learning in Österreich weiter entfachen und gleichzeitig Machine Learning ,demystifizieren'.
Thomas Steirer ist ein Testautomatisierungsarchitekt aus Wien, und bringt mehr als 15 Jahren Erfahrung mit. Er hat zahlreiche Automatisierungsframeworks und 
-lösungen in verschiedenen Branchen und Technologien entwickelt. Sein Schwerpunkt liegt auf dem Aufbau skalierbarer und nachhaltiger Lösungen, die primär darauf ausgelegt sind wertvolle Informationen zu liefern. In seiner Tätigkeit bei Nagarro begleitet er Kunden bei der Einführung und Optimierung von Testautomatisierung und unterrichtet an Hochschulen in Österreich. In seiner Freizeit ist er ein Tech-Junkie, Tüftler und begeisterter Gameboy-Musiker.
Jan Nößner, Thomas Steirer
Jan Nößner, Thomas Steirer
Track: Vortrag
Vortrag: Di 1.4

Vortrag Teilen

12:05 - 12:40
Di 2.4
Grundlegende Testkompetenzen - Wohin geht die Reise?
Grundlegende Testkompetenzen - Wohin geht die Reise?

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.

Karin Vosseberg ist Professorin an der Hochschule Bremerhaven im Bereich IT- Systemintegration mit dem Fokus auf Qualität in der Softwareentwicklung. Seit 2015 ist sie als Konrektorin für Studium und Lehre in der Hochschulleitung. Sie ist Mitglied im ASQF-Präsidium, Wissenschaftspartnerin der Softwareforen, Leipzig und in diversen Programmkomitees für Konferenzen und Workshops.
Prof. Dr. Karin Vosseberg
Prof. Dr. Karin Vosseberg
Track: Vortrag
Vortrag: Di 2.4
Themen: Research

Vortrag Teilen

14:00 - 14:35
Di 1.5
Test Automation in the age of digital banking Darwinism
Test Automation in the age of digital banking Darwinism

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!”.

Rudolf Grötz has been in IT for 30 years and has been a passionate software tester since 2008. He works as an agile engineering coach for the topic & test automation at Raiffeisen Bank International in Vienna and lives the motto "Test automation is not an act, test automation is a habit!". In addition to various author activities, including for IX-Magazin, he organizes the Agile (Test) Automation Meetup in Vienna and the TestBustersNight Vienna 6 times a year. ------------------ Rudolf Grötz ist seit 30 Jahren in der IT unterwegs und seit 2008 passionierter Softwaretester. Er ist als Agile Engineering Coach für das Thema & Test Automation bei der Raiffeisen Bank International in Wien tätig und lebt den Leitspruch „Testautomation is not an act, Testautomation is a habit!“. Neben diverser Autorentätigkeiten, u.a. für das IX-Magazin, organisiert er in Wien das Agile (Test) Automation Meetup und 6x pro Jahr die TestBustersNight Vienna.
Rudolf Grötz
Rudolf Grötz
Track: Vortrag
Vortrag: Di 1.5

Vortrag Teilen

14:00 - 14:35
Di 2.5
Testsuite Yoga - Software Tests zurück ins Gleichgewicht bringen
Testsuite Yoga - Software Tests zurück ins Gleichgewicht bringen

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?

Dr. Henning Femmer ist einer der Gründer von Qualicen. Bei Qualicen hilft Henning unterschiedlichsten Firmen bei der Einführung von Text-Analytics-Ansätzen. Er hat im Bereich Software Engineering an der Technischen Universität München promoviert und ist unter anderem im Steering Committee des Artificial Intelligence for Requirements Engineering Workshops tätig. Henning ist häufig Speaker auf nationalen und internationalen Konferenzen.
Henning Femmer
Henning Femmer
Track: Vortrag
Vortrag: Di 2.5

Vortrag Teilen

Zurück