Konferenzprogramm

 

 

 

Das gesamte Konferenzprogramm auf einem Blick? Kein Problem, alle Programminhalte finden Sie hier jetzt auch als praktische PDF-Broschüre ganz bequem zum durchscrollen, downloaden oder ausdrucken:

Zur PDF-Broschüre

 

 

Thema: Testing & Quality

Nach Tracks filtern
Nach Themen filtern
Alle ausklappen
  • Montag
    06.02.
  • Dienstag
    07.02.
  • Mittwoch
    08.02.
  • Donnerstag
    09.02.
, (Montag, 06.Februar 2023)
10:00 - 13:00
Mo 8
Limitiert Balance in Testing
Balance in Testing

Today we must deal with shorter time-to-market, increasing complexity and more agility while keeping quality and other key system properties high.
To address these challenges the right balance in testing w.r.t. independence, timing, automation, and formality is critical but often not explicitly tackled.

Therefore, in this interactive tutorial we reflect on our current approach on balancing testing, investigate and discuss needed strategies, tactics, and practices, and share experiences to improve and sustain our testing approaches!

Max. number of participants: 40

Target Audience: Test Architects, Test Engineers, Product Owners, Quality Managers, Software Architects, Developers
Prerequisites: Basic knowledge about testing and quality engineering
Level: Advanced

Extended Abstract:
Today we must deal with shorter time-to-market, increasing complexity and more agility while keeping quality and other key system properties high. Our test systems increase in size, volume, flexibility, velocity, complexity, and unpredictability. Additionally, digitalization requires more than just a face lift in testing.

To address these challenges the right balance in testing w.r.t. independence, timing, automation, and formality is critical but often not explicitly tackled. Therefore, in this interactive tutorial we reflect on our current approach on balancing testing, investigate and discuss needed strategies, tactics, and practices in different areas, and share experiences and lessons learned to improve and sustain our testing approaches!

The following areas in testing are covered w.r.t. their appropriate balancing:

  • Level of independence – independent vs. fully integrated with development
  • Timing – too early vs. too late
  • Degree of automation – automated vs. manual
  • Formality – formal vs. informal, scripted vs. exploratory
  • Test case design – structured vs. experience-based, black-box vs. white-box

Peter Zimmerer is a Principal Key Expert Engineer at Siemens AG, Technology, in Munich, Germany. For more than 30 years he has been working in the field of software testing and quality engineering. He performs consulting, coaching, and training on test management and test engineering practices in real-world projects and drives research and innovation in this area. As ISTQB® Certified Tester Full Advanced Level he is a member of the German Testing Board (GTB). Peter has authored several journal and conference contributions and is a frequent speaker at international conferences.

Peter Zimmerer
Peter Zimmerer
flag VORTRAG MERKEN

Vortrag Teilen

14:00 - 17:00
Mo 12
Limitiert Approval Testing: Get Legacy Code Under Control
Approval Testing: Get Legacy Code Under Control

Approval testing is a technique that helps you to get a difficult codebase under test and begin to control your technical debt. Approval testing works best on larger pieces of code where you want to test for multiple things and interpreting failures is challenging.

In this hands-on session we'll introduce a commonly-used Approval testing tool for Java and through hands-on exercises learn to get control of some example code. The same tool is also available for many other programming languages, see https://approvaltests.com/

Bring a laptop.
Max. number of participants: 30

Target Audience: Developers, Architects
Prerequisites: Basic knowledge of Java and unit testing, bring a laptop
Level: Basic

Extended Abstract:

Introducing Approval Testing (55 minutes)

  • Code Review: examine existing test case, discuss strengths & weaknesses
  • Demonstration: Convert an assertion-based test to use Approval testing
  • Hands-on exercise: Add some tests using Approvals.Java.

Break (5 minutes)

Approval Test Design (50 minutes)

  • Presentation: Approval testing characteristics and design patterns
  • Exercise: Using the default XML printer with Approvals.Java
  • Demonstration: Using scrubbing with an XML printer
  • Discussion: when to print, when to scrub

Printer Design (30 minutes)

  • Exercise: Designing a printer for a domain object
  • Presentation: Case studies
  • Q&A (10 minutes)

Emily Bache is a Technical Coach with ProAgile. She has worked with software development for over 20 years in diverse organizations from start-up to large enterprise. These days Emily specializes in coaching development teams in agile practices like Test-Driven Development, refactoring and agile design. Emily has written two books, authored Pluralsight courses and regularly speaks at software conferences. Originally from the UK, she currently lives in Gothenburg, Sweden.
Twitter: https://twitter.com/emilybache
Linkedin: https://www.linkedin.com/in/emilybache/
Github: https://github.com/emilybache
Website: https://sammancoaching.org/

Emily Bache
Emily Bache
flag VORTRAG MERKEN

Vortrag Teilen

14:00 - 17:00
Mo 15
Limitiert Accessibility Workshop to Help Capture Best Practises and Shift Left
Accessibility Workshop to Help Capture Best Practises and Shift Left

How often have you heard that “Yes this is important, but we don’t have the capacity right now” or “sure let’s put it in the backlog”?

At least 1 in 5 people in the UK have a long-term illness, impairment or disability. Many more have a temporary disability. A recent study found that 4 in 10 local council homepages failed basic tests for accessibility.
Bring a laptop.

Max. number of participants: 20

Target Audience: Everyone
Prerequisites: None
Level: Basic

Extended Abstract:
How often have you heard that “Yes this is important, but we don’t have the capacity right now” or “sure let’s put it in the backlog”?
This is something we should not brush off or take lightly. Accessibility testing is vital especially when your product is a user facing application.
We need to be socially aware as a team and build quality towards our product with making it more accessible.

At least 1 in 5 people in the UK have a long-term illness, impairment or disability. Many more have a temporary disability. A recent study found that 4 in 10 local council homepages failed basic tests for accessibility.

This is quite vital and the sooner we as testers can advocate this into our teams, we make our product more accessible, reduce the risk of bad product reviews, reputation and also be more socially aware. Let's shift left and make accessibility testing built-in our teams.

  1. create a checklist
  2. look at some plugging (wave, lighthouse, arc toolkit, developer tools)
  3. Screen readers (mac/windows inbuilt)
  4. Have a healthy discussion on what they have learnt in the session and how can we bring accessibility sooner in an SDLC?
     

Laveena Ramchandani is an experienced Testing Consultant with a comprehensive understanding of tools available for software testing and analysis. She aims to provide valuable insights that have high technical aptitude and hopes to inspire others in the world through her work. Laveena holds a degree in Business Computing from Queen Mary University of London and regularly speaks at events on data science models and other topics.

Laveena Ramchandani
Laveena Ramchandani
Vortrag: Mo 15
flag VORTRAG MERKEN

Vortrag Teilen

