Die im Konferenzprogramm der OOP 2022 Digital angegebenen Uhrzeiten entsprechen der Central European Time (CET).
Unser Programm gibt es auch als praktische PDF-Datei >>Zum Download
Die Teilnehmer erlangen aktuelle praktische Kenntnisse zur Sicherheit von Web-basierten Architekturen in Entwicklung und Einsatz, inkl. Schutzmaßnahmen und Best Practices. Insbesondere wird die kürzlich veröffentlichte Version 2021 der „OWASP Top 10 Security Vulnerabilities“ des „Open Web Application Security Project“ vorgestellt, die alle vier Jahre aktualisiert werden. Es gibt praktische Übungen mittels Open-Source-Werkzeugen für die Sicherheitsanalyse von Architekturen und Implementierungen, für die ein Laptop mitgebracht werden sollte.
Benötigte Software: SonarQube und das Microsoft Threat Modelling Tool
Maximale Teilnehmerzahl: 20
Zielpublikum: Architekt:innen, Entwickler:innen, QA-Manager, Projektleiter:innen, Product Owners
Voraussetzungen: Grundlegendes Verständnis von Webanwendungen
Schwierigkeitsgrad: Anfänger
Jan Jürjens ist Director Research Projects am Fraunhofer ISST und leitet als Professor für Software Engineering das Institut für Softwaretechnik an der Universität Koblenz. Sein Arbeitsschwerpunkt ist die Entwicklung und das Testen sicherheitskritischer Software, für die er Ansätze und Werkzeuge in Kooperation mit Unternehmen entwickelt. Er ist Autor des Buches 'Secure Software Development with UML', das auch ins Chinesische übersetzt wurde.
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 timing in testing is critical but often not explicitly tackled. Therefore, in this interactive tutorial we reflect on our current approach on timing in testing, investigate and discuss needed strategies, tactics, and practices in different areas, and share experiences and lessons learned to improve timing in testing – because it is time to act now!
Maximum number of participants: 50
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 timing in testing (“when to do what kind of testing and how?”) is critical, but often not explicitly tackled. Therefore, in this interactive tutorial we reflect on our current approach on timing in testing, investigate and discuss needed strategies, tactics, and practices in different areas, and share experiences and lessons learned to improve timing in testing – because it is time to act now!
Some of the areas in testing that are covered in the tutorial are:
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.
Gamification bringt Spaß in den Projektalltag. Aber lohnt es sich überhaupt?
Um dies einschätzen zu können, geben wir einen Überblick über verschiedene spielerische Ansätze, die auf die Qualitätssicherung von Software fokussieren.
Wir gehen darauf ein, wie man Gamification gezielt und im richtigen Maß in Projekte einführt, welche Schwerpunkte gesetzt werden sollten und wie skeptische Kollegen überzeugt werden können.
Damit kann der Vortrag als Entscheidungsgrundlage dienen. Richtig eingesetzt, lohnt sich Gamification!
Zielpublikum: Projektleiter:innen, Manager, Entscheider
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Anfänger
Extended Abstract
Spielerische Ansätze in der Software-Entwicklung sind nicht neu und finden immer häufiger ihren Platz im Projektalltag. Doch kosten diese nicht einfach nur Zeit und Geld? Bringt es überhaupt Vorteile, das Team „spielen“ zu lassen? Und wie misst man Erfolg oder auch das Scheitern einer Spielidee?
Wir zeigen am Beispiel von Gamification-Ansätzen in der Qualitätssicherung, dass diese das Potenzial haben, nicht nur den Projektalltag aufzulockern und den Teamzusammenhalt zu stärken, sondern auch die Softwarequalität spielend zu verbessern. Gezielte Produktverbesserung, z. B. durch Bug-Hunting, wird ebenso adressiert wie systematische Prozessverbesserung, z. B. durch Maturity Poker.
Voraussetzung ist, dass Gamification gezielt eingesetzt wird, um effizient zu sein. Der spielerische Ansatz muss zum Team und zum Projekt passen, Schwächen beheben und auf Lösungen für bestehende Probleme fokussieren.
Der Vortrag will eine Entscheidungshilfe geben, wann sich spielerische Ansätze lohnen und wann man eher auf sie verzichten sollte. Denn nur, wenn sich Erfolge einstellen und Gamification das Projekt voranbringt, stehen alle Beteiligten hinter dem Vorgehen, und die investierte Zeit ist nicht „verspielt".
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.
Mehr Inhalte dieses Speakers? Schaut doch mal bei SIGS.de vorbei: https://www.sigs.de/experten/dehla-sokenou/
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.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/baris.gueldali
Schon von Quarkus gehört, dem neuen und effizienten JVM-Framework? Das - nicht unerfolgreich - etablierten Frameworks wie Spring Boot Konkurrenz macht?
Und bist Du daran interessiert, wie man eine Quarkus-App erstellt und - noch wichtiger - Teile davon isoliert testet?
Interessiert? Dann lass mich von unseren Erfahrungen berichten, wie sich Quarkus-Apps mit Kotlin, JUnit und MockK testen lassen. Praktische Einblicke garantiert!
Zielpublikum: Developers
Voraussetzungen: Basic knowledge about JVM languages, JVM frameworks and the microservice architecture pattern
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract
Das relativ junge Quarkus konnte sich zu einem ernst zu nehmenden Konkurrenten für etablierte Microservice-Frameworks wie Spring Boot entwickeln. Das liegt insbesondere daran, dass das leistungsfähige und dennoch leichtgewichtige JVM-Framework es schafft, Startzeiten und Speicherverbrauch von Anwendungen erheblich zu reduzieren. Damit ist es nicht nur für die Entwicklung von Microservices in containerisierten Cloud-Plattformen wie Kubernetes interessant, sondern auch für Serverless Computing.
Und es unterstützt meine Lieblings-Programmiersprache: Kotlin!
Wenn man eine Anwendung mit Quarkus und Kotlin entwickelt, kommt man früher oder später (hoffentlich früher ;-) ) nicht umhin, isolierte Tests zu schreiben. Nur so lässt sich bekanntermaßen automatisiert feststellen, ob sich der Anwendungscode wie erwartet verhält. Und als Kotlin-Entwickler will man dazu bekannte Technologien wie z. B. JUnit und MockK nutzen. Es gibt dabei aber einige wesentliche Aspekte, die beim Testen und Mocking von CDI-Beans in Quarkus beachtet werden müssen.
Interessiert? Dann habt teil an unseren Erfahrungen, wie sich Quarkus-Apps mit Kotlin, JUnit und MockK testen lassen. Praktische Einblicke garantiert!
Vortrag Teilen
Vortrag Teilen
<provocative statement>Manuelles Testen ist die Abarbeitung einzelner definierter Testschritte. Hierfür benötigt es keine speziellen Skills, wir brauchen nur Click-Monkeys – oder?!</provocative statement
<mind change>Falsch! Wir müssen den Menschen in den Fokus stellen. Manuelles Testen sollte vielmehr als “Human Testing” betrachtet werden. Die Tester:innen nutzen all ihre Stärken zum Durchführen der Tests - eigenständiges Denken, neue Ideen entwickeln, sowie kollaborative Ansätze stehen hierbei im Zentrum des „Human Testing“.</mind change>
Zielpublikum: Tester:innen, Testmanager, Product Owner, Scrum Master, Stakeholder
Voraussetzungen: Grundlegende Kenntnisse im Testing
Schwierigkeitsgrad: Anfänger
Extended Abstract
In vielen Projekten erleben wir immer mehr, dass manuelles Testen nur als Abarbeitung diverser Testfälle gesehen wird. Hierfür werden lediglich “dumme” Click-Monkeys benötigt, Tester:innen die Testfälle Schritt für Schritt durchführen und diese nicht hinterfragen.
Aus unserer Erfahrung ist dies ein Unding, setzt die Leistung der Tester:innen herab und verschwendet wertvolle Ressourcen. Die einfache Abarbeitung von Testschritten kann in der Regel automatisiert werden.
Durch den erhöhten Automatisierungsgrad wird mehr Kapazität für den/die Tester:in geschaffen. Manuelles Testen suggeriert die oben beschriebene Abarbeitung einzelner Testschritte, wohingegen Human Testing mehr den Wert des Menschen in den Mittelpunkt rückt. Hierbei kann er/sie seine/ihre Stärken voll ausspielen und zum Beispiel in Testing Sessions auch mal über den Tellerrand hinausschauen, um eigenen Testideen zu folgen oder sich in Themen zu explorieren (beispielsweise via Testing Touren).
Human Testing rückt nicht nur den Menschen in den Mittelpunkt, sondern drückt auch die Wertigkeit des Testens aus. Es ist eben nicht nur die Durchführung manueller Testfälle, sondern vielmehr eine vertrauensvolle Zusammenarbeit mit Fokus auf Qualität.
In unserem Vortrag erläutern wir zum einen die Vorurteile gegenüber manuellem Testen, die uns in unzähligen Projekten begegnet sind, sowie mögliche Ansätze, wieso das manuelle Testen zukünftig als Human Testing zu betrachten ist. Ebenso zeigen wir auf, welchen Standard wir im Testing zwingend erreichen müssen, so dass die Rolle des Testers den verdienten Respekt erhält.
Maria Petzold coacht gerne Projektkolleg:innen zu allen QA relevanten Themen. Gerne verwendet sie hierbei auch neue Ansätze, so z. B. die Einführung explorativer Testmethoden im regulierten Umfeld.
Benedikt Wörners Leidenschaft ist es, Kunden bei der agilen Transformation zu helfen. Er eröffnet den Kunden neue Wege und Perspektiven, z. B. anhand explorativer und kollaborativer Testmethoden.
Vortrag Teilen
Wenn ein System wächst, wächst auch die Anzahl automatisierter Tests. Wir sehen immer öfter Test-Suiten, die Stunden oder Tage laufen. Das ist lähmend langsam. Wenn die Ausführung aller Tests zu lange dauert, kann man einen Teil der Tests häufiger ausfü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 stellen wir verschiedene Ansätze hinsichtlich Kosten, Nutzen und Anwendbarkeit und Erfahrungen aus Forschung und Praxiseinsatz vor.
Zielpublikum: Entwickler:innen, Tester:innen, Verantwortliche für Entwicklung und Test
Voraussetzungen: Interesse an Software-Test
Schwierigkeitsgrad: Fortgeschritten
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 Problemen mit sich. Für die Entwickler bedeutet es, dass sie Feedback für den geänderten Code erst eine lange Zeit, nachdem sie die Änderungen gemacht haben, bekommen. Das macht es deutlich schwieriger, die Fehler im Code zu finden und zu beheben. Außerdem werden moderne Verfahren, wie zum Beispiel Continuous 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 Fähigkeit der Tests, Fehler zu finden, 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 verwendet, wie testfallspezifische Coverage [1] und Ausführungszeit, 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 neuen 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,
[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)
Dr. Elmar Jürgens 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 Teams bei der Verbesserung ihrer Qualitätssicherungs- und Testprozesse. Jürgens spricht regelmäßig auf Forschungs- und Industriekonferenzen und wurde für seine Vorträge mehrfach ausgezeichnet. Er wurde 2015 zum Junior Fellow der Gesellschaft für Informatik ernannt.
Vortrag Teilen
Der effektive Einsatz einer Testautomatisierungslösung steht und fällt mit den verwendeten Werkzeugen. In dem Vortrag stellen wir die Ergebnisse einer wissenschaftlichen Arbeit zur Erstellung eines Kriterienkataloges für die Auswahl des passenden Testautomatisierungswerkzeugs für unsere Projekte vor. Dabei wurden die Kriterien und deren Gewichtung nach Vorgehensmodellen, Technologie, Einsatzgebiet sowie dem Blickwinkel der Rollen evaluiert. Die Anwendung des Kriterienkatalogs soll leichtgewichtig sein und Vorgaben des agilen Manifests befolgen.
Zielpublikum: Tester:innen, Agile Teams, Testmanager:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheider
Voraussetzungen: Grundkenntnisse Testen/Testautomatisierung, Projekterfahrung, Fachkenntnisse agile Methoden
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract
Der effektive Einsatz einer Testautomatisierungslösung steht und fällt mit den verwendeten Werkzeugen. Für die gezielte Auswahl der Werkzeuge und besonders für die Begründung gegenüber dem Management benötigen Projekte daher einen Katalog von Kriterien. Dabei unterscheiden sich die Kriterien bzw. deren Gewichtung je nach Einsatzgebiet, Vorgehen, Technologie und besonders der Rolle des Betrachters.
In dem Vortrag stellen wir die Ergebnisse einer wissenschaftlichen Konzeption eines Kriterienkataloges für die Auswahl der passenden Testwerkzeuglösung im Rahmen der Testautomatisierung für die ZEISS Digital Innovation vor. Dabei wurden die Kriterien und deren Gewichtung unter anderem nach den verwendeten Vorgehensmodellen (Agile, Scaled, Klassisch), der verwendeten Technologie, dem Einsatzgebiet sowie den Blickwinkeln der unterschiedlichen Rollen evaluiert.
Als Endergebnis soll es möglich sein, passende Testautomatisierungstestwerkzeuge je nach Projekteinsatz anhand des Kriterienkatalogs evaluieren bzw. empfehlen zu können. Durch die flexible Entscheidungsvorlage soll sichergestellt werden, dass die im Kundenprojekt eingesetzten Testwerkzeuge allen relevanten Anforderungen des Projekts, aber auch des Unternehmens entsprechen. Dabei soll die Anwendung des Kriterienkatalogs leichtgewichtig sein und besonders die Vorgaben des agilen Manifests befolgen.
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.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Kay.Grebenstein
Ich binConsultantim Bereich SoftwareTestingbei ZEISS Digital Innovation,Berlin. Parallel zum einem kürzlich abgeschlossenen Wirtschaftsinformatik-Studium habe ich in der Qualitätssicherung in verschiedenen Projekten gearbeitet und bin so zum bekennenden QA-Fan geworden. Besonderen Wert lege ich auf agile Vorgehensweisen, kreative und kollaborative Methoden. Durch Teilnahme an Konferenzen und Meet ups baue ich mein Wissen und meine Fähigkeiten im professionellen Umfeld weiter aus.
Vortrag Teilen
(Agile) Games are sounding throughout the land. Everyone plays games and anyone guides games. However, what makes playing games "interesting" from the business owner's perspective?
We look into the criteria of effectiveness and efficiency of games and thus the capabilities of creating business impact for the company.
As such, it turns out a game - is just a game and remains a play if one does not align with underlying business needs. Sounds familiar? But you wonder how to do so?
In this talk, we will look in a 4-Step-Modelmaking the obvious tangible. And in the end, it becomes a structured approach how one might create business impact too.
Target Audience: Moderators, (young) Scrum Masters, Project Leaders, Managers, Decision-Makers, Facilitators
Prerequisites: General understanding of games and agility, and how to lead games successfully
Level: Basic
Ihr Motto „You go first! – Nimm dein Leben in die Hand!", steht für ihr Tun: Rein in den nachhaltigen Erfolg durch Eigenverantwortung und Selbstführung.
Anne Hoffmann unterstützt Menschen und Organisationen dabei, erfolgreich ihre Ziele zu erreichen. Als Expertin für Selbstführung und mit ihrem Motto „You go first!“ erinnert sie daran, dass nachhaltiger Erfolg durch hohe Eigenverantwortung insbesondere dann entsteht, wenn diese Selbstführung vorgelebt wird.
Anne benutzt oft Spiele, um Erkenntnisse weiterzugeben.
So many challenges, so little time. As testers or quality engineers, we need to sharpen the saw, but how? Gamification can be a way to look at how you're doing and find out where to improve. It's a great way to have everyone engaged and get the best out of people.
In this presentation, Ben Linders will show how playing games (onsite or online) with the Agile Testing Coaching Cards and Agile Quality Coaching Cards help to explore your current quality and testing practice and decide as a team on what to improve or experiment with.
Target Audience: Testers, Agile Teams, Tech Leads, Technical Coaches, Scrum Masters
Prerequisites: None
Level: Advanced
Extended Abstract
The Agile Testing Coaching Cards and Agile Quality Coaching Cards are a deck of cards with statements that help people to share and reflect. Examples of cards are "Testers help developers design acceptance criteria for user stories", "Failing tests get proper attention even when no defect in the product has been detected", and "Refactoring is done to keep code maintainable and reduce technical debt".
Playing games with these coaching cards (onsite or online), you can learn from each other. Teams can use the coaching cards to discuss quality and testing values, principles, and practices, and share their experiences and learnings.
Different game formats can be used to share experiences on testing and quality principles and practices and explore how they can be applied effectively. The playing formats from the Agile Self-assessment Game (benlinders.com/game) can be used to play with these cards. This presentation provides an overview of playing formats and will inspire you to come up with your own formats.
Facilitation is key when playing with these coaching cards. Ben Linders will present how to prepare a game session and facilitate it, what can be done to keep people engaged, and how debriefing can help to pull out learnings and ideas for improvement.
Takeaways:
- Show how to use gamification to self-assess your current way of working.
- Present examples of playing games with the Agile Testing Coaching Cards and Agile Quality Coaching Cards.
- Explore how facilitating games can help to enhance quality and testing in agile teams.
To continuously deliver IT systems at speed with a focus on business value, high-performance IT delivery teams integrate quality engineering in their way of working.
Quality engineering is the new concept in achieving the right quality of IT systems. Testing only after an IT product was developed is an outdated approach. Built-in quality from the start is needed to guarantee business value in today’s IT delivery models. Quality engineering is about changes in skills, organization, automation and quality measures.
Target Audience: All people involved in high-performance IT delivery teams
Prerequisites: General knowledge of IT delivery
Level: Advanced
Extended Abstract
To continuously deliver IT systems at speed with a focus on business value, high-performance cross-functional IT delivery teams integrate quality engineering in their way of working.
Quality engineering is the new concept in achieving the right quality of IT systems. Testing an application only after the digital product has been fully developed has long been a thing of the past. More is needed to guarantee the quality of applications that are delivered faster and more frequently in today’s high-performance IT delivery models. It is about achieving built-in quality. The road to quality engineering means changes in terms of starting points, skills, organization, automation and quality measures.
Our new VOICE model guides teams to align their activities with the business value that is pursued, and by measuring indicators, teams give the right information to stakeholders to establish their confidence that the IT delivery will actually result in business value for the customers.
Teams benefit from the clear definition of QA&Testing topics that are a useful grouping of all activities relevant to quality engineering. Organizing topics are relevant to align activities between teams and performing topics have a focus on the operational activities within a team.
Also, to be able to deliver quality at speed, for today’s teams it is crucial to benefit from automating activities, for example in a CI/CD pipeline, whereby people must remember that automation is not the goal but just a way to increase quality and speed.
In this presentation the audience will learn why a broad view on quality engineering is important and how quality engineering can be implemented to achieve the right quality of IT products, the IT delivery process and the people involved.
This presentation is based on our new book "Quality for DevOps teams" (ISBN 978-90-75414-89-9) which supports high-performance cross-functional teams in implementing quality in their DevOps culture, with practical examples, useful knowledge and some theoretical background.
Rik Marselis is principal quality consultant at Sogeti in the Netherlands. He is a well-appreciated presenter, trainer, author, consultant, and coach in the world of quality engineering. His presentations are always appreciated for their liveliness, his ability to keep the talks serious but light, and his use of practical examples with humorous comparisons.
Rik is a trainer for test design techniques for over 15 years.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/rik.marselis
In large software projects the assessment of the impact of a code change can be a cumbersome task. If the software has grown and shows an evolutionary design there are always unwanted side effects.
Change control boards are established. But on what data do they judge what can happen with the changes? Very often there is the HIPPO syndrome which means it is the highest paid person's opinion.
In this talk we will show you ways to come to a deterministic prediction of the impact, what data you need and what you can do with it.
Target Audience: Architects, Test Managers, Developers, Testers
Prerequisites: Basic knowledge of collected data in software projects
Level: Advanced
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 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.
Die Praxis in den agilen Teams ergibt immer größeren Bedarf an grundlegenden Testfähigkeiten auch für klassische Entwicklerrollen. Aber oft fehlen die entsprechenden Expertisen und die Akzeptanz für das Testen. Nötig ist eine stärker ausgeprägte Kultur des Testens als Schlüsselfaktor für den Erfolg agiler Projekte. Daher wurde vom GTB auf Basis des etablierten „Certified Tester“-Quasistandards für Testing-Skills ein auf die Bedürfnisse von Entwicklern zugeschnittener Kanon an Testwissen und ein praxisbezogener Kurs als Hilfestellung definiert.
Zielpublikum: Entwickler & Tester, Architekt:innen, Productmanager:innen, DevOps, Qualitätsmanager:innen, Entscheider, Human Resource
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger
Extended Abstract
Agil ist weiter auf dem Vormarsch und aus unserer Praxis wissen wir, dass gerade in der agilen Welt die Komplexität der Aufgaben im Team und Anforderungen an die Qualität der Produkte stetig und rasant zunehmen. Schnelle Entwicklungszyklen und Technologien wie KI, Machine Learning und IoT erhöhen den Druck auf die Projekte.
In den agilen Projekten werden Entwickler:innen zunehmend mit Testaufgaben betraut und Tester:innen zunehmend mit der Entwicklung von Testautomatisierung. Daher ergibt sich in den Teams ein wachsender Bedarf an grundlegenden Testfähigkeiten auch für die klassischen Entwicklerrollen im Team. Allerdings weisen viele agile Projekte missionskritische Lücken in der Qualitätssicherung auf. Zwei Schwerpunkte sind hier entscheidend: fehlende Akzeptanz für das Testen in den agilen Teams und oft fehlende Testexpertisen.
Um dies zu adressieren und zu verbessern, benötigen wir ein stärkeres Bewusstsein für die Herausforderungen und Fallstricke und eine stärker ausgeprägte Kultur einer Qualitätssicherungs-Community. Wir sehen deutlichen Bedarf an Verbesserung der Testexpertisen über alle Testaspekte und Teststufen als Schlüsselfaktor, Produkte nachhaltig und erfolgreich agil zu entwickeln. Was wir in anderen Worten ermöglichen müssen: Entwickler:innen können testen und Tester:innen können Automatisierung entwickeln. Und wir benötigen dafür die nötige Unterstützung aus dem Management.
Aber welche Testthemen sind zu stärken oder überhaupt zu etablieren? Und welche Testexpertisen werden dafür benötigt? Basierend auf dieser Frage wurde vom GTB (German Testing Board e.V.) ein auf die Bedürfnisse von Entwickler:innen zugeschnittener Kanon an Testthemen und Testexpertisen definiert. Dieser Kanon soll Entwickler:innen die Möglichkeit geben, die für die Erstellung der Software benötigten Kenntnisse über Testgrundlagen systematisch aufzubauen und zu erweitern.
Darauf basierend hat GTB auch einen Lehrplan "A4Q Testing Foundations for Developers" auf Basis des seit vielen Jahren etablierte Quasistandards des „ISTQB® Certified Testers“ entwickelt. In dem Lehrgang wird auch auf Hands-on-Aspekte viel Wert gelegt, d.h. es wird auch programmiert. Kanon und Kurs sind als Handreichung zu verstehen, Akzeptanz für das Thema Testen und die nötige Systematik der Testexpertisen im Team zu stärken. Die damit gewonnene gemeinsame Sprechweise hilft auch dabei, dass sich Entwickler:innen und Tester:innen bei ihrer Arbeit noch besser verstehen.
Dr. Armin Metzger hat über 25 Jahre Erfahrung in Software-Entwicklung und -test in Industrie- und Forschungsprojekten und internationalen Gremien. Seit 2018 ist er Geschäftsführer des German Testing Board.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/armin.metzger
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.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/erhardt.wunderlich
Vortrag Teilen
Metamorphes Testen ist ein relativ neues Testverfahren, das sich besonders gut eignet, wenn kein ausreichendes Testorakel verfügbar ist. Metamorphes Testen betrachtet mehrere Ausführungen des Testobjekts und prüft, ob die Eingaben und Ausgaben bei diesen Ausführungen zueinander konsistent sind. Der Beitrag stellt das Verfahren vor, gibt einen Überblick über die bisherigen Erfahrungen bei klassischen und bei KI-basierten Systemen und ordnet es in die Testmethodik ein.
Zielpublikum: Softwaretester:innen
Voraussetzungen: Certified Tester Foundation Level
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract
Es kann schwierig sein festzustellen, ob die Ausgaben eines Testfalls korrekt sind. Ein Beispiel ist die Suche nach einem gängigen Text in einem großen Datenbestand. Eine Abhilfe kann sein, die Textsuche durch zusätzliche Filterkriterien einzuschränken und zu prüfen, ob das Suchergebnis eine Teilmenge des Ergebnisses der ursprünglichen Suche ist. Metamorphes Testen ist ein Testverfahren, das diesen Ansatz systematisiert. Es betrachtet mehrere Ausführungen des Testobjekts und prüft, ob die Eingaben und Ausgaben bei diesen Ausführungen zueinander konsistent sind. Die Konsistenzbedingungen werden meist aus der Spezifikation gewonnen.
Erfüllt das Testobjekt bei einer Gruppe von Testfällen eine Konsistenzbedingung nicht wie erwartet, so wurde eine Fehlerwirkung gefunden. Der Beitrag stellt das Verfahren vor, gibt einen Überblick über die bisherigen Erfahrungen bei klassischen und bei KI-basierten Systemen und ordnet es in die Testmethodik ein.
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.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/matthias.hamburg
Vortrag Teilen
In den 1960er Jahre entwickelte die NASA eine Methode zur Sicherstellung von Lebensmittelqualität: die Gefahrenanalyse der kritischen Kontrollpunkte nach HACCP. Diese Methode inspirierte mich zu einem Workshop, der über Teamgrenzen hinweg gemeinsam einen Blick auf die Qualität unseres Produkts wirft.
In meinem Vortrag zeige ich Ihnen, wie ich als ursprünglich gelernter Koch, heute in der Rolle des Qualitätsmanagers, instinktiv Methoden der Lebensmittelhygiene anwende. Mit dem Ziel, welches wir alle möchten: die Qualität des Produkts!
Zielpublikum: Prozessverantwortliche, Testmanager:innen, Qualitymanager:innen, Entwickler:innen, Manager, Entscheider
Voraussetzungen: Keine besonderen Vorkenntnisse nötig
Schwierigkeitsgrad: Anfänger
Extended Abstract
Zu Beginn der 1960er Jahre entwickelte die NASA eine Methode zur Sicherstellung von Lebensmittelqualität. Diese Methode inspirierte mich zu einem Workshop, der über Teamgrenzen hinweg, gemeinsam einen Blick auf die Qualität unseres Produkts wirft.
In meinem Vortrag zeige ich Ihnen, wie ich als gelernter Koch instinktiv Methoden der Lebensmittelhygiene anwende. In der Rolle als Qualitätsmanager führte ich Workshops durch, die unseren Entwicklungsprozess entscheidend veränderten – mit Methoden aus der Gastronomie.
Die Gefahrenanalyse der kritischen Kontrollpunkte nach HACCP (hazard analysis and critical control points) ist bis heute eine gesetzlich vorgeschriebene Methode in der Lebensmittelindustrie und Gastronomie, um die Qualität (Hygiene) von Lebensmittel-Produkten sicherzustellen. Diese Methode war der Ausgangspunkt für den Prozessanalyse-Workshop Quality Storming. Der, für Software-Entwicklung erdacht, in den Jahren immer mehr verbessert wurde.
Ich zeige Ihnen, wie Sie mit drei verschiedenen Quality Storming-Varianten die Hygiene ihrer Entwicklungsprozesse entscheidend verbessern können. Wir schauen gemeinsam, warum permanente Temperaturkontrollen von Tiefkühlpizza die gleichen Ziele haben wie Softwaretests in der Entwicklung: die Qualität des Produkts!
Als Quality Evangelist lautet Georg Haupts Motto: „Aus der Praxis für die Praxis!“ Denn als Test- und Qualitäts-Management-Experte blickt er auf 20 Jahre praktische Erfahrung für sowohl agile als auch klassische Soft- und Hardwaretests zurück. Weitere Schwerpunkte sind: Test-Automatisierung, Test-Analyse sowie Security-Tests. Hierbei liegen ihm besonders teamübergreifende und agile Qualitätssicherung am Herzen.
Georg Haupt legt hohen Wert auf eine ausgewogene Mischung aus manuellen, explorativen und automatisierten Tests. Das Entwickeln und Etablieren von Testmethoden und Prozessen ist für ihn langjährige Praxis. Darüber hinaus bietet Georg Haupt praktische Erfahrung in der Einführung von teamübergreifenden Test- und Testmanagementwerkzeugen und Prozessen.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/georg.haupt
Data technical debt refers to quality challenges associated with legacy data sources, including both mission-critical sources of record as well as “big data” sources of insight. Data technical debt impedes the ability of your organization to leverage information effectively for better decision making, increases operational costs, and impedes your ability to react to changes in your environment. The annual cost of bad data is in the trillions of dollars, this problem is real and it won't go away on its own.
Target Audience: Developers, Data Professionals, Managers, Architects
Prerequisites: Understanding of basic data terms
Level: Basic
Extended Abstract
Data technical debt refers to quality challenges associated with legacy data sources, including both mission-critical sources of record as well as “big data” sources of insight. Data technical debt impedes the ability of your organization to leverage information effectively for better decision making, increases operational costs, and impedes your ability to react to changes in your environment. Bad data is estimated to cost the United States $3 trillion annually alone, yet few organizations have a realistic strategy in place to address data technical debt.
This presentation defines what data technical debt is and why it is often a greater issue than classic code-based technical debt. We describe the types of data technical debt, why each is important, and how to measure them. Most importantly, this presentation works through Disciplined Agile (DA) strategies for avoiding, removing, and accepting data technical debt. Data is the lifeblood of our organizations, we need to ensure that it is clean if we’re to remain healthy.
Learning objectives:
• Discover what data technical debt is
• Understand the complexities of data technical debt and why they’re difficult to address
• Learn technical and management strategies to address data technical debt
Scott Ambler is the Chief Methodologist of Ambysoft Inc. He is the creator of the Agile Modeling and Agile Data methods, as well as co-creator of PMI's Disciplined Agile tool kit. He has worked with organizations around the world to improve their software development ways of working (WoW). Scott is an award-winning author of 20+ books and an international keynote speaker.
Each project has its own unique technology stack, different business logic and a unique team. The definition of quality in our projects can vary greatly. However, there are good practices that will work everywhere. There are steps that can be taken in every project and team to produce the software of better quality. I will tell you how to improve communication and processes, and what tools we can use not to be ashamed of the fruits of our work. Everything from a programmer's perspective.
Target Audience: Developers and Tech/Project Leaders
Prerequisites: Some experience in profesional software development
Level: Advanced
Extended Abstract
Each project has its own unique technology stack, different business logic and a unique team. Some of us work on mature products that have been in production for many years. Others are constantly struggling to innovate in the race against time. The definition of quality in our projects can vary greatly. However, there are good practices that will work everywhere. There are steps that can be taken in every project and team to produce the software of better quality. I will tell you how to improve communication and processes, and what tools we can use not to be ashamed of the fruits of our work. Everything from a programmer's perspective.
“TDD is when you write tests before implementing the business logic” - a simple sentence that is also often misunderstood.
Moving from one project to another, I have observed how many times people were terrified of TDD. I have been there too.
This session will focus on trying to understand HOW and more importantly WHY you should consider TDD. I've transformed failures from my experience into a series of lessons learned, things that in hindsight should have been obvious.
Target Audience: Architects, Developers
Prerequisites: Basic knowledge in testing techniques
Level: Basic
Vortrag Teilen
Vortrag Teilen
Test case design is one of the core competences of the testing profession. This tutorial is about an effective and elegant technique that is still too little known.
After an overview presentation of test design using coverage-based test design techniques and experience-based test approaches, this tutorial addresses one of the (seemingly) harder techniques from the condition-oriented group of coverage-based test design techniques, the Elementary Comparison Test (ECT) that uses Modified Condition Decision Coverage (MCDC).
Target Audience: Quality Engineers, Test Engineers, Developers
Prerequisites: General knowledge of IT delivery, quality engineering and testing
Level: Advanced
Extended Abstract
Test case design is one of the core competences of the testing profession.
Which test design techniques do you use? And is this effective and efficient?
In the TMAP body of knowledge we distinguish 4 main groups of test design techniques: Process-oriented (such as path testing), Condition-oriented (such as decision table testing), Data-oriented (such as Data Combination test) and Appearance-oriented (such as Syntactic testing and performance testing).
After an overview presentation of test design using coverage-based test design techniques and experience-based test approaches, this tutorial addresses one of the (seemingly) harder techniques from the condition-oriented group of coverage-based test design techniques, the Elementary Comparison Test that uses Modified Condition Decision Coverage.
Suppose you must test the entry-check of the new Wuthering Heights Rollercoaster in the QualityLand amusement park. Every person must be at least 120 cm tall to be allowed in the rollercoaster. What technique would you use? Boundary Value Analysis (from the group data-oriented testing), right? That’s not a tough choice.
But now the marketing department of QualityLand has a special offer for Halloween. To be allowed with the special discount-rate, a person must still be at least 120 cm tall, but must also wear a Halloween outfit and needs to be at the gate on 31 October (that’s a decision with 3 conditions). On top of this, if the person has bought a ticket online, and paid 10% extra, they may skip the line (that’s another decision, with 2 conditions).
So, all in all you have 2 decision points, with together 5 conditions.
Now what test case design technique do you use?
In the above example (with 5 conditions) choose a condition-oriented test design technique. But which? Probably you know Decision Table Testing. Applying this technique would lead to 2-to-the-power-of-5 = 32 test cases. That’s a bit too much to call this an efficient test set.
My advice is to use the Elementary Comparison Test (ECT) design technique, together with Modified Condition Decision Coverage (MCDC). This way, with only 6 (!!) test cases you can guarantee that EVERY condition has contributed to trigger EVERY outcome of the entry-check of the rollercoaster. So, it is both effective and efficient!
Have you never heard of ECT before? Well, even though it exists for decades, I can imagine, because ISTQB doesn’t teach you this. But is has been part of the TMAP body of knowledge since 1995 :-)
This HUSTEF conference you will get your chance to learn all about ECT & MCDC!!
Join me in this half-day or full-day tutorial and I will make sure that you will get hands-on experience.
Rik Marselis is principal quality consultant at Sogeti in the Netherlands. He is a well-appreciated presenter, trainer, author, consultant, and coach in the world of quality engineering. His presentations are always appreciated for their liveliness, his ability to keep the talks serious but light, and his use of practical examples with humorous comparisons.
Rik is a trainer for test design techniques for over 15 years.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/rik.marselis