, (Dienstag, 07.Februar 2023)
09:00 - 10:45
Di 8.1
How (Not) to Measure Quality
How (Not) to Measure Quality

Measuring quality requires many questions to be answered. The most obvious ones may be: “What is quality?”, but also “How can we measure it?”, “Which metrics are most accurate?”, “Which are most practical?”.

In this talk, I share some general motivations for measuring quality. I review commonly used metrics that claim to measure quality, I rate them with regards to how they may be helpful or harmful to achieve actual goals. I give some examples how the weaknesses of one metric might be countered by another one to create a beneficial system.

Target Audience: Developers, Project Leader, Manager, Decision Makers, Quality Engineers, Testers, Product Owners
Prerequisites: Basic Software Project Experience, Rough Understanding of Software Development
Level: Advanced

Extended Abstract:
Measuring quality requires many questions to be answered. The most obvious ones may be: “What is quality?”, but also “How can we measure it?”, “Which metrics are most accurate?”, “Which are most practical?”.

In my experience, one question is often not answered or postponed until it is too late: “Why do we want to measure quality?” Is it because we want to control how well our developers are performing? Is it to detect problems early? Is it to measure the impact of changes? Is it the product or the process we care about? Is it to improve locally in a single team or globally across the company? Is there a specific problem that we are trying to solve, and if so, which one?

Instead of trying to define what software quality is – which is hard and depends on a lot of factors – we should first focus on the impact of our measuring. Some metrics may work great for one team, but not for the company as a whole. Some will help to reach your team or organizational goal, some will not help at all, and some will even have terrible side effects by setting unintended incentives. Some can be gamed, others might be harmful to motivation. Consider an overemphasis on lead time, which can lead to cutting corners. Or measuring the number of bugs found, which can cause a testers versus developers situation.

In this talk, I share some general motivations for measuring quality. I review various commonly used metrics that claim to measure quality. Based on my experience, I rate them with regards to how they may be helpful or harmful to achieve actual goals and which side effects are to be expected. I give some examples how the weaknesses of one metric might be countered by another one to create a beneficial system.

Michael Kutz has been working in professional software development for more than 10 years now. He loves to write working software, and he hates fixing bugs. Hence, he developed a strong focus on test automation, continuous delivery/deployment and agile principles.
Since 2014 he works at REWE digital as a software engineer and internal coach for QA and testing. As such his main objective is to support the development teams in QA and test automation to empower them to write awesome bug-free software fast.

The State and Future of UI Testing
The State and Future of UI Testing

UI testing is an essential part of software development. But the automation of UI tests is still considered too complex and flaky.
This talk will cover the "state of the art" of UI testing with an overview of tools and techniques. It will be shown which kind of representations are used by today's test tools and how the addressing of elements in the UI is done.
In addition, the role of artificial intelligence in the different approaches is shown and a prediction of testing tools of the future is presented.

Target Audience: Developers, Testers
Prerequisites: Basic Knowledge of UI-Testing
Level: Advanced

Extended Abstract:
UI testing is an essential part of software development. Despite technological progress, the automation of UI tests is still considered too complex to function completely without manual intervention.
In addition to classical selector-based approaches, more and more image-based methods are being pursued.
This talk will cover the "state of the art" of UI testing with an overview of tools and techniques. In particular, current problems and future developments will be discussed. Furthermore, it will be shown which kind of UI representations are used by today's test tools and how the addressing of elements in the user interface is done.
In addition, the role of artificial intelligence in the different approaches is shown and a prediction of testing tools of the future is presented on the basis of current research.

Johannes Dienst is Developer Advocate at askui. His focus is on automation, documentation, and software quality.

Michael Kutz
Johannes Dienst
Johannes Dienst
flag VORTRAG MERKEN

Vortrag Teilen

14:00 - 14:45
Di 8.2
Testing AI Systems
Testing AI Systems

At first glance, testing AI systems seems very different from testing “conventional” systems. However, many standard testing activities can be preserved as they are or only need small extensions.

In this talk, we give an overview of topics that will help you test AI systems: Attributes of training/testing/validation data, model performance metrics, and the statistical nature of AI systems. We will then relate these to testing tasks and show you how to integrate them.

Target Audience: Developers, Testers, Architects
Prerequisites: Basic knowledge of testing
Level: Basic

Extended Abstract:
From a testing perspective, systems that include AI components seem like a nightmare at first glance. How can you test a system that contains enough math to fill several textbooks and changes its behavior on the whims of its input data? How can you test what even its creators don’t fully understand?

Keep calm, grab a towel and carry on - what you have already been doing is still applicable, and most of the new things you should know are not as arcane as they might seem. Granted, some dimensions of AI systems like bias or explainability will likely not be able to be tested for in all cases. However, this complexity has been around for decades even in systems without any AI whatsoever. Additionally, you will have allies: Data scientists love talking about testing data.

In this talk, we give an overview of topics that will help you test AI systems: Attributes of training/testing/validation data, model performance metrics, and the statistical nature of AI systems. We will then relate these to testing tasks and show you how to integrate them.

Gregor Endler holds a doctor's degree in Computer Science for his thesis on completeness estimation of timestamped data. His work at Codemanufaktur GmbH deals with Machine Learning and Data Analysis.

Marco Achtziger is a Test Architect working for Siemens Healthcare GmbH in Forchheim. He has several qualifications from iSTQB and iSQI and is a certified Software Architect by Siemens AG.

Gregor Endler, Marco Achtziger
Gregor Endler, Marco Achtziger
flag VORTRAG MERKEN

Vortrag Teilen

16:15 - 17:15
Di 8.3
Test Intelligence für manuelle Tests
Test Intelligence für manuelle Tests

Manuelle Tests wirken altmodisch, aufwendig und langsam. Trotzdem spielen sie in vielen wichtigen Softwaresystemen eine zentrale Rolle, auch langfristig.

In diesem Vortrag stelle ich Analysetechniken vor, die den Aufwand und die Durchführungszeit von manuellen Tests optimieren. Diese Techniken sind ursprünglich für automatisierte Tests entwickelt worden, lassen sich aber für manuelle Tests adaptieren, oft sogar mit besseren Ergebnissen.

Ich stelle die Grundlagen dieser Analysen vor und zeige Erfahrungen im Einsatz in der Praxis.

Zielpublikum: Tester, Test-Manager
Voraussetzungen: Erfahrungen mit manuellen Tests
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Manuelle Tests wirken altmodisch, aufwendig und langsam: Im Vergleich zu automatisierten Tests haben sie einen sehr hohen manuellen Aufwand für die Durchführung. Test-Phasen dauern damit oft Wochen statt Stunden und verhindern dadurch potentiell kürzere Release-Zyklen.

Trotzdem spielen sie bei vielen missionskritischen Softwaresystemen eine entscheidende Rolle in der Qualitätssicherung: Weil sich einige Tests nicht oder nur mit unverhältnismäßig hohem Aufwand automatisieren lassen, oder weil manuelle Tests komplementär zu automatisierten eingesetzt werden, um andere Fehlertypen zu finden, etc. Unser Survey [1] unter 38 Testern aus 16 internationalen Firmen hat aufgezeigt, dass diese Firmen auch weiterhin manuelle Tests als integralen Bestandteil ihres QS-Prozesses sehen und beibehalten werden.

In diesem Vortrag möchte ich Analysetechniken vorstellen, um den Aufwand und die Durchführungszeit von manuellen Tests zu optimieren. Diese Techniken sind ursprünglich für automatisierte Tests entwickelt worden, lassen sich aber auch für manuelle Tests adaptieren. Da die Kosten für die manuelle Ausführung oft viel höher sind als bei automatisierten Tests, erzielen sie oft bei manuellen Tests die viel höheren Ersparnisse.

Ich gehe im Vortrag unter anderem auf folgende Analysen ein:
•    Test-Priorisierung: Selektionsalgorithmen, die eine Teil-Testsuite ermitteln, die in kurzer Zeit einen möglichst großen Teil der Funktionalität testet. Diese „optimale Smoke-Test-Suite“ kann am Anfang einer Testphase ausgeführt werden, um zu verhindern, dass eine sehr fehlerhafte Version einer Software in den manuellen Test kommt, wo sich viele Fehler gegenseitig überdecken.
•    Test-Impact-Analyse: Auswahl der Tests, die eine spezifische Änderung am Code durchlaufen. Dadurch können bei Hotfix-Tests in kurzer Zeit neue Fehler gefunden werden, die ggf. durch den Hotfix entstanden sind.
•    Test-Gap-Analyse: Aufdeckung von Änderungen/neuen Features, die im manuellen Test übersehen und nicht getestet wurden (oder sich nach dem manuellen Test ergeben haben, und die Wiederholung des Tests erfordern).

Im Vortrag stelle ich sowohl die Grundlagen und Grenzen dieser Analysen vor, als auch Erfahrungen und Erfolge im Einsatz in der Praxis.

[1] "How Can Manual Testing Processes Be Optimized? Developer Survey, Optimization Guidelines, and Case Studies". Roman Haas, Daniel Elsner, Elmar Juergens, Alexander Pretschner. In Proceedings of the 29th ACM Joint Eurpoean Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE '21').

Dr. Elmar Juergens hat über statische Codeanalyse promoviert und für seine Doktorarbeit den Software-Engineering-Preis der Ernst Denert-Stiftung erhalten. Er ist Mitgründer der CQSE GmbH und begleitet seit zehn Jahren Teams bei der Verbesserung ihrer Qualitätssicherungs- und Testprozesse. Juergens spricht regelmäßig auf Forschungs- und Industriekonferenzen und wurde für seine Vorträge mehrfach ausgezeichnet. Elmar Juergens wurde 2015 zum Junior Fellow der Gesellschaft für Informatik ernannt.

Elmar Juergens
Elmar Juergens
Vortrag: Di 8.3
flag VORTRAG MERKEN

Vortrag Teilen

17:45 - 18:45
Di 8.4
The Shape of Testing, Teams and the World in the Future
The Shape of Testing, Teams and the World in the Future

IT is always changing ... In this talk I'll do some crystal ball gazing from two perspectives. At heart, I’m a tester. For two years I’ve also been a CEO. I’ll look at what factors are at work and what kinds of effects will they have on how we work and the roles of testers and software professionals.

Alongside musings about the future, I’ll talk about concrete activities on an individual and company level to best prepare ourselves for this nebulous future.

Target Audience: Everyone
Prerequisites: None
Level: Basic

Extended Abstract:
I’m not the first person to notice that the world is constantly changing and that everything is impermanent. Most especially after the last two years, we have really been forced to come to terms with how quickly and drastically things can change. As IT professionals, we are aware of the intrinsic changeability of projects, contexts and our business, but the events of the last couple of years have put this into sharper focus.

But let’s not get too generally philosophical about the whole world. Let’s look at what is in our more immediate context and perhaps even in our sphere of influence. If our future is anything, it’s nebulous (and I don’t just mean the cloud). How will external changes shape our teams and our work, and how can we shape ourselves proactively in order to be able to respond to changes, make changes or our own and even thrive?

In this talk I’d like to do some triangulated crystal ball gazing from two perspectives. At heart, I’m a tester. For two years I’ve also been a CEO. From my passion for testing and my experience of business and people in organisations, I’ll look at what factors are at work now, what known unknowns we have and what kinds of effects will they have on how we work and the roles of testers and software professionals.
Alongside musings about the future, I’ll talk about concrete activities on an individual and company level to best prepare ourselves for this nebulous future.

Alex Schladebeck ist ein Wirbelwind aus Begeisterung für Qualität, Agilität und Menschen. Aus der anfänglichen Testerrolle ist eine spannende Karriere als Product Owner, Berater und Führungskraft entstanden, bevor sie 2020 Teil der Geschäftsführung bei der Bredex GmbH wurde.
Sie verbringt ihre Zeit in Kommunikation mit verschiedenen Menschen. Dazu gehört Wissensvermittlung durch Workshops und Coaching, Zusammenarbeit mit Entwicklern und Testern, Kundenberatung, Mitarbeiterentwicklung sowie strategische Themen mit anderen Führungskräften umzusetzen. Sie hält sich bei ihrem Lieblingsthemen auf dem Laufenden, indem sie weiterhin Kunden und Teams berät und unterstützt.
Alex spricht häufig auf Konferenzen als Speaker oder Keynote-Speaker über Agilität, Qualitätssicherung und Führung aus Sicht ihrer Erfahrung. In ihrer Freizeit ist sie leidenschaftliche Sportlerin, Musikerin und Tante. Sie beschreibt sich selbst als „explorer“ und liebt es, Orte, Kulturen, Perspektiven und Menschen zu entdecken.

Alex Schladebeck
Alex Schladebeck
flag VORTRAG MERKEN

Vortrag Teilen

, (Mittwoch, 08.Februar 2023)
09:00 - 10:30
Mi 8.1
3 Amigos und die Entwicklung eines Produkts (BDD)
3 Amigos und die Entwicklung eines Produkts (BDD)

Dieses Problem kennen wir alle: In Projekten führt eine unzureichende Kommunikation oft dazu, dass die Software am Ende nicht so umgesetzt ist, wie die Auftraggebenden es sich am Anfang vorgestellt hatten.
Behaviour-Driven Development (BDD) setzt von Anfang an darauf, alle Stakeholder an einen Tisch zu holen und ein gemeinsames Verständnis über das gewünschte Verhalten der Software herzustellen. Daraus entsteht eine ausführbare Spezifikation, die zum richtigen Produkt nebenbei noch automatisierte Tests und eine lebendige Dokumentation liefert.

Zielpublikum: Product Owner, Entwickler:innen, Tester, Business-Analysten
Voraussetzungen: Grundkenntnisse in Java
Schwierigkeitsgrad: Anfänger

Extended Abstract:
SZENARIO: OOP Konferenz 2023

ANGENOMMEN DASS du wenig über BDD weißt
WENN du zu diesem Vortrag kommst
DANN lernst du das Grundprinzip kennen
ANGENOMMEN DASS du BDD bisher als Testmethode nutzt
WENN du zu diesem Vortrag kommst
DANN siehst du, dass noch viel mehr dahintersteckt

Behaviour-Driven Development ist ganz sicher keine neue, aber eine häufig missverstandene Methode. In vielen Teams wird BDD nur zum Testen eingesetzt. In diesem Talk gehen wir einmal gemeinsam den Weg von der ersten Beschreibung der Software bis zur Umsetzung im Code, um zu erkennen, dass der Fokus von BDD auf der Kommunikation zwischen allen an der Entwicklung Beteiligten liegt.

Katrin Rabow hat viele Jahre als selbstständige Beraterin kleine Unternehmen in ihrem kaufmännischen Alltag unterstützt, ehe sie sich 2015 für ein Studium der Wirtschaftsinformatik an der TU Darmstadt entschied. Sie sucht immer wieder nach Wegen, „harte“ Themen wie Software-Engineering mit „weichen“ Themen wie der Unternehmenskultur zu verbinden. Seit ihrem Masterabschluss arbeitet sie als IT-Consultant in Frankfurt.

Katrin Rabow
Katrin Rabow
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Mi 8.2
Warum ist Code so schwer zu verstehen?
Warum ist Code so schwer zu verstehen?

Wann ist Code verständlich?

Wenn die Methoden kurz sind, wenn sprechende Namen verwendet werden, wenn ... diese Liste ist lang und zumindest in Auszügen bekannt. Verständlichkeit wird meist mit Faustregeln und Code-Smells beschrieben.
Wir möchten hier anders ansetzen: Verständlichkeit entsteht im Gehirn. Leicht verständlich bedeutet, dass das Gehirn gefordert wird, schwer verständlich, dass es überfordert wird.

Zielpublikum: Entwickler:innen, Architekt:innen, alle, die es interessiert
Voraussetzungen: Programmiersprachenkenntnisse (nur für die Beispiele)
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Wir erarbeiten gemeinsam anhand eines Modells den Verständnisprozess, lernen wo unser Verständnis an seine Grenzen stößt, und demonstrieren Erkenntnisse an anschaulichen Code-Beispielen.
Interessant für jeden, der sich nicht nur für Code-Smells und Code-Konventionen interessiert, sondern auch gerne ein Blick auf das "Warum" wirft.

Stefan Mandel ist Full-Stack-Entwickler bei andrena objects und beschäftigt sich seit fast 20 Jahren mit Programmiersprachen, Prinzipien und Refactoring.

Als studierter Mathematiker findet Peter Guntermann eigentlich großen Gefallen daran, sich das Hirn über kniffligen Problemen zu zermartern. Doch wenn es darum geht, robuste und leicht wartbare Software zu entwickeln, hält er es am liebsten so simpel und gehirngerecht wie möglich. Clean Code und Domain-driven Design sind hierbei seine wichtigsten Begleiter, um die Herausforderungen im agilen Alltag zu bewältigen.

Stefan Mandel, Peter Guntermann
Stefan Mandel, Peter Guntermann
Vortrag: Mi 8.2
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Mi 8.3
Test-Driven Requirements Engineering: Agile Testing in Practice
Test-Driven Requirements Engineering: Agile Testing in Practice

Requirements engineering like testing require balance of value and risk. Agile requirements engineering and testing with test-driven requirements engineering (TDRE) balances project risks and cost. Clear advantage: Requirements are understandable, testable, and directly applicable as test case. Lead time and costs in testing are reduced by up to thirty percent.

This presentation at OOP 2023 will practically introduce to agile requirements engineering and test with TDRE. A case study demonstrates an industry use of TDRE.

Target Audience: Project Managers, Architects, Analysts, Requirements Engineers, Product Owners, Software Engineers
Prerequisites: None
Level: Advanced

Extended Abstract:
Requirements engineering like testing require balance. Balance is about balancing value and risk. Requirements must be good enough to mitigate risks but yet not overly specific to contain effort. Same for test, which though never complete needs to address those areas with highest risk.

Requirements engineering and testing belong together. Historically, testers have often only seen the requirements after the system has already been partially implemented. This had two serious disadvantages. On the one hand, insufficient requirements quality came far too late to the table. On the other hand, it was quite a lot of extra work without deriving suitable test cases in the context of requirements definition. A lot of additional work and long correction loops were the result.

Only an agile balance of risk-oriented coverage and testable requirements can improve test effectiveness. Such risk-oriented work also optimizes requirements engineering. Instead of paralysis by analysis in defining numerous requirements, test-driven requirements engineering (TDRE) focusses on specifying what is necessary and of high risk or high value.

TDRE is straight-forward: Test cases are developed in parallel to the requirements. Thus, the feasibility of the requirements is analyzed much faster than in the traditional sequential approach, in which tests are specified relatively late. The test cases are initially described in the same structure as the requirements and as a supplement to the respective requirements. This shifts Test-Driven Development (TDD), which has already proven itself as relevant agile methodology, to the specification level. Regression tests are attributed in order to prepare for later automation. The effort required for testing can be better estimated on this basis, and project and quality risks are thus reduced.
TDRE follows a triple peak model, which is connecting requirements (i.e., needs), design (i.e., solution) and test (i.e., the product).

It intertwines three perspectives:
•    Market perspective: “How can I meet customer satisfaction and needs?”
•    Design perspective: “How can I implement the solution to meet requirements?”
•    Testing perspective: “How can I find a defect and cause the product to fail?”

Here some guidance from our projects, which we will further illustrate in this presentation:
•    Every single functional requirement has at least one acceptance check, which is either fulfilled or not fulfilled and serves as the agile DoD (definition of done).
•    Each individual quality requirement is described with numerical values that can be measured.
•    Business rules are defined so that it can be determined whether they are true or false.
•    Business and data objects are defined with all their attributes, types and states so that they can be set and validated at test time.
•    System interfaces such as GUIs, reports and service interfaces are included in the requirements document so that values can be assigned to them.
•    All use cases have pre- and post-conditions that can be generated and validated.
•    All text is marked so that it can be automatically processed to generate test cases.

Agile requirements engineering and testing with test-driven requirements engineering (TDRE) balances project risks and cost. Clear advantage: Requirements are understandable, testable, and directly applicable as test case. Lead time and costs in testing are reduced by up to thirty percent. This presentation at OOP 2023 will practically introduce to agile requirements engineering and test with TDRE. A case study from medical cybersecurity demonstrates an industry use of TDRE.

Christof Ebert is managing director at Vector Consulting Services. He supports clients around the world in agile transformations. Before he had been working for ten years in global senior management positions. A trusted advisor and a member of several of industry boards, he is a professor at the University of Stuttgart and at Sorbonne in Paris. He authored several books including "Requirements Engineering" published by dPunkt and in China by Motor Press. He is serving on the editorial Boards of "IEEE Software" and "Journal of Systems and Software (JSS)".

Christof Ebert
Christof Ebert
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Mi 8.4
QMS nach ISO 9001 – Das Ende der Produktivität oder eine Qualitätsverbesserung?
QMS nach ISO 9001 – Das Ende der Produktivität oder eine Qualitätsverbesserung?

Wir sind in 20 Jahren zu einer 100-Personen-Entwicklungseinheit herangewachsen, die große komplexe Software-Projekte umsetzt. Jetzt haben wir uns entschlossen, ein Qualitätsmanagementsystem (QMS) nach ISO 9001 einzuführen.
Wir haben dabei festgestellt, wie wichtig die Integration des QMS in unsere Kultur und wie notwendig ein iteratives partizipatives Vorgehen ist. In diesem Vortrag stelle ich einige Herausforderungen vor und wie wir diese so gelöst haben, dass unser QMS unsere Qualität verbessert, ohne die Entwickler:innen zu quälen.

Zielpublikum: Architekt:innen, Projektleiter:innen, Manager, Entscheider
Voraussetzungen: Grundlagen in Qualitätsmanagement
Schwierigkeitsgrad: Fortgeschritten

Dr. Torsten Fink ist Geschäftsführer der Berliner Einheit der akquinet. Neben der Leitung von Softwareprojekten führte er vor seiner Managementtätigkeit Architektur- und Technologieberatungen durch. Aus dem eher technischen Bereich verteilter Systeme kommend, beschäftigt er sich in letzter Zeit immer mehr mit qualitätsorientierten Prozessen und modernen Organisationsstrukturen.

Nach einem Studium in der Wirtschaftsinformatik arbeitet Jana Metz in der Berliner Niederlassung der akquinet als Qualitätsmanagementbeauftragte und IT-Projektmanagerin mit den Schwerpunkten E-Health. Telematikinfrastruktur und Medizinproduktentwicklung. Sie ist maßgeblich an dem Aufbau des firmeneigenen QM-Systems beteiligt und unterstützt dessen Einführung und Umsetzung in der agilen Softwareentwicklung.

Christian Koska ist Qualitätsmanagementbeauftragter der Berliner Einheit der akquinet. Er ist somit mitverantwortlich für die Einführung eines individuellen QM-Systems. Ursprünglich im klinischen Studien- und Controllingbereich angesiedelt, ist er heute fachlich beratend in Softwareentwicklungsprojekte für den Health-Sektor involviert. Die letzten Jahre widmete er zunehmend den regulatorischen Anforderungen an Medizinprodukte sowie dem Aufbau und Betrieb von QM-Systemen.

Torsten Fink, Jana Metz, Christian Koska
Torsten Fink, Jana Metz, Christian Koska
Vortrag: Mi 8.4
flag VORTRAG MERKEN

Vortrag Teilen

, (Donnerstag, 09.Februar 2023)
09:00 - 10:45
Do 3.1
Use Testing to Develop Better Software Faster
Use Testing to Develop Better Software Faster

As developers, our job is to deliver working software. With the shift to CI/CD and the move to the cloud, the need to have the right feedback at the right time only increases. There are many ways that testing can help us with that. Not only can testing help us verify our solution and prevent us from breaking things, it can also help us design our software, find flaws in our architecture and come up with better solutions. In this talk I will highlight some of the many ways that testing can help you to develop better software faster.

Target Audience: Developers
Prerequisites: Basic knowledge in Java
Level: Advanced

Extended Abstract:
Testing doesn't always get the attention it deserves in software development. Many developers claim to be bad at it, or are just not that interested. (These may or may not be related.)

As developers, our job is to deliver working software. With the shift to CI/CD and the move to the cloud, the need to have the right feedback at the right time only increases. There are many ways that testing can help us with that. Not only can testing help us verify our solution and prevent us from breaking things, it can also help us design our software, find flaws in our architecture and come up with better solutions.

In this talk I will highlight some of the many ways that testing can help you to develop better software faster.

Marit van Dijk is a software developer with 20 years of experience in different roles and companies. She loves building awesome software with amazing people and has contributed to open source projects like Cucumber and various other projects. She enjoys learning new things, as well as sharing knowledge on programming, test automation, Cucumber/BDD and software engineering. She speaks at international conferences, webinars and podcasts, occasionally writes blog posts and contributed to the book "97 Things Every Java Programmer Should Know" (O’Reilly Media).

Micro-Service Delivery without the Pitfalls
Micro-Service Delivery without the Pitfalls

In this session I’ll examine some of the things that can go wrong when organisations jump headfirst into micro-service architectures without understanding the potential pitfalls.

I'll explain contract testing from the ground up. You'll learn how it can decouple micro-service dependencies during development, allowing your teams to work effectively. And I'll describe sophisticated, free, open-source tooling that helps integrate contract testing into your software lifecycle, giving you the confidence to release micro-services independently.

Target Audience: Architects, Developers, Decision Makers, Release Managers, DevOps
Prerequisites: English, basic software design/architecture, software lifecycle
Level: Advanced

Seb Rose has been a consultant, coach, designer, analyst and developer for over 40 years. He's now Developer Advocate with SmartBear Advantage, promoting better ways of working to the software development community.
Co-author of the BDD Books series "Discovery” and "Formulation" (Leanpub), lead author of “The Cucumber for Java Book” (Pragmatic Programmers), and contributing author to “97 Things Every Programmer Should Know” (O’Reilly).

Marit van Dijk
Seb Rose
Seb Rose
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:45
Do 4.1
Ready for the Future: Enterprise Java in Zeiten von Modern Web, Cloud Native & Co.
Ready for the Future: Enterprise Java in Zeiten von Modern Web, Cloud Native & Co.

Auch nach mehr als 20 Jahren ist Jakarta EE (ehemals Java EE) DER Standard, wenn es um die Entwicklung Java-basierte Enterprise Computing-Lösungen geht. Dies gilt zumindest immer dann, wenn die Anwendung als Monolith in einem Application Server deployed werden soll. Wie aber steht es mit einer Anwendung, die aus einer Vielzahl autark laufender Microservices besteht? Und wie gut schlägt sich Jakarta EE in der Cloud, in der geringer Speicherbedarf und schnelle Startzeiten gefragt sind?

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Entscheider
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Die Session zeigt, wie es Jakarta EE geschafft hat, mit der Zeit zu gehen und so, mithilfe von Side-Projekten wie dem Eclipse MicroProfile, den Anforderungen moderner Cloud-native-Anwendungen gerecht zu werden.
Ein Ausblick auf das Zusammenspiel mit GraalVM und Quarkus zeigt, dass Jakarta EE dabei auch in extrem verteilten Cloud-Szenarien, aka Serverless, eine gute Figur macht.

Lars Röwekamp, Gründer des IT-Beratungs- und Entwicklungsunternehmens open knowledge GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. Ein besonderer Schwerpunkt seiner Arbeit liegt derzeit in den Bereichen Enterprise und Cloud Computing sowie ML/AI, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen.

Gestern ging es noch! API Testing reloaded
Gestern ging es noch! API Testing reloaded

Webanwendungen ohne automatisiert getestete APIs machen im Betrieb und Weiterentwicklung schlechte Laune, egal, ob es um APIs zwischen Frontend und Backend, zwischen Microservices oder zu Drittparteien geht. Typischerweise beschreiben wir das erwünschte Verhalten der Anwendung, in dem wir uns selbst Beispiele als Testfälle ausdenken. Da geht mehr. In diesem Beitrag werfen wir einen Blick auf über "naive Integrationstests" hinausgehende Ansätze, von Contract Based bis hin zu KI-Unterstützung.

Zielpublikum: Entwickler:innen, Tester:innen
Voraussetzungen: Erfahrung in der Entwicklung und im automatisierten Testing von Webanwendungen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Die Älteren unter uns werden sich noch an die Anfänge der Webentwicklung erinnern: Tester:innen klickten sich wieder und wieder durch umfangreiche Testpläne durch, die typischerweise nach dem Entwickeln erstellt wurden. Dieser Ansatz ist leider gerade in Konzernen immer noch nicht ausgestorben. Schlecht getestete Schnittstellen werden schnell zur Achillesferse gerade in modularen Architekturen und vor dem Wunsch, fertige Software schneller in die Produktion zu bringen. Consumer driven contract testing ist zumindest theoretisch mittlerweile in den Teams angekommen, neuere Ansätze wie Search based Software Testing oder Property based Testing sind dagegen noch exotisch.

Die Session will einen praxisorientierten Überblick über unbekanntere Verfahren geben.

Dorthe Luebbert ist in der IT seit der 5 1/4 Zoll Diskette dabei und interessiert sich für Webtechnologien und die Menschen, die diese bauen. Als Freelancerin in der IT schätzt sie den entspannten Feierabend dank guter Architektur, Softwarequalität und vernünftiger Prozesse.

09:00 - 10:45
Do 8.1
Evolutionäre Softwarequalität
Evolutionäre Softwarequalität

Qualitätsziele helfen uns, Architekturentscheidungen fundierter zu treffen. Die genau richtige Qualität ist jedoch oft subjektiv und ändert sich über die Zeit hinweg. Dies macht das Arbeiten mit und an Qualitätszielen vor allem bei langlebigen Softwaresystemen spannend.

In diesem Vortrag stelle ich eine neue Sicht auf Softwarequalität vor, bei der wir Qualität im evolutionären Kontext betrachten. Als Basis verwende ich das ISO 25010-Qualitätsmodell sowie Wardley Mapping, um die passende Qualität nach Wichtigkeit und Evolutionsstufen zu finden.

Zielpublikum: Software-Architekt:innen, Entwickler:innen
Voraussetzungen: Erfahrung mit optimierungsbedürftigen Softwaresystemen
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Die Balance der passenden Qualitätszielen ist ein herausforderndes Thema. Qualitätsziele sind aber sehr wichtig in der Entwicklung passender Softwaresysteme. Sie helfen uns, Architekturentscheidungen fundierter zu treffen. Die „genau richtige Qualität“ hängt dabei stark vom Betrachtungspunkt verschiedener Stakeholder ab. Zudem ändern sich Ansprüche an die Qualitäten eines Softwaresystems über die Zeit hinweg. Dies macht das Arbeiten mit und an Qualitätszielen vor allem in langlebigen Softwaresystemen immer wieder spannend.

In diesem Vortrag stelle ich eine neue Sicht auf Softwarequalität vor, wo wir Qualität im evolutionären Kontext betrachten. Als Basis verwende ich hierzu das ISO 25010-Qualitätsmodell sowie Wardley Mapping. Damit lassen sich notwendige Qualitäten nach ihrer Wichtigkeit und Evolutionsstufen von Softwaresystemen kommunizieren. Der Vortrag verzahnt die evolutionäre Sicht auf Softwarequalität mit Beispielen aus der Praxis und zeigt, wie sich damit die richtige Balance zwischen zu viel und zu wenig Qualität gestalten lässt.

Markus Harrer arbeitet seit mehreren Jahren in der Softwareentwicklung und ist vor allem in konservativen Branchen tätig. Als Senior Consultant hilft er, Software nachhaltig und wirtschaftlich sinnvoll zu entwickeln und zu verbessern. Er ist aktiver Mitgestalter in Communities zu den Themen Software Analytics, Softwarearchitektur, Softwaresanierung und Java. Zudem ist er akkreditierter Trainer für den iSAQB Foundation Level und dem Advanced-Level-Modul IMPROVE.

Technische Schulden – warum der Begriff mehr Verwirrung als Klarheit stiftet. Und wie es besser geht
Technische Schulden – warum der Begriff mehr Verwirrung als Klarheit stiftet. Und wie es besser geht

Ist uns Softwerkern wirklich klar, was wir meinen, wenn wir von Technischen Schulden sprechen? “Klar”, ist die Antwort. Wirklich? Warum haben wir dann Schwierigkeiten, POs/Projektleiter/Abteilungsleiter vom notwendigen Budget zu überzeugen?
Im Vortrag zeigen wir, wie es datenbasiert besser geht. Wie man für Technische Schulden KPIs erfasst und wie man jeweils Code-, Architektur-, Test-Qualität, Team-Kollaboration mit den KPIs korreliert, um eine Kosten-Nutzen-Analyse durchzuführen. Trotz Microservices und DevOps - die Herausforderungen bleiben.

Zielpublikum: Architekt:innen, Projekt-/Technische Leiter:innen, Key Developer, Manager, Entscheider
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Ist uns Softwerkern wirklich klar, was wir meinen, wenn wir von Technischen Schulden sprechen? “Klar”, ist die Antwort, “es geht um Smells, Bugs, Bedarf an Refactoring, fehlende Tests …”. Zum Teil können wir deren Umfang und Bedarf sogar messen. Aber wie entscheiden wir, was wir zuerst angehen sollen? Wie und was messen wir, sodass andere Stakeholder uns überhaupt verstehen und wir POs, Projektleiter und Abteilungsleiter vom notwendigen Budget überzeugen können?
Im Vortrag zeigen wir, wie man datenbasiert bessere Antworten findet. Was man mit den Folgen der Technischen Schulden anfängt, Wartungs- und sich verstärkende Mehraufwände in der Entwicklung als KPIs erfasst und deren Hotspots im Code identifiziert. Wie man jeweils Code-, Architektur- und Test-Qualität usw. als Ursachen identifiziert und mit den KPIs korreliert. Und wie man Technische Schulden in der Architektur in Zahlen prognostiziert, um eine Kosten-Nutzen-Analyse durchführen zu können. Und wie sich Team-Kollaboration auch auf Technische Schulden auswirkt.
Diese Herausforderungen sind seit mehreren Jahrzehnten die gleichen. Daran haben auch Microservices nichts geändert.

Die Teilnehmer erhalten Antworten auf folgende Fragen:

•    Was sind Technische Schulden genauer?
•    Wie misst man die Folgen?
•    Wie sieht eine effektive Ursachenanalyse aus?
•    Wie überzeuge ich andere Stakeholder von der Notwendigkeit?
•    Wie wirkt sich Team-Kollaboration auf Technische Schulden aus?

Egon Wuchner hat mehr als 18 Jahre bei der Siemens Corporate Technology als Software-Engineer, Architekt und Projektleiter zu Software-Architektur-Themen wie Qualitätsattribute und Software-Wartbarkeit gearbeitet.
Konstantin Sokolov hat teilweise für Siemens als Freelancer an den Themen mit Egon zusammengearbeitet. Zusammen haben sie Cape of Good Code gegründet mit dem Ziel, Software-Analysen anzubieten, auf die es ankommt.
Markus Harrer
Egon Wuchner, Konstantin Sokolov
Egon Wuchner, Konstantin Sokolov
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Do 8.2
Hardware-in-the-Loop und Continuous Integration – wie passt das zusammen?
Hardware-in-the-Loop und Continuous Integration – wie passt das zusammen?

Jede kleine Änderung an einem Embedded System kann bösartigste Auswirkungen haben. Findet und behebt man die Probleme zu spät, ist die Behebung zudem sehr teuer.

In Vortrag und Demo wird gezeigt, wie man durch Verbindung von Hardware-in-the-Loop und Continuous Integration jede Änderung an einem Embedded System innerhalb von Minuten testen kann, statt lange auf die Durchführung von Systemtests zu warten.

Zielpublikum: Architekt:innen, Embedded Entwickler:innen, Qualitätsmanager, Projektleiter:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Jede kleine Änderung an einem Embedded System kann bösartigste Auswirkungen haben. Findet und behebt man die Probleme zu spät, ist die Behebung zudem sehr teuer.

Daher sollte jede Änderung an einem Embedded System innerhalb von Minuten getestet werden können. Nur so kann man sicherstellen, dass man die Probleme schnell entdecken und beheben kann.
Bei reinen Softwareprojekten hilft eine vollständige Automatisierung der Tests über Continuous Integration (CI). Hierbei löst jede Codeänderung automatisch den Bau und Test der kompletten Software aus. Dadurch kann innerhalb von Minuten ein vollständiger Regressionstest Fehler in bestehendem und neuem Code entdecken.

Aber wie kann man das für System- oder Integrationstests bei Embedded Systemen erreichen?

Dafür nötige Hardware-in-the-Loop-Tests (HIL-Test) oder manuelle System-Tests sind häufig schwer zu automatisieren.

* Echte Hardwareanteile im Testaufbau verhindern die Automatisierung und Wiederholbarkeit
* Häufig kann nur der "Happy Path", nicht aber ein Fehlverhalten getestet werden
* Der Teststand ist häufig zu teuer, um für jedes Projekt, jederzeit für Automatisierung verfügbar zu sein

Durch den leichtgewichtigen Hardware-in-the-Loop-Test mit dem miniHIL kann man die Tests vollständig über Continuous Integration automatisieren.
Wie geht das?

* Hardwareschnittstellen werden nur auf Signalebene simuliert und passen daher gut in die Test-Automatisierung
* Testhardware wird größtenteils durch Softwaresimulationen ersetzt
* Fehlverhalten kann einfach über fehlerhafte Signale simuliert und getestet werden
* Die dazu nötige Hardware ist signifikant einfacher, kleiner und preiswerter als traditionelle HIL-Systeme. Für jedes Projekt steht jederzeit ein eigener Testaufbau für die Automatisierung zur Verfügung.

So kann jede Änderung innerhalb von Minuten automatisch getestet werden. Erst durch die vollständige und schnelle Testautomatisierung kann effektiv in Teams gemeinsam komplexe Embedded Software entwickelt werden.
Der Vortrag schließt mit einer Live-Demo eines solchen Testaufbaus.

Thomas Schütz studierte Luft- und Raumfahrttechnik in München und gründete 1997 die PROTOS Software GmbH. Als Softwareprojektleiter oder Architekt konnte er seine Erfahrung in der Verbindung modellbasierter Ansätze mit den Anforderungen von Embedded Systemen in zahlreiche Projekte einbringen. Thomas Schütz berät Firmen beim Aufbau von domänenspezifischen Werkzeugketten und Testsystemen für Embedded Systeme und ist Projektleiter des Eclipse-Projektes eTrice.

Thomas Schütz
Thomas Schütz
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Do 8.3
Wie viele Grenzwerte sollte man testen?
Wie viele Grenzwerte sollte man testen?

Grenzwertanalyse ist ein weit verbreitetes Verfahren mit dem Ziel, Fehlerzustände bei Vergleichen aufzudecken. Populär ist die Abdeckung von zwei oder drei Werten je Grenze. An einem praktischen Beispiel zeigt der Autor, dass drei Werte nicht immer ausreichen.
Im Vortrag präsentiert er einen neuen Ansatz aus 2021, der auf Mutationsanalyse basiert. Anschließend geht der Autor darauf ein, wie die Anzahl der Grenzwerte eines Parameters bei mehreren Grenzen optimiert werden kann.

Zielpublikum: Tester, Testanalysten, Entwickler:innen mit Interesse am Testen (SDET)
Voraussetzungen: Grundkenntnisse in Testen, z. B. CTFL, Grundkenntnisse der Programmierung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Grenzwertanalyse ist ein weit verbreitetes Verfahren mit dem Ziel, Fehlerzustände bei Vergleichen aufzudecken. Populär ist die Abdeckung von zwei oder drei Werten je Grenze. An einem praktischen Beispiel eines nicht seltenen Codierfehlers in einer kritischen Anwendung zeigt der Autor, dass alle drei üblichen Grenzwerte den Test bestehen und den Fehlerzustand unentdeckt lassen. Im Vortrag präsentiert er einen neuen mutationsbasierten Ansatz von Kovács und Forgács (Paradigm Shift in Software Testing, 2021). Bei einem Mutationstest wird eine korrekte Implementierung der Spezifikation zu einer fehlerhaften Variante abgewandelt (mutiert), und es werden Eingaben gesucht, bei denen diese Mutation ein vom Erwarteten abweichendes Ergebnis verursacht. Die Herausforderung hierbei ist, dass es zu jeder endlichen Anzahl von Eingaben unendlich viele fehlerhafte Codes gibt, die bei den gewählten Eingaben das korrekte Ergebnis bringen, aber bei anderen nicht. Beim Mutationstest nimmt man deshalb an, dass der Programmierer kompetent ist und nur sporadisch Fehler macht. Gestützt auf empirische Studien beschränkt man sich auf Mutationen erster Ordnung (d. h., nur ein Element des korrekten Codes mutiert). Bei einem Vergleich kann es sich dabei um eine Mutation der Operanden oder des Operators handeln. Das führt zu einer gut begründeten Antwort auf die gestellte Frage, wie viele Grenzwerte man zu einer Grenze testen soll: so viele, dass alle Mutationen erster Ordnung des Vergleichs überdeckt werden. Es sind die vier Grenzwerte "ON, OFF, IN und OUT" von Offutt (Introduction to Software Testing, 2016), welche die richtige Balance von minimaler Anzahl von Testfällen (Effizienz) und vollständiger Überdeckung der Mutanten (Effektivität) erbringen.
Der Autor veranschaulicht die Anwendung an konkreten Beispielen von Spezifikationsfragmenten und geht auch auf die Möglichkeit der automatischen Testfallgenerierung ein. Schließlich wird die Frage auf Parameter mit mehreren Grenzen erweitert. Auch hier kann die Anzahl der Grenzwerte systematisch optimiert werden, indem man z. B. den IN-Wert der einen Äquivalenzklasse gleichzeitig als OUT-Wert der benachbarten Klasse nutzt. Die Lösung hängt davon ab, ob die Äquivalenzklassen zwischen den Grenzen aus einem, zwei oder mehreren Elementen bestehen.

Matthias Hamburg war bis zu seiner Pensionierung in 2019 Managing Consultant bei der Sogeti Deutschland GmbH. Seine fachlichen Schwerpunkte sind bei der Testanalyse, Testmanagement und Testprozessverbesserung. Im German Testing Board (GTB) und seinem Dachverband ISTQB engagiert er sich weiterhin ehrenamtlich. Unter anderem gibt er den Advanced Test Analyst Lehrplan und das Standardglossar der Testbegriffe in Englisch und in Deutsch heraus.

Matthias Hamburg
Matthias Hamburg
Vortrag: Do 8.3
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Do 8.4
Unser eigenes QA-Manifest – Ein übergreifendes Testvorgehen für eine agile Entwicklungsabteilung
Unser eigenes QA-Manifest – Ein übergreifendes Testvorgehen für eine agile Entwicklungsabteilung

In der Entwicklungsabteilung der Carl Zeiss SMT GmbH arbeiten mehr als 30 Scrum-Teams. Für diese wurde ein übergreifendes „QA Manifest“ erstellt, das die grundlegenden Werte für die Qualitätssicherung definiert, Empfehlungen ausspricht sowie Anleitungen und Good Practices beinhaltet.

Im Vortrag werden die Ergebnisse vorgestellt, aber besonders wird auf die Erkenntnisse und Überraschungen eingegangen, die während der Workshops, Interviews und Arbeit mit allen Beteiligten auftauchten.

Zielpublikum: Tester, Entwickler:innen, Projektleiter:innen, Manager, Entscheider,
Voraussetzungen: Fachkenntnisse agile Methoden
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Die Entwicklungsabteilung EMI der ZEISS Semiconductor Manufacturing Technology hat sich in den letzten Monaten erfolgreich einer agilen Transition unterzogen. Es gibt nun mehr als 30 Scrum-Teams, die verschiedene Softwareprodukte entwickeln und anpassen. Im nächsten Schritt sollte ein übergreifendes „QA Manifest“ entstehen, das die grundlegenden Werte für die Qualitätssicherung definiert, Empfehlungen ausspricht sowie Anleitungen und Good Practices beinhaltet.

Dabei wurden umfangreiche agile Workshops durchgeführt, um alle Teams abzuholen, gemeinsam mit dem QualityChapter der EMI ein Vorgehen erarbeitet und die Ergebnisse abschließend verprobt.
Ziel war es, einen einfachen Ansatz zu finden, der die Herausforderungen einer agilen Qualitätssicherung gemeinsam mit den Scrum-Teams angeht und dabei die Anforderungen der Stakeholder im Auge behält sowie die Kommunikation mit allen Beteiligten sicherstellt. Darüber hinaus mussten auch Wege gefunden werden, um Anforderungen der Qualitätssicherung in einem skalierten Umfeld effektiv umzusetzen.

Im Vortrag werden die Ergebnisse vorgestellt, aber besonders wird auf die Erkenntnisse und Überraschungen eingegangen, die während der Workshops, Interviews und Arbeit mit allen Beteiligten auftauchten.

Projected learning outcomes / lessons learned for participant:

* Good Practices und Hinweise für agile Qualitätssicherung im komplexen Umfeld
* Ansätze für kollaborative und verteilte Workshops mit vielen Teilnehmern und vielen Teams
* Vorstellung der Schwerpunkte für spezielles Projekt
* Individuelle Ansätze für agiles Testen im skalierten Umfeld
* Einführung (Vorstellung des Projektes und der Aufgabenstellung)
* Erste Schritte (Schulungen, kollaborative und verteilte Workshops mit 20 Teams zur Aufnahme des IST-Standes)
* Gemeinsame Erarbeitung des Testvorgehens (Vorgaben, Anleitung, Good Practices, Definition von gemeinsamen Arbeitspaketen)
* Umsetzung des Testvorgehens (Coaching der Teams, Erarbeitung der gemeinsamen Arbeitspakete)
* Abschluss (Erkenntnisse und Ausblick)

Kay Grebenstein arbeitet als Head of QA für die Business Line Manufacturing Solutions bei der ZEISS Digital Innovation. In seiner Zeit als Testmanager und agiler QA-Coach hat er in den letzten Jahren in Projekten unterschiedlicher fachlicher Domänen (Industrie, Semiconductor, Energie, …) Qualität gesichert und Software getestet.

Kay Grebenstein
Kay Grebenstein
flag VORTRAG MERKEN

Vortrag Teilen

Zurück