Um die Auswahl zwischen den parallel laufenden Vorträgen und Workshops zu vereinfachen, geben die Sprecherinnen und Sprecher einen kurzen Teaser zu Ihrer Session.
Many organizations struggle to adopt 'agile' in a way that delivers on its promise to make the company fast, flexible and efficient. Global consultancy firms have great pitches on how to adopt different so-called 'Agile frameworks'. The marketing is great, but are the results too? We see how our clients get stuck in adopting a framework - forming 'agile teams', appointing 'product owners' and then clustering all this into 'tribes'. Thus creating robust structures that make further organizational improvements and adaptability difficult, slow, and expensive. This talk offers ideas how to go beyond these limiting ideas.
Target Audience: executives + agile coaches / consultants / scrum masters / internal change agents with a mandate for real change
Prerequisites: none
Level: Advanced
Alexey Krivitsky has been a developer, scrum master, conference producer, and speaker. He has written several books and is the inventor of lego4scrum. He is a Certified Scrum Trainer (CST) and works as an organization agility coach.
Alexey is known in the industry because of the success of lego4scrum that he invented.
He has been using Scrum since 2005, he is probably the first Scrum master of Ukraine. In 2007, together with a group of 'interested', he acted as the inspirer of the Agile Ukraine community. So in Ukraine they began to talk about flexible development. It all started with a Google group. Then a dozen half-day free conferences throughout Ukraine. The wave went rolling.
Since 2008, he has been actively appearing in the arena of the Agile community as a conference producer and speaker. Since the same year - an independent agile consultant, perhaps also the first in Ukraine.
Roland Flemm (PST) became a Scrum Master in 2009 closing his 20-year career as a developer and infrastructure specialist. Roland grew into international agile consulting with a focus on large scaled Scrum adoptions since 2015. He has been actively appearing in the Agile community as a conference speaker.
He started in 1984 as a Cobol and Ideal/Datacom developer. In 2001 he moved to the support and maintenance field and worked with mostly IBM Application Server products.
In 2009 he switched to a new career in Scrum and Agile. He is now a proud member of the 350 globally certified Professional Scrum Trainers for scrum.org. His main focus is Agile organization design coaching and he supports agile adoptions in various industries. The core of his approach is to put people first, learn by doing and innovate with common sense.
Vortrag Teilen
Mehr Inhalte dieses Speakers? Kein Problem, schaut doch mal bei sigs.de vorbei:
https://www.sigs.de/autor/Christian_Kram
Pair und Ensemble Testing haben ihren festen Platz im agilen Testens. Der Fokus liegt auf einer kollaborativen Testdurchführung. Aber wie kann man gemeinsam andere Testaktivitäten angehen? Hier kommen nun die Liberating Structures ins Spiel, deren Hauptaugenmerk darauf liegt, alle Anwesenden gleichermaßen zu involvieren. In diesem Workshop werden Liberating Structures praktisch erfahren. Wir werden in der Gruppe zusammen Lücken und Unzulänglichkeiten im Testprozess aufdecken, Ideen generieren, um diese Punkte zu adressieren, strukturiert nach Hilfe und Input für Testanalyse und Testspezifikation fragen und eine Teststrategie erstellen.
Max. Teilnehmendenzahl: 24
Zielpublikum: Tester:innen, Test Manager:innen, Test Coaches, Scrum Master, Agile Coaches, Projektleiter:innen
Voraussetzungen: Grundlegendes Verständnis von Softwareentwicklung, Interesse an neue Kollaborationsformaten
Schwierigkeitsgrad: Basic
Extended Abstract:
Pair und Ensemble Testing haben ihren festen Platz im Kanon des agilen Testens. Ihr Hauptaugenmerk liegt auf einer kollaborativen Testdurchführung.
Aber wie kann man gemeinsam andere Aktivitäten rund um das Thema Testen abgehen?
Hier kommen nun die Liberating Structures ins Spiel. LS (http://www.liberatingstructures.com) sind ein Werkzeugkasten zum Moderieren von Terminen und Workshops, deren Hauptaugenmerk darauf liegt alle Anwesenden gleichermaßen zu involvieren und nicht nur diejenige, die gerne ihre Stimme hören.
In diesem Workshop werden Sie Liberating Structures nicht nur theoretisch kennenlernen, sondern auch praktisch erfahren. Wir werden eine Abfolge von Structures erleben, die das Wissen der gesamten Gruppe rund um das Thema Testen anzapft. Sie werden Structures kennenlernen, die bei folgenden Punkten helfen:
All dies wird in einen hochkollaborativen Format stattfinden, dass die Beteiligung aller unterstützt und dabei gängige Probleme wie den HiPPO Effekt zu vermeiden sucht. Ziel ist es, in diesem Workshop
Liberating Structures zu erleben und zu sehen, wie in kurzer Zeit großartige Ideen entstehen. Wir werden Kollaborationswerkzeuge dort nutzen, wo sie sinnvoll sind, das Hauptaugenmerk wird jedoch auf dem Gruppenerlebnis liegen.
"Als Trainer und Berater liegen meine Schwerpunkte im Bereich der Qualitätssicherung und Softwaretests.
Über zehn Jahre habe ich in verschiedenen Rollen - vom manuellen Tester in der vergleichenden Warenprüfung über Testmanager im Automobilsektor bis zum Abteilungsleiter Test für ERP-Software - dazu beigetragen, dass die Kunden die Qualität bekommen, die sie benötigen. Meine Themenschwerpunkte liegen im Bereich des agilen Testens, des explorativen Testens und dem Verankern von Qualitätsbewusstsein im gesamten Softwareentwicklungsprozess.
Auch privat lassen mich die Rollen Trainer und Coach seit über 20 Jahren nicht los, wenngleich es dann nicht um Softwaretests, sondern um Basketball geht."
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/experten/christian-kram/
Mehr Inhalte dieses Speakers? Kein Problem, schaut doch mal bei sigs.de vorbei:
https://www.sigs.de/autor/Anne_Kramer
Modellbasierte Testansätze gibt es seit Jahren. Eine Weile war das Interesse groß. Dann kam Ernüchterung. Zu technisch, zu kompliziert - ein Thema für Experten. Nun ist die Zeit reif für die Rückkehr der Modelle. Anders als früher steht heute die Klärung von Anforderungen im Vordergrund. 'Visual ATDD' ist eine schlanke Form des MBT und folgt dem Shift-Left-Prinzip.
Doch auch Visual ATDD erfordert Abstraktionsvermögen, was in diesem Tutorial geübt wird. Gemeinsam werden wir in Jira Testszenarien visualisieren und daraus Testfälle zusammenstellen. Ziel ist, die Hemmschwelle für visuelles Testdesign zu senken und die Vorteile erlebbar zu machen.
Zielpublikum: Tester:innen, Product Owner, Testmanager:innen, Projektleiter:innen
Voraussetzungen: idealerweise Laptop und Internetzugang; es geht aber auch ohne
Schwierigkeitsgrad: Basic
Extended Abstract:
'Modellbasierter Test? Um Gottes Willen! Das ist nur was für Fortgeschrittene. Wir haben ganz andere Probleme im Test.'
Vielleicht ist es menschlich, dass wir uns darauf konzentrieren, Symptome zu beheben, anstatt Ursachen zu bekämpfen. Wir erhöhen die Deiche, anstatt das Wasser daran zu hindern, auf kürzestem Wege in die Flüsse zu laufen. Wir perfektionieren die Behandlung von Diabetes II-Patienten und lassen der Lebensmittelindustrie freie Hand bei der Zugabe von Fructose. Wir kämpfen mit unklaren Anforderungen und infolgedessen mit unzureichend getesteter Software und verschließen die Augen vor einfachen Lösungen.
Lean MBT ist eine solche Lösung. Lange Zeit als Thema für Spezialisten verschrien, beobachten wir heute ein Art Wiederauferstehung. Mit einem Unterschied: anders als früher steht nicht die Generierung der Testfälle aus perfekt gestalteten Modellen im Vordergrund, sondern die Klärung von Anforderungen - und zwar eingebettet in agile Vorgehensweisen. 'Visual ATDD' kombiniert Vorteile des Behavior-Driven Developments (BDD) mit denen des modellbasierten Testens. Es ist ein Shift-Left-Ansatz, der mit Fug und Recht den Titel 'Lean MBT' verdient.
Eine Schwierigkeit bleibt jedoch bestehen. Auch Visual ATDD erfordert ein gewisses Maß an Abstraktionsvermögen. Genau darum soll es in diesem Tutorial gehen. Die Teilnehmer üben, Testszenarien zu visualisieren und sich darüber mit Kollegen auszutauschen. Teilnehmer mit Laptop und Internetzugang können dazu Jira nutzen.
Während ihrer beruflichen Laufbahn in stark regulierten Branchen (E-Payment, Medizintechnik, Automotive) hat Anne einen außergewöhnlichen Erfahrungsschatz in IT-Projekten gesammelt - insbesondere in den Bereichen QS und Test. Anne gibt ihr Wissen und ihre Erfahrung mit Leidenschaft weiter, insbesondere wenn es um Testdesign-Ansätze geht, die auf visuellen Darstellungen basieren. Seit April 2022 ist Anne Global Customer Success Managerin bei Smartesting, einem französischen Hersteller von SW-Testwerkzeugen.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/experten/anne-kramer/
Mehr Inhalte dieses Speakers? Kein Problem, schaut doch mal bei sigs.de vorbei:
https://www.sigs.de/autor/Daniel.Pollig
Wenn Sie wissen möchten, was KPIs sind, wieso diese nicht das Gleiche sind wie Metriken oder SLAs und wie Sie sie strukturiert für Ihr Testing entwickeln können - dann sind Sie in diesem Kurs genau richtig!
Sie lernen Zweck und Anforderungen an KPIs kennen, wie man sie entwickelt und erfahren, wie Metriken und Geschäftsziele mit ihnen verbunden werden.
Die Grundlagen von 'soften' Quality Gates werden vermittelt und aus den erstellten KPIs abgeleitet.
Es wird aufgezeigt wie KPIs und Quality Gates im SW-Testing und der SW-Entwicklung eingeführt und regelmäßig genutzt werden sollten.
Der Praxiskurs enthält 3 Theorie- und 5 Übungseinheiten.
Max. Teilnehmendenzahl: 30
Zielpublikum: Tester, SW-Entwickler, Testmanager, Projektleiter, Product Owner
Voraussetzungen: Grundlegendes Verständnis von Software-Entwicklung und -Testen
Schwierigkeitsgrad: Basic
Daniel Pollig ist Experte für Software-QA & -Testing mit 12+ Jahren Kundenerfahrung.
Themenschwerpunkte: QA-Assessments, Beratung von Teststrategien, -organisationen sowie KPIs und Metriken auf Management-Ebene.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/experten/daniel-pollig/
Welche Themen im Open Space des GTD 2023 behandelt, werden können wir dir zum jetzigen Zeitpunkt noch nicht sagen. Denn Open Space ist, was ihr daraus macht! Bringe deine eigenen Fragen, Problemstellungen und Themen mit und diskutiere sie mit anderen Teilnehmenden. Im Vordergrund steht der lockere, aber informative Austausch untereinander. Sei dabei und gestalte den Open Space mit.
Der German Testing Day ist zurück in Frankfurt - wenn das mal kein Grund zum Feiern ist! Mischt Euch unter die Leute, kommt bei Snacks und Drinks ins Gespräch und lasst den ersten Tag schon einmal Revue passieren.
Du hast Fragestellungen, die du mit anderen Testinteressierten diskutieren möchtest? Du möchtest mit deiner Erfahrung anderen Personen eine Perspektive auf Fragen anbieten? Dann bist du beim Lean Coffee genau richtig. Denn im Lean Coffee bestimmt die Gruppe, welche Themen für wie lange diskutiert werden, um den maximalen Nutzen des Austauschs zu erreichen.
Lean Coffee ist ein strukturiertes agenda-loses Meeting-Format, bei dem die Teilnehmer:innen die Tagesordnung durch die Themen, die sie einbringen, selbst bestimmen. Trete in den Austausch mit Gleichgesinnten und diskutiere die aktuellen Themen rund um das Thema „Testen", „Qualität“ oder was auch immer in diesem Moment gerade wertvoll ist.
Um die Auswahl zwischen den parallel laufenden Vorträgen und Workshops zu vereinfachen, geben die Sprecherinnen und Sprecher einen kurzen Teaser zu Ihrer Session.
We use the word "quality" a lot. We talk about a goal of having high quality, that we have a "quality mindset" or that we build quality in, and we measure a lot of different things to be able to tell/report about that quality. But what do you mean when you say quality? And do you mean the same as your customer, the end users, or your management?
But look at the first principle of agile: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
With that in mind, why not move the focus to what value our customer is pursuing with the solution we are creating for them and figure out a way to measure whether we are delivering that value? And it is interesting from several reasons; Research from Mckinsey identifies that “On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted” so not only from a business value perspective but also from an economical point of view this would be a valuable focus for our customers, and therefor also for us.
Gitte Ottosen is a test manager and agile/quality coach with a strong focus on a value driven approach to software development. She has more than 25 years of experience in IT, primarily within test, test management and process improvement, in both traditional and agile contexts. The last fifteen years she has primarily worked within an agile context, focusing on supporting a quality mindset across teams and organizations, and improving the processes for some of the largest international companies in Denmark. As a self-confessed test and agile evangelist who preaches the need for a strong quality and value driven focus, Gitte is a strong advocate for a context-driven approach, a role requiring profound professional insight, passion, and persistence—qualities that Gitte holds in abundance. Gitte is a dedicated trainer within the areas of agile and test and is a regular speaker at international conferences. She holds several certificates within testing as well as agile; ISTQB Expert Level Test Management – Full, Certified agile tester (CAT), TMap Test Engineer, TMAP Organizing Built-in Quality at Scale, Certified SCRUM Master, SAFe Program Consultant
It's tempting to use BDD as a way to describe and run acceptance tests on the UI. Our experience has shown, that BDD is more beneficial, when used in earlier testing stages instead.
Target Audience: Test managers, testers, developers, ... so for the whole team
Preriquisites: Knowledge in BDD advantageous, but not mandatory
Level: Basic
Extended Abstract:
BDD is well established way to provide abstract description of expected system behaviors to developers. But, due to years of siloed mindsets, BDD is often described as the next big thing to describe and automate testcases for QA teams. This talk gives a small insight, in why using BDD in later testing stages (System-Integration and Acceptance Testing) could create additional overheads and more complicated test automation setups. You will learn how BDD can be beneficial when used correctly, but also how it can disrupt team velocity if introduced at the wrong places.
Testen sollte deutlich mehr wertgeschätzt werden, das ist meine persönliche Überzeugung. Deshalb engagiere ich mich seit über 10 Jahren in der Testautomatisierung und dem Testmanagement und zusätzlich begleite ich unsere Associate IT-Consultants sowohl in ihrer fachlichen als auch persönlichen Entwicklung. In meiner Freizeit sind die Interessen vielfältig: Angefangen vom Drachenfliegen, über Gospel-Musik bis zum Go-Spielen.
Während ich mich in meinem Medieninformatik-Studium sehr viel ausprobiert habe, bin ich auf mein Interesse für Qualitätssicherung gestoßen. Seitdem konnte ich in diesen Bereich viel Praxiserfahrung sammeln und übernehme nun Fachtests, Testmanagement, sowie Testautomatisierung. In meiner Freizeit bin ich gerne aktiv, unternehme etwas mit Freunden und versuche so oft es geht in der Woche zum Sport zu gehen.
Mehr Inhalte dieses Speakers? Kein Problem, schaut doch mal bei sigs.de vorbei:
https://www.sigs.de/autor/Helmut.Pichler
Ein Adrenalinkick für QA Experten - mussten Praktiken, Testansätze und -fähigkeiten doch rasch angepasst werden, um bei diesem enormen Fahrtwind weiterhin qualitativ hochwertige Erlebnisse zu garantieren. In diesem Vortrag nehmen wir Sie mit auf eine spektakuläre Achterbahnfahrt durch Last- und Performancetests eines komplexen Anwendungsfalls einer Audio-Video-Streaming-Plattform. Die Herausforderung: Gleichzeitiger Zugriff von 310.000 Benutzern auf die Plattform und ein begrenztes Budget.Wir entschieden uns für ein Open-Source-Tool, suchten nach einer kosteneffizienten Testinfrastruktur und entwickelten selbst eine Reihe von Dienstprogrammen
Zielpublikum: Test-Experten, speziell Last-, Perf Test-Engineers, Testmanager
Voraussetzungen: Grundkenntnisse Testing Nichtfunktionaler Anforderungen, speziell Last-, Performance Tesing
Schwierigkeitsgrad: Advanced
Extended Abstract:
Ein Adrenalinkick für QA Experten - mussten Praktiken, Testansätze und -fähigkeiten doch rasch angepasst werden, um bei diesem enormen Fahrtwind weiterhin qualitativ hochwertige Erlebnisse zu garantieren.
In diesem Vortrag nehmen wir Sie mit auf eine spektakuläre Achterbahnfahrt durch Last- und Performancetests eines komplexen Anwendungsfalls einer Audio-Video-Streaming-Plattform.
Die Herausforderung: Gleichzeitiger Zugriff von 350.000 Benutzern auf die Plattform und ein begrenztes Budget.
Wir entschieden uns für ein Open-Source-Tool, suchten nach einer kosteneffizienten Testinfrastruktur und entwickelten selbst eine Reihe von Dienstprogrammen.
Der Schwerpunkt lag nicht nur auf der Sicherstellung der Gesamtleistung des Systems, sondern auch auf der Überwachung der Qualität des Audio-Video-Streamings, wenn 350.000 Benutzer live in der Anwendung an verschiedenen, parallellaufenden Vorträgen teilnehmen.
Peter Kuras durchlief nach dem Studium mehrere Stationen in den Bereichen Multi-Projektmanagement bis zur Umsetzung der Digitalisierung und Vorantreiben größerer Anwendungsplattformen. Im seinem Zusammenspiel zwischen IT und weiteren Fachbereichen war qualitativ hochwertig Software stets ein wichtiges und herausforderndes Thema. Peter blüht auf wenn es um kundennahe, mehrwertschöpfende aber auch intensive Projekte geht wo QA sehr stark im Fokus steht. Heute treibt Peter als Director Business Development den QA Bereich in Deutschland voran und verantwortete bisher große Kundenprojekte mitunter im L&P Test Bereich. Dabei hat Peter stets die Optimierung durch Einsatz neuster oder gut bewährter Technologien im Auge.
Helmut Pichler blickt auf eine langjährige Karriere im Bereich Test- und Qualitätsmanagement zurück. Neben seiner Beratertätigkeit hält er auf zahlreichen Konferenzen Vorträge über Softwaretest-Themen. Seine Leidenschaft gilt einer praxisnahen, pragmatischen, lösungsfokussierten QA im agilen sowie auch traditionellen Umfeld, Last- und Performancetests und beschäftigt sich in letzter Zeit intensiver mit Emerging Technologie-Lösungen. Helmut ist Co-Autor des Buches 'Agile Testing' und ein Veteran in der internationalen Tester Community. Darüber hinaus ist er Präsident des Austrian Testing Boards (ISTQB®-Vertretung in Österreich), das für Softwaretest-Zertifizierungen zuständig ist.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/experten/helmut-pichler/
Vortrag Teilen
Software-Testing in der Gaming-Branche - Wie funktioniert das eigentlich? Viele Menschen spielen zwar regelmäßig Computerspiele, aber kaum einer kennt den Beruf des Software-Testers in dieser Branche. In diesem Vortrag geben wir einen kurzen Einblick in unsere Arbeit als Testteam. Welche komplexen Herausforderungen ergeben sich hierbei und wie geht unser Testteam damit um? Tauchen Sie mit uns ein in die Welt von 'Tibia', einem 25 Jahre altem Online Rollenspiel und wir zeigen Ihnen welche Test-Werkzeuge und Methoden wir erfolgreich verwenden. Zudem wird gezeigt, wie unsere Spieler aktiv in den Testprozess integriert werden.
Zielpublikum: Tester, Entwickler, Testmanager, Projektmanager
Voraussetzungen: Neugier und eine Affinität für Online Games
Schwierigkeitsgrad: Basic
Extended Abstract:
Software-Testing in der Gaming-Branche - Wie funktioniert das eigentlich? Viele assoziieren mit diesem Beruf stundenlanges Zocken. Tatsächlich gehört dies zwar zu den Aufgaben, aber das Testen von Computerspielen ist oft weitaus komplexer als zunächst gedacht.
Zunächst werden wir uns der Frage widmen, welche Bestandteile und Systeme ein Computerspiel ausmachen. Um dies zu veranschaulichen, werden wir uns an unserem erfolgreichen und langjährigen Online-Rollenspiel 'Tibia' orientieren. Wir werden dabei auch die Rolle unseres Testteams beleuchten und Einblicke in unsere Arbeitsweise bei der Behandlung von Regressionen geben.
Test-Werkzeuge haben für uns einen hohen Stellenwert und deshalb werden wir einige davon vorstellen und verdeutlichen, wie die Ideen dazu entstanden sind.
Es wird auch darum gehen, warum wir unsere Games oft gemeinsam und explorativ testen, obwohl es umfangreiche Anforderungsdokumente gibt.
Am Ende werden wir den sogenannten 'Externen Test' vorstellen. Sie werden erfahren, warum wir viel Aufwand betreiben und welche Rolle beim Test unsere Community dabei spielt.
Ich bin Oliver Heldt und Software-Tester bei der CipSoft GmbH aus Regensburg. Wir entwickeln lebendige Online-Spielwelten und ich bin Teil des Testteams. Vorher war ich lange als System-Administrator in München tätig, wo die Fehlersuche und das Nachstellen von Problemen ein wichtiger Teil meiner Aufgaben war. 2015 wechselte ich in die Automobil-Industrie als Software-Tester, aber meine Leidenschaft für Games aus meiner Jugend zog mich 2017 in die Games-Branche zurück.
Continuous Delivery ist allgegenwärtig. Wirklich? Viele Teams straucheln immer noch dabei regelmäßig gut getestete Produktinkremente zu liefern. Normalerweise mit der gleichen alten Ausrede: die (nicht)-funktionalen Tests seien zu aufwändig und zu teuer umzusetzen. Doch genau das Gegenteil ist der Fall! In diesem Tutorial gehen wir kurz auf die Bedeutung früher und regelmäßiger (nicht)-funktionale Tests ein und erläutern warum monolithische CI Pipelines eine Sackgasse sind. Anschließend zeigen wir, wie einfach es ist, kontinuierliche Integrations, Performance, Security und Akzeptanz-Tests mit Hilfe von Testkube direkt im Cluster auszuführen.
Es wird ein eigener Laptop benötigt, sowie eine Lokale Kubernetes Installation, z.B.
und eine Lokale IDE, z.B.
Max. Teilnehmendenzahl: 20
Zielpublikum: Tester:innen, Entwickler:innen, Architekt:innen
Voraussetzungen: Java-Kenntnisse, Kubernetes-Kenntnisse, Grundlegende Programmier-Kenntnisse sind empfehlenswert
Schwierigkeitsgrad: Advanced
Mario-Leander Reimer ist passionierter Entwickler, stolzer Vater und #CloudNativeNerd. Er ist CTO bei der QAware GmbH und beschäftigt sich intensiv mit den Innovationen und Technologien rund um den Cloud-Native-Stack und deren Einsatzmöglichkeiten im
Unternehmensumfeld. Außerdem unterrichtet er Software-Qualitätssicherung an der TH Rosenheim.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/experten/mario-leander-reimer/
Durch immer kürzere Release-Zyklen erfolgen Test und Entwicklung immer häufiger parallel. In der Praxis führt das sowohl zu Test-Lücken, wenn geänderter Code ungetestet ausgeliefert wird, als auch zu nutzlosen Tests von Bereichen, die sich nicht verändert haben und daher keine neuen Fehler enthalten können.
In diesem Vortrag stellen wir Test Intelligence vor, eine Methode, bei der änderungsgetrieben getestet wird, um so Test und Entwicklung präziser aufeinander abzustimmen und Probleme zu vermeiden.
Test Intelligence analysiert, welche (manuellen oder automatisierten) Tests welche Code-Bereiche durchlaufen und welche Code-Bereiche wann geändert wurden. Dadurch lassen sich Tests passend zu Änderungen auswählen und verbleibende Test-Gaps rechtzeitig erkennen und schließen. Wir gehen auf Forschungsergebnisse, Werkzeuge und Praxiserfahrungen ein.
*Der Track+ besteht aus Präsentationen der Sponsoren und Austeller. Diese Präsentationen unterliegen nicht der Qualitätssicherung des German Testing Day Conference-Boards.
Dr. Andreas Göb ist Team Lead Customer Success und Berater für Softwarequalität bei der CQSE GmbH. Er begleitet seit Jahren viele Firmen beim Verbessern ihrer Softwareentwicklungs- und Testprozesse.
Er hat eine Promotion im Bereich Softwarequalität der TU München und spricht auf nationalen und internationalen Konferenzen.
Andreas Punz ist Berater für Softwarequalität bei der CQSE GmbH. Er studierte Informatik und machte seinen Bachelor an der TU München.
Mehr Inhalte dieses Speakers? Kein Problem, schaut doch mal bei sigs.de vorbei:
https://www.sigs.de/autor/dehla.sokenou
Cypress ist ursprünglich als Alternative zu Selenium gestartet. Inzwischen füllt es mit Component Testing auch die Lücke zwischen Unit- und End-2-End-Tests in der Webentwicklung, die bisher nur ungenügend besetzt war.
Lässt man Cypress Component Tests in sein Projekt, dann automatisieren sie schnell nicht nur Komponententests, sondern bieten sich auch als Ersatz für typische Unit-Test-Werkzeuge wie Jest an.
Kann Cypress wie ein Schweizer Taschenmesser wirklich den kleinen Zoo der bisher verwendeten Werkzeuge ablösen? Wir haben es ausprobiert und berichten über Erfahrungen positiver Art, aber auch über die Grenzen, an die wir gestoßen sind.
Zielpublikum: Tester, Entwickler, Testautomatisierer
Voraussetzungen: Projekterfahrung, Testautomatierungserfahrung, Basiskenntnisse in der Webentwicklung
Schwierigkeitsgrad: Advanced
Extended Abstract:
Das Open-Source-Werkzeug Cypress ist ursprünglich als Alternative zu Selenium im Bereich der End-2-End-Tests in der Webentwicklung gestartet. Inzwischen füllt es mit Component Testing auch die Lücke zwischen Unit- und End-2-End-Tests in der Webentwicklung, die bisher nur ungenügend besetzt war, also bei den Komponenten- und Integrationstests.
Lässt man Cypress Component Tests in sein Projekt, dann automatisiert man damit schnell nicht nur Komponententests, sondern auch Unit-Tests. Sie bieten sich damit als Ersatz für typische Unit-Test-Werkzeuge für Webanwendungen wie Jest oder Karma an. Cypress etabliert sich damit als Automatisierungswerkzeug für alle Teststufen, von den Unit- bis hin zu den End-2-End-Test.
Kann Cypress wie ein Schweizer Taschenmesser wirklich den kleinen Zoo der bisher verwendeten Werkzeuge ablösen? Wir haben es ausprobiert und berichten über Erfahrungen positiver Art, aber auch über die Grenzen, an die wir gestoßen sind. Unter anderem zeigen wir, wie einfach bestehende Tests migriert werden können, und haben evaluiert, was unter welchen Bedingungen schneller und stabiler ist, die Unit-Tests in Jest oder die in Cypress.
Dr.-Ing. Dehla Sokenou promovierte 2005 an der TU Berlin über UML-basiertes Testen. Sie fühlt sich in allen Phasen der Softwareentwicklung zu Hause, einen besonderen Schwerpunkt bilden allerdings auch weiterhin alle Themen rund um Qualitätssicherung und Testen. Bei der WPS ist sie als Test- und Qualitätsmanagerin sowie Softwarearchitektin tätig. Daneben ist sie Sprecherin der GI-Fachgruppe Test, Analyse und Verifikation von Software (TAV).
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/experten/dehla-sokenou/
Die Begriffe “Green IT and Programming” existieren bereits seit Jahrzehnten, erfahren jedoch durch die aktuellen geopolitischen Umstände mehr Bedeutung. Dies ist überfällig, schließlich konnte man das Gefühl gewinnen, dass während der
Cloud-Bewegung oftmals der Nachhaltigkeits-Gedanke vergessen wurde. In diesem Vortrag wollen wir den Begriff “Sustainability” als nicht-funktionale Anforderung (NFR) definieren, Ideen und Vorgehen zum Testen und Messen dieser
Anforderungen vorstellen und die Wechselwirkungen hin zu anderen NFR-Klassen wie Performance oder Availability betrachten. Ein kurzer Exkurs zu Nachhaltigkeit im Testprozess rundet den Vortrag ab.
Zielpublikum: Tester, NFR engineers, developers, architects
Voraussetzungen: Keine
Schwierigkeitsgrad: Basic
Extended Abstract:
In dieser Session wollen wir Antworten auf die folgenden Fragen liefern - oder zumindest den Startschuss für Eure Projekt-spezifischen Diskussionen zu diesem Thema liefern:
Markus arbeitet als Lead Performance Engineer bei Celonis in München. In der Daten-intensiven Domäne des Process Minings stellt er die performante und effiziente Verarbeitung sicher. Zudem interessiert sich Markus für interne Qualitätsattribute wie Wart- und Testbarkeit von Software.
In seiner Rolle als Portfoliomanager hilft Florian Siemens-Projekte bei ihrer digitalen Transformation, indem er Forschungsergebnisse in die operative Arbeit führt und gleichzeitig die strategische Roadmap für verwandte Forschungsfragen entwirft. Als Lead Test Architect bei Siemens MindSphere und weiteren Projekten war er verantwortlich für Testarchitektur und -infrastruktur, leitete damit verbundene international verteilte Teams und arbeitete eng mit F&E, QV, Architektur, Sicherheit und Betriebsmanagement zusammen.
Vortrag Teilen
Bisher ging es immer um Outsourcing, Test Center/Test Factory und Kosten sparen - sollte Qualität als Kernkompetenz nicht in-house sein? Built-In Quality (a la SAFe) kann dann wirklich erreicht werden, wenn Qualität als Ziel aller Beteiligten definiert wird. Welche Wege gibt es dafür, welche Fallstricke müssen beachtet werden und warum macht das Sinn? Auf diese Fragen gibt es in Form von Anekdoten und Beispielen Lösungsansätze und Ideen, dies als Teil einer Qualitätsoffensive zu starten, die wirklich im Unternehmen verankert ist und Testing nicht nur als Kostenblock versteht.
Zielpublikum: Tester, SW-Entwickler, Testmanager, Projektleiter, Product Owner, Release Train Engineers
Voraussetzungen: Grundlegendes Verständnis von Software-Entwicklung und -Testen, idealerweise auch Outsourcing oder Provider-Steuerung
Schwierigkeitsgrad: Advanced
Extended Abstract:
Nach mühsamen Wissenstransfer Runden, um das sehr verteilte Expertenwissen an (vermeintlich) spezialisierte Firmen zu übergeben merken jetzt viele Unternehmen, dass man Qualität nicht auslagern kann. Die Tätigkeiten dazu schon, aber wenn das dann alles optimiert ist, wieso sollte ich Testing Aufgaben nicht wieder insourcen und so Qualität als Kernkompetenz in meinem Unternehmen etablieren? Qualität fängt bekanntlich schon bei der Projektidee, dem Demand oder Change an, und nicht erst während des Testings. Eine in-house Qualitätsorganisation kann gleichzeitig schlank und durchschlagskräftig sein, innovativ und gleichzeitig mit dem nötigen Grad an (angemessener, systematischer) Kontrolle. Zwar hat jede Industrie hier unterschiedliche Voraussetzungen, und auch Plattform-spezifische Unterschiede sind zu betrachten (SAP only, Cloud-only, Mobile-First etc) - aber letztendlich gelten überall ähnliche Qualitätskriterien, diese sollten intern verankert und nachgehalten werden.
Seit mehr als 20 Jahren tätig für Kunden in verschiedenen Industrien bei der Gestaltung, Implementierung und Verbesserung von Test- und IT-Prozessen sowie zentralen Testorganisationen. Angefangen als Tester, seitdem sehr viele Industrien, Organisationen, Testansätze und vor allem Menschen gesehen. Besonderer Fokus auf sinnvolle Testautomatisierung, vor allem in agilen Vorgehensweisen, sowie die Visualisierung komplexer Prozesse mit Hilfe von Metriken.
Die Bereiche Qualitätssicherung und Testen haben in den letzten Jahren enorm an Komplexität gewonnen. Build Management, Continuous Integration, Environments, Deployments und Release Management sind nur wenige der vielen umfangreichen Themen, die das verursacht haben. Gleichzeitig hat die digitale Transformation den Druck dahingehend weiter erhöht, auf veränderliche Marktbedingungen rasch zu reagieren.
Unternehmen müssen Testzyklen verkürzen, die Testfrequenz steigern und die Testeffizienz verbessern, alle umliegenden Prozesse im Auge behalten und einfließen lassen und haben dabei oft Schwierigkeiten, die richtigen Prozesse zur Qualitätssicherung einzurichten. Finden Sie heraus ob Ihr Unternehmen schon bereit ist, von manuellen Tests zu automatisierten Tests überzugehen, ob Sie bestehende Testportfolios optimieren müssen oder ob Sie überhaupt erst eine Qualitätssicherung einführen sollten.
Diese Fragen können wir Ihnen in den von Qualysoft entwickelten Assessment Centers beantworten, um gemeinsam die richtigen Schritte in Ihrer Qualitätssicherung zu tätigen. Lernen Sie in diesem Vortrag mehr über die verschiedenen Anwendungsmöglichkeiten sowie Erfolgsgeschichten und erfahren Sie welches Assessment den besten Ansatz für Ihr Unternehmen darstellt.
*Der Track+ besteht aus Präsentationen der Sponsoren und Austeller. Diese Präsentationen unterliegen nicht der Qualitätssicherung des German Testing Day Conference-Boards.
Ein Adrenalinkick für QA Experten - mussten Praktiken, Testansätze und -"Software muss stabil funktionieren und bei der Beurteilung von Softwarequalität ist das sicherlich das wichtigste Kriterium. Langfristig darf aber auch die Wartbarkeit der Software nicht vernachlässigt werden, denn das führt zu Mehraufwänden bei Fehlerbeseitigungen und Weiterentwicklungen, auch bekannt als technische Schulden. Fehlende, nicht-kontinuierliche oder nicht-automatisierte Testfälle dürfen ebenso zu technischen Schulden gezählt werden.
In diesem Vortrag wird erklärt, was genau unter Softwarequalität zu verstehen ist.
Ergebnisse und Erkenntnisse aus einem Jahr der Qualitätsüberwachung in einer CI-Pipeline werden vorgestellt.
Zielpublikum: Tester:innen, Entwickler:innen, Testmanager, Projektleiter
Voraussetzungen: Keine
Schwierigkeitsgrad: Basic
Extended Abstract:
ISO 25010 zieht zur Definition von Softwarequalität neben Funktionalität und Stabilität auch Wartbarkeit als Bewertungskriterium in Betracht. Eine Vernachlässigung der Wartbarkeit führt zu Mehr-Aufwänden bei Fehlerbeseitigungen und Weiterentwicklungen, auch bekannt als technische Schulden oder 'Technical Debt'.
Bei der Bewertung von Softwarequalität darf man aber auch das umgebende Test-Setup nicht vernachlässigen, z.B. Code-Abdeckungs-Metriken aus dynamischen Tests. Auch fehlende, nicht-kontinuierliche oder nicht-automatisierte Testfälle dürfen als technische Schulden verstanden werden.
'Continuous Integration' (CI) ermöglicht einen automatisierten, kontinuierlichen Test und definierte Qualitäts-Kontrollpunkte. Durch die kontinuierliche Überwachung kann eine gleichbleibende und hohe Softwarequalität sichergestellt werden, wodurch eine kontinuierliche Bereitstellung der Software, auch bekannt als 'Continuous Deployment' (CD), ermöglicht wird. Probleme können frühzeitig erkannt, adressiert und Kosten-optimal beseitigt werden.
In diesem Beitrag erhalten Sie einen Überblick über Grundlagen der Softwarequalität und eine Umsetzung der kontinuierlichen Überwachung in einer CI Pipeline.
Anhand eines konkreten Projekt-Beispiels werden Ergebnisse und Erkenntnisse aus einem Jahr der Anwendung vorgestellt.
Ingo Nickles blickt auf mehr als 20 Jahre Berufserfahrung in der Softwarentwicklung für embedded Geräte in der Telekommunikationsbranche zurück. Seit 2012 ist er Field Application Engineer für die Firma Vector und verantwortlich für Schulungen, Seminare, Präsentationen und den Support rund um die VectorCAST Produktfamilie. Er verfügt über zahlreiche Erfahrungen aus den unterschiedlichsten Kundenprojekten und den verschiedensten Entwicklungswerkzeugen.
Mehr Inhalte dieses Speakers? Kein Problem, schaut doch mal bei sigs.de vorbei:
https://www.sigs.de/autor/thomas.much
Tester werden in agilen, crossfunktionalen Teams zunehmend zu Qualitäts-Spezialisten und -Moderatoren und arbeiten gemeinsamen mit den Entwicklern an der Testautomatisierung auch auf den unteren Teststufen. Es ist also wichtig, dass Tester nicht nur die Test-Grundlagen kennen und vermitteln, sondern auch die Herausforderungen bei der Programmierung verstehen: Wann Code bzw. die Komponenten einer Anwendung gut automatisiert testbar sind - und was dem häufig im Wege steht. In diesem Vortrag zeige ich mit einfachen Beispielen, wie man eine gute Testbarkeit im Code-Design und in der Architektur erreicht: Durch das Beherrschen von Abhängigkeiten.
Zielpublikum: Tester, Testmanager, Entwickler, Architekten
Voraussetzungen: Erfahrungen mit dem Schreiben von Code und automatisierter (Unit-)Tests sind hilfreich, aber nicht erforderlich
Schwierigkeitsgrad: Basic
Extended Abstract:
Tester werden in agilen, crossfunktionalen Teams zunehmend zu Qualitäts-Spezialisten und -Moderatoren. Dabei arbeiten sie gemeinsamen mit den Entwicklern an der Testautomatisierung auch auf den unteren Teststufen. Es ist also wichtig, dass Tester nicht nur die Test-Grundlagen kennen und vermitteln, sondern auch die Herausforderungen bei der Programmierung verstehen: Wann Code bzw. die Komponenten einer Anwendung gut automatisiert testbar sind - und was dem häufig im Wege steht. In diesem Vortrag zeige ich mit einfachen Beispielen, wie man eine gute Testbarkeit im Code-Design und in der Architektur erreicht: Durch das Beherrschen von Abhängigkeiten. Ziel dieser Session ist, dass man als Tester Impulse bzw. erste Anregungen bekommt, wie man Softwareentwicklungsteams durch geeignete Fragen und Ideen unterstützen kann, damit Testen und Testbarkeit ein nachhaltiger, integraler Bestandteil der gemeinsamen Arbeit ist.
Auf welchem Hintergrund entstand dieser Vortrag, warum liegt der Fokus auf Testbarkeit von Code-Design und Architektur? Bei meiner Arbeit mit zahlreichen Teams habe ich während der letzten Dekade ein wiederkehrendes Muster beobachtet: Teams mit guter, schneller Testautomatisierung liefern oftmals bessere Lösungen kontinuierlicher ab - und arbeiten dabei oft auch sehr gut rollenübergreifend zusammen. Aber warum erreichen manche Teams eine gute Testautomatisierung, während sich andere damit über Jahre abmühen?
Meiner Erfahrung nach hängt dies davon ab, ob der Code einfach testbar ist. Das hat positive Auswirkungen nicht nur auf die unteren (Unit-)Teststufen, sondern erleichtert meist auch das Testen auf höheren Stufen. Gerade bei Unit-Tests denkt man dann sofort an Programmierpraktiken wie Test-Driven Development (TDD), durch die ein besseres - besser testbares! - Code-Design entsteht. Aber darum soll es in diesem Vortrag nicht (oder nur ganz am Rande) gehen. Denn es gibt auch einige Architekturstile bzw. -muster, die ein einfacheres Testen mit schnelleren Feedback-Schleifen ermöglichen. Und das ist nicht nur für Entwickler interessant, sondern auch für andere Rollen wie beispielsweise Tester.
Wir schauen uns in dieser Session an, was es bedeutet, Geschäftslogik von Integrationscode zu trennen, welche unterschiedlichen Code-Designs und Architekturmuster es gibt, um dieses Ziel zu erreichen - und warum damit kleinere und schnellere automatisierte Tests möglich sind. Es geht dabei um die absoluten Grundlagen von testbarem Code und testbarer Architektur. Wer sich nicht täglich mit diesen Themen beschäftigt, wird Anregungen und Tipps bekommen, worauf es sich bei der täglichen Arbeit zu achten lohnt.
Die gezeigten Beispiele bestehen aus einfachem, sprachunabhängigem Pseudo-Code und einfachen Architekturdiagrammen.
Thomas Much works as a Technical Agile Coach at Techniker Krankenkasse (TK) in Hamburg. Together with his coaching colleagues, he supports teams in always getting a little bit better at collaboration and agile programming practices – by encouraging (and doing!) pair and team programming, TDD, BDD, test automation and the like. Over the years, Thomas has contributed to various software systems large and small, many of which had to and have to be maintained for many years, even decades.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/experten/thomas-much/
Imagine working on a product whose customers are your colleagues. How would you go about getting and using their feedback? How would you support them and troubleshoot occurring problems?
In most cases, an application's customers are either far away or so big in number that they are but a fuzzy concept for those developing that application. Thus, we create customer journeys and profiles.
But could you benefit from easily reachable customers? What methods could you use in that case? And how can a Quality Specialist use feedback to identify and drive product improvements, or prioritize the testing of an application? In this talk, I will share experiences from my current project, where I work in close collaboration with the users - my colleagues.
For that purpose, I will share how I learned to speak the users' language, stepped into their shoes, and incorporated all those learnings into the development of the product. Furthermore, I will present different methods I used for collecting feedback from the users and show you which concepts worked well, which didn't and how they were executed. As a cherry on top, I will also elaborate on how these methods help me to brighten the quality mindset and communication within my team.
I’m a Senior Quality Specialist building quality strategies since 2014. From XING’s Startpage to MOIA’s navigation system, I love technical challenges that require logical thinking and a quality mindset. When I don’t use my quality mindset for tech, I try to crochet the highest quality stuffed animals.
Effizientes Testen erfordert einen hohen Automatisierungsgrad der Testdatenbereitstellung, so wie die moderne Entwicklung einen hohen Automatisierungsgrad des Deployment benötigt.
Die beiden Säulen, die das Testen unterstützen, sind das automatische Testen, das in Deployment-Pipelines verwendet wird und das manuelle Testen, das für explorative Tests verwendet wird. Diese beiden Bereiche haben eines gemeinsam: Beide benötigen Testdaten. Bei automatischen Unit-Tests sind die Testdaten bereits im Testcode enthalten. Integrationstests - sowohl manuelle als auch automatische -, explorative Tests oder Akzeptanztests müssen jedoch vorab mit Testdaten versorgt werden. Jedes Mal, wenn Sie ein realistisches Mockup für den Unit-Test in einer Unternehmensumgebung erstellen, sind komplexe und korrekt zugeordnete Daten erforderlich. Außerdem braucht der Tester einen Ausgangspunkt für die Integrations- und Sondierungstests. Um zu vermeiden, dass die Daten von Grund auf neu erstellt werden müssen, benötigen beide Arten einen automatischen Prozess zur Erstellung einer Testgrundlage. Unternehmensanwendungen speichern ihre Daten in mehreren Datenbanken auf unterschiedlichen Plattformen. Sie modellieren komplexe Prozesse, die aus zahlreichen Zuständen mit vielen Beschränkungen für die zugehörigen Daten bestehen. Um agile Teams in die Lage zu versetzen, die perfekten Testdaten zu erhalten, die mit ihren aktuellen Produktzielen übereinstimmen, sind gut geplante Ansätze entscheidend. Daher wird eine flexible Testdaten-Pipeline benötigt, die schnell die gewünschten Testdaten liefern kann. Dieser Vortrag fasst die wichtigsten Anforderungen an eine Testdatenbereitstellungspipeline zusammen, zeigt häufige Probleme und deren Lösung auf und demonstriert, wie eine Testdatenbereitstellungspipeline aufgebaut werden kann, die für Tester, Entwickler, Anwendungsbenutzer und alle anderen am Test Beteiligten einfach zu handhaben ist.
*Der Track+ besteht aus Präsentationen der Sponsoren und Austeller. Diese Präsentationen unterliegen nicht der Qualitätssicherung des German Testing Day Conference-Boards.
Danny Tamm ist Entwickler und Consultant bei UBS Hainer GmbH.
Ein Großteil seiner Aufgaben besteht in der Beratung und Unterstützung der Partner bei Aufbau und Wartung von Testdatenbereitstellungsystemen mit XDM.
Dabei hilft ihm der enge Kontakt zu den Partnern genauso wie die 20 Jahre Erfahrung als Entwickler.
1. Software Testing with Wittgenstein (Joël Doat)
Inadequate documentation of requirements can be one of the most problematic areas in test planning. Instead of evaluating concrete notation techniques, this talk demonstrates a philosophical approach on understanding the formation of requirements by the example of expert systems. Using the perspective on language of famous philosopher Wittgenstein, the nature of the communication between stakeholders can be described while at the same time, it defines verifiable dependencies between important terms enabling the creation of test cases.
2. Testen, was wirklich zählt - Eine kurze Einführung in Usage-Centric Testing (Anne Kramer)
Die Idee von Usage-Centric Testing besteht darin, Informationen aus dem laufenden Betrieb einer Software zu analysieren, Verhaltensmuster (User Journeys) zu erkennen und daraus geeignete, automatisierte Regressionstests zu generieren. Regressionstests neigen nämlich dazu, mit der Zeit zu veralten. In diesem Lightning Talk wird kurz das Problem erläutert und dann das Konzept anhand einer konkreten Umsetzung mit der SasS gravity illustriert. Dabei werden auch die besonderen Herausforderungen angesprochen. Teilnehmer, die Interesse zeigen, können sich im Anschluss melden und als Early Adopters an der Gestaltung des Produkts mitwirken.
Mehr Inhalte dieses Speakers? Kein Problem, schaut doch mal bei sigs.de vorbei:
https://www.sigs.de/autor/Anne_Kramer
3. Explorative Tests - Was man vom Fischen lernen kann! (Manfred Baumgartner)
In vielen Projektsituationen erlebe ich, dass exploratives Testen eher als Versuch und Irrtum denn als methodischer agiler Testansatz gelebt wird. Man kennt die Methoden und Werkzeuge des sitzungsbasierten Testens, wendet dieses Wissen aber nicht an.
Um die Potenziale des explorativen Testens in Erinnerung zu rufen und besser zu verinnerlichen, ziehe ich in meinem Vortrag Analogien zu den Erfahrungen als Fischer. Denn Testen und Fischen haben viel gemeinsam: Wenn ich den ganzen Tag keinen Fisch fange, heißt das nicht, dass keine Fische im Wasser sind. Wie Dijkstras es ausdrückt: 'Testen zeigt das Vorhandensein, nicht die Absenz von Fehlern'.
Mehr Inhalte dieses Speakers? Kein Problem, schaut doch mal bei sigs.de vorbei:
https://www.sigs.de/autor/Manfred_Baumgartner
Hi, I'm Joël! Currently working as Quality Assurance Architect at Eloquest GmbH, I'm especially interested in designing test strategies and program analysis. As a trained mathematician and would-be philosopher, my mission is bridging formal methods and conceptualization to define software quality in a meaningful, objective, and transparent manner.
Während ihrer beruflichen Laufbahn in stark regulierten Branchen (E-Payment, Medizintechnik, Automotive) hat Anne einen außergewöhnlichen Erfahrungsschatz in IT-Projekten gesammelt - insbesondere in den Bereichen QS und Test. Anne gibt ihr Wissen und ihre Erfahrung mit Leidenschaft weiter, insbesondere wenn es um Testdesign-Ansätze geht, die auf visuellen Darstellungen basieren. Seit April 2022 ist Anne Global Customer Success Managerin bei Smartesting, einem französischen Hersteller von SW-Testwerkzeugen.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/experten/anne-kramer/
Manfred Baumgartner verfügt über mehr als 35 Jahre Erfahrung in der Softwareentwicklung, insbesondere in der Software-Qualitätssicherung und im Software-Test. Nach dem Studium der Informatik an der Technischen Universität Wien war er als Softwareentwickler und später als Qualitätsmanager tätig und baute seit 2001 die QS-Beratungsleistungen der Nagarro GmbH auf. Er ist Präsidiumsmitglied des ASQF und Autor einschlägiger Fachliteratur wie z.B. Der Systemtest, Software in Zahlen, Agile Testing, Basiswissen Testautomatisierung.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/experten/manfred-baumgartner/
Vortrag Teilen
Um die Auswahl zwischen den parallel laufenden Vorträgen und Workshops zu vereinfachen, geben die Sprecherinnen und Sprecher einen kurzen Teaser zu Ihrer Session.
Die IVU hat eine große automatische Testsuite mit mehrere tausend Testfällen. Diese sind zum Teil Sprachübergreifendend aufgebaut (C++, Java). Vorhandene Ansätze zur Testselektion waren bisher nicht sicher genug oder wegen der Struktur der Testfälle nicht anwendbar. Dadurch wurde es immer schwieriger, ein umfangreiches und gleichzeitig zeitnahes Feedback an die Entwickler:innen zu liefern. Gemeinsam mit der TU München haben wir Werkzeuge zur Testselektion entwickelt, die dafür sorgen, dass nur die relevanten Testfälle ausgeführt werden. Ich stelle im Vortrag die grundsätzlichen Konzepte und Ergebnisse dieser Zusammenarbeit vor.
Zielpublikum: Tester:innen, Test-Manager:innnen, Entwickler:innen, Architekt:innen
Voraussetzungen: Grundlegende Kenntnisse zur Testautomatisierung
Schwierigkeitsgrad: Basic
Silke Reimer ist Leiterin der Qualitätssicherung für eines der beiden Geschäftsfelder bei der IVU Traffic Technologies AG. Ein wesentlicher Teil ihrer Aufgabe beinhaltet Verbesserungen im Bereich Testautomatisierung auf allen Ebenen. Diesem Thema hat sie sich vor ihrer aktuellen Position auch als Testarchitektin langjährig gewidmet. Damit bringt sie viele Jahre an Erfahrung im Aufbau und der Wartung von automatischen Testsuites mit.
Die Planung eines Hardware in the Loop (HiL)-Testsystems wird in vielen Embedded Projekten zu spät in den Projektalltag integriert. Anforderungen ändern sich ständig und Schnittstellen müssen angepasst werden. Das Testsystem muss alle Schnittstellen und Umgebungsbedingungen des Prüflings bedienen und gleichzeitig die Echtzeitbedingungen einhalten.
In vielen Fällen empfiehlt sich dann ein Middleware-basierter Ansatz, um die Testsysteme einfach, effektiv und schnell ändern zu können, wobei die Echtzeitfähigkeit, Portabilität und Flexibilität eine große Rolle spielen.
Zielpublikum: Testautomatisierungsanwender und -experten, Testmanager, Projektleiter, Entscheidungsträger, Interessierte
Voraussetzungen: Grundlegende Kenntnisse im Bereich Entwicklung von Embedded Systems und Softwaretest
Schwierigkeitsgrad: Advanced
Extended Abstract:
In den letzten Jahren hat der Funktionsumfang von eingebetteten Systemen, speziell auch im Industrie- und Automobilbereich, stark zugenommen. Es wird erwartet, dass dieser Trend sich auch in Zukunft fortsetzt und neben der bloßen Funktionsvielfalt auch die Interaktion mit der Umwelt immer weiter zunimmt. Zum Projektstartzeitpunkt eines Embedded Systems wird dabei häufig das Testen in den Hintergrund gestellt. Im Projektverlauf werden Anforderungen definiert, welche den verschiedenen Stakeholdern gerecht werden sollen. Meist wird dabei jedoch der Tester als Stakeholder vergessen.
In jedem Industriebereich kommt dann schließlich doch der Zeitpunkt, an dem die Frage nach dem Test in den Vordergrund rückt. Welche Tests soll es geben? Wie soll getestet werden? Genügen Modultests oder müssen über den normalen Softwaretests hinaus auch Integrations- oder gar Systemtests durchgeführt werden? Eines trifft aber in allen Varianten zu: Je später das Testteam involviert wird, desto umständlicher und aufwendiger wird das Testen.
Die Anforderungen sind längst fixiert und doch ändern sich diese mit jedem neuen Build. Der Safety- and Security-Beauftragte fordert für die Freigabe jedoch auch noch funktionale Sicherheitstests und das Projektbudget ist begrenzt. Dafür muss nun eine Testumgebung geschaffen werden, um den Prüfling hinreichend testen zu können. Hierzu müssen HiL-System-Hersteller angefragt werden, und diese Testsysteme sollen am besten alle Schnittstellen des Prüflings direkt bedienen können. In der Realität ist dies allerdings ohne weiteres meist nicht out-of-the-box möglich.
Der Einsatz einer Middleware kann hier Abhilfe schaffen, über die zum Beispiel Hardwareschnittstellen verschiedener Hersteller (DIO-/AIO-Karten, FPGA, CAN) aber auch Softwareschnittstellen verschiedener Komponenten / Applikationen (Umgebungsmodell, physikalische Simulation) an die Echtzeitsimulation angebunden werden können.
Im Vordergrund steht jedoch auch die Echtzeitfähigkeit des Testsystems. Immerhin muss sich der Prüfling in seiner simulierten Umgebung wohlfühlen und diese vom Verhalten her hinreichend nahe der realen Umgebung sein. Es gilt auch, die verschiedenen Messzykluszeiten (vom Messsystem, vom DeviceUnderTest (DUT), etc.) auf eine gemeinsame Basis zu bringen.
Verschiedene Hersteller bieten Middleware- oder Hardware Abstraction Layer (HAL)-Lösungen an, welche unterschiedliche Ausrichtungen des Datenflusses wie den Zugriff über eine Cloud bieten. Es stellt sich die Frage: Welche Lösung bietet nun eine Middleware basierter Ansatz für den Embedded-Test?
Daniel Heinrich war nach Abschluss seines Elektrotechnik-Studiums an der Technischen Hochschule Nürnberg zunächst am Institut ELSYS tätig und erarbeitete die Grundlagen für den automatisierten Hardware In The Loop-Test. Nach dem Wechsel zur iSyst GmbH im Jahr 2004 baute er dort den Bereich Hardware In The Loop auf. Seit 2008 ist Herr Heinrich Geschäftsführender Gesellschafter und steht den Bereichen Technik und Vertrieb vor.
I'm not right in the head. I've been struggling with depression, anxiety, and other brain weasels since I was young. I used to think that in my professional life I'd have hide this part of me, and if anyone found out, that would be the end of anyone ever taking me seriously - if not my entire career. So, I kept my mouth firmly shut about it. Until one day I didn't.
I'd like to tell you the story of how I started talking about mental health, even in the workplace, and what I learned from it about openness, courage, and kindness, and what Ben Franklin and oxygen masks have to do with it.
Target Audience: Everyone is welcome
Prerequisites: none
Level: Basic
Extended Abstract:
There are things you don't talk about with your colleagues - even less so with your boss. Mental health issues are certainly a big no-no. When I first started working as an agile tester, I kept my history with mental illness secret. As a result, I couldn't speak openly about topics that are close to my heart: mental health and self-care. In the Agile World however, we value respect, courage, and openness. How do you reconcile this with these taboos? Can you really be courageous and open if you deny a part of yourself?
When I attended my first ever testing conference, I was in awe about the openness with which psychological topics were discussed. Inspired, and with a head still spinning from the experience (and a serious lack of sleep), I came clean to my boss on the very first day upon returning. From then on, I wore my heart on my sleeve.
And my life at the office began to change: Once I had started speaking up, openness came easier with every new issue. I would suddenly talk about my experiences with sickness and therapy as well as being more comfortable with sharing my thoughts and feelings about day-to-day business and goings-on at work. Conversely, people started confiding in me, asking me for advice and talking to me in a whole new way.
In this talk, I would like to share what I have learned from breaking taboos. I will discuss how communication improved for me, which obstacles I bumped into, and why I will still not shut up about the things you don't talk about at work.
Hi, I'm Sophie!
When I was a girl, I wanted to be an astronaut or a ballerina, or both. Now I'm a tester, holding diplomas in math and yodeling. I'm a dancer, a baker, a fighter and a knitter. Plant mum and doting aunty. I love the sea, walking in misty woods and all things chocolate or ice cream. I get over-excited and I talk too fast.
Audio-Anwendungen als Skill oder Dialogsystem nehmen immer mehr zu, daher bauen wir eine kleine Teststrecke mit freien Tools und Google Colab. Probieren Sie selbst aus, wie sich Audio testen lässt und welche Schwierigkeiten sich mit Akzenten oder anderen Faktoren ergeben und wie man diese automatisiert testen kann.
Zielpublikum: Audiotester:innen
Voraussetzungen: Laptop/Tablet, Google-Account
Schwierigkeitsgrad: Advanced
Extended Abstract:
Sie möchten selbst ausprobieren, wie man Audioanwendungen testen kann? Dann bringen Sie Laptop oder Tablet mit und probieren Sie Beispiele aus, wie eine KI Audio erstellt und versteht. Sie lernen in Grundzügen, wie diese erstellt werden und welche datenschutzrechtlichen oder ethischen Aspekte beachtet werden sollten. Anschließend nutzen Sie das Hören und Sprechen der KI für eine Google-Colab-Teststrecke, die Sie an Ihre Bedürfnisse anpassen können. Schließlich erfahren Sie, wie sich diese Beispiele in ein bestehendes Test-Framework integrieren lassen.
Olaf digitalisiert gesprochenes Deutsch. Er trainiert Modelle für die Transkription und Synthese von deutschem Audiomaterial mit Hilfe von künstlicher Intelligenz. Da diese Modell immer stärker genutzt werden, wird auch das Testen dieser Modelle immer wichtiger.
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, TesterInnen die Testfälle Schritt für Schritt durchführen und diese nicht
hinterfragen. Aus unserer Erfahrung ist dies ein Unding, setzt die Leistung der TesterInnen 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 eigenen Testideen verfolgen. 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 meinem Vortrag erläutere ich 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 zeige ich auf, welchen Mind change wir im Testing
zwingend erreichen müssen, so dass die Rolle des Testers den verdienten Respekt erhält.
*Der Track+ besteht aus Präsentationen der Sponsoren und Austeller. Diese Präsentationen unterliegen nicht der Qualitätssicherung des German Testing Day Conference-Boards.
Zielpublikum: Tester:innen, Agile Teams, Testmanager:innen, Entwickler:innen, Projektleiter:innen
Voraussetzungen: Grundlegendes Verständnis von Software-Entwicklung und -Testen
Schwierigkeitsgrad: Basic
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.
Eine gute Continuous Integration läuft weniger als 10min - etwa die Zeit, um einen Kaffee zu holen. Für Dolby liegt die größte Herausforderung dabei in der Testlaufzeit, denn das sind oft Stunden. Ein Lösungsansatz ist, nur eine Teilmenge der Tests direkt auszuführen und die übrigen Tests in nachgelagerte Test-Builds (z.B. nightly) auszulagern. Wir berichten von den Nachteilen manueller Testauswahl, von technischen und organisatorischen Herausforderungen einer automatisierten Lösung und davon, wie es im Projekt 'Dolby Car Automotive' letztendlich doch gelang, sicherzustellen, dass die CI dauerhaft unter 10 Minuten bleibt.
Zielpublikum: Tester:innen, Testmanager:innen, Entwickler:innen
Voraussetzungen: Basiswissen Softwareentwicklung und -test
Schwierigkeitsgrad: Basic
Extended Abstract:
Eine gute Continuous Integration läuft weniger als 10min - etwa die Zeit, um einen neuen Kaffee zu holen. Diese Ansicht teilen die Entwickler:innen von Dolby mit vielen Kolleg:innen aus anderen Organisationen [1] und Pionieren wie Martin Fowler [2]. Für Dolby liegt die größte Herausforderung dabei in der Laufzeit der (automatisierten) Tests, denn viele dieser Tests müssen wenigstens alle paarweisen Kombination von Konfigurationsoptionen wie dem Lautsprechersystem (5.1, 5.1.2, 7.1, ...) und der Bitrate des Tons durchlaufen. So werden aus 40 Testfunktionen schnell einmal 1300 Testfälle und die Ausführung aller Testfälle dauert mehrere Stunden.
Ein Lösungsansatz ist, eine Teilmenge der Tests für schnelles Feedback direkt auszuführen und die übrigen Tests in nachgelagerte Test-Builds (z.B. nightly) auszulagern, die auch länger brauchen dürfen. Wenn man diese Teilmenge passend zu den konkreten Änderungen auswählt, die getestet werden sollen, lassen sich rund 90% der Testfehlschläge in nur 2% der Testlaufzeit erkennen. Doch wie gelingt eine solche Testauswahl im Alltag?
Lars Kempe (Dolby) und Sven Amann (CQSE) haben verschiedene Taktiken miterlebt. Sie berichten von den Nachteilen manueller Testauswahl, von technischen und organisatorischen Herausforderungen bei der Eigenentwicklung einer automatisierten Lösung und davon, wie es ihnen im neuen Projekt 'Dolby Car Automotive' letztendlich doch gelungen ist, mit der Test-Impact-Analyse von Teamscale sicherzustellen, dass die Continuous Integration dauerhaft unter 10 Minuten bleibt.
[1]: Hilton et al.: dl.acm.org/doi/abs/10.1145/3106237.3106270
[2]: Fowler: martinfowler.com/articles/continuousIntegration.html
Dr. Sven Amann hat als Berater für Software-Qualität bei der CQSE GmbH bereits vielen Kunden erfolgreich geholfen Geschwindigkeit und Effektivität ihrer Tests zu verbessern. Sven hält seit vielen Jahren Vorträge und Keynotes auf Konferenzen und Fachtagen.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/experten/sven-amann/
Lars Kempe beschäftigt sich als QA-Lead und Audio-Tester bei Dolby täglich mit der wachsenden Test-Suite und weiß wie schnell eine praktikable CI sein muss. Lars spricht seit vielen Jahren auf Konferenzen und Fachtagen.
Mehr Inhalte dieses Speakers? Kein Problem, schaut doch mal bei sigs.de vorbei:
https://www.sigs.de/autor/ralf.wirdemann
Business Fitness Functions (BFF) überwachen den fachlichen Kern eines Softwaresystems zur Laufzeit. Das System wird von außen betrachtet, indem messbare Merkmale (KPIs) definiert werden, die das System fachlich auszeichnen. Beispiele sind die über den Warenkorb eines E-Commerce-Systems laufenden Geldbeträge oder die in ein Job-Portal durchschnittlich eingestellten Stellenanzeigen. Für identifizierte Merkmale werden BFFs entwickelt, die das Systemverhalten kontinuierlich messen und mit den Erwartungen abgleichen. Dieser Vortrag zeigt, wie sich das fachliche Funktionieren eines Softwaresystems zur Laufzeit messen und absichern läßt.
Zielpublikum: Architekt:innen, Tester:innen, (DevOps)Entwickler:innen
Voraussetzungen: Basiswissen Unit-, Integrations- und Akzeptanz-Testing
Schwierigkeitsgrad: Advanced
Extended Abstract:
Business Fitness Functions (BFF) überwachen den fachlichen Kern eines Softwaresystems zur Laufzeit. Das System wird von außen betrachtet, indem messbare Merkmale (KPIs) definiert werden, die das System fachlich auszeichnen. Beispiele sind die über den Warenkorb eines E-Commerce-Systems laufenden Geldbeträge oder die in ein Job-Portal durchschnittlich eingestellten Stellenanzeigen. Für identifizierte Merkmale werden BFFs entwickelt, die das Systemverhalten kontinuierlich messen und mit den Erwartungen abgleichen. Dieser Vortrag zeigt, wie sich das fachliche Funktionieren eines Softwaresystems zur Laufzeit messen und absichern läßt.
Ralf Wirdemann ist programmierender Gesellschafter der CodeKeepers GmbH in Hamburg. Als Projektmanager, Architekt und Programmierer begleitet er Entwicklungsteams seit mehr als 20 Jahren bei der Planung und Umsetzung komplexer Softwareprojekte. Er versteht sich als Brücke zwischen Entwicklern und Projektmanagement. Agilität heißt für ihn, Verantwortung für das Ergebnis zu übernehmen. Ralf Wirdemann ist Autor der beiden Fachbücher 'Scrum mit User Stories' und 'RESTful Go APIs'.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/experten/ralf-wirdemann/
This is a story about teamwork. In the summer of 2019, the London Metropolitan Police's twitter account was hacked. Control of the account was soon recovered, but the culprits proved harder to find. Police were at a loss.
However, there were about 5 million people in the UK with a very specific skill that could have helped solve the crime, if only they had been consulted. Asking for help can be incredibly difficult. Veerle Verhagen knows this, because she's been there. It is also vital to self-improvement. So how do you learn to reach out and get the support you need?
Target Audience: This talk is aimed towards Testers and professionals who struggle to ask for help and feel uncomfortable doing so.
Prerequisites: tbd
Level: Basic
Extended Abstract:
Just before Veerle heard about this Twitter Met police hacking story, she was in the position of the being the police in her testing own story. She was completely stuck on an assignment, but for various reasons didn't ask for help.
For a large part it was embarrassment that stopped her: as the only Tester on her project, she thought she had to be the expert in her field and asking for help would have been a sign of inexperience and mediocrity. So she stuck it out, inside her comfort zone and admits to never learning a thing.
Finding people who can support you and foster your talent is vital to your success as an individual. Veerle realised that she wasn't very good at reaching out, but she was learning to do so.
She learned that the most valuable allies are sometimes the most unexpected and in turn learned new ways of reaching out that make asking for help feel empowering rather than humiliating. And she wants to share with you how she got there.
Veerle is a software tester with RisQIT. She has a background in historical linguistics and spent a few years in education before turning to IT. She is particularly interested in the human beings behind the software, core skills, agile testing, and ethics in tech. So far her absolute favourite project in testing has been a mobile travel planner app. Besides testing, she likes to put her background in education to use by creating and facilitating workshops. Veerle is a social animal who cannot wait for the office (and the pub!) to open again. Until that time she tries to connect and keep in touch online with Testers all around the globe, from the comfort of her own kitchen.
Neue Automatisierungsframeworks sind verfügbar, im Team beim Kunden gilt es, neue Konzepte zur Effizienzsteigerung einzuführen, im neuen Projekt sind andere SW-Entwicklungsmodelle im Einsatz bzw. Eine Transition steht vor der Tür, das Team möchte andere Formen der Zusammenarbeit ausprobieren. Soft Skills werden wichtiger als Tech Skills, der Kunde verlangt eine neue Zertifizierung der Mitarbeitenden, bzw. für eine neue Technologie sind entsprechende Zertifizierungen verfügbar und vom Kunden gewünscht oder technisch sinnvoll.
Wir kennen das alle. Was gibt es für Möglichkeiten, damit umzugehen, darauf zu reagieren, "immer am Ball" zu bleiben und vor allem – nicht davon überrascht zu werden, vorbereitet zu sein auf Neues ?
Communities, Constant Learning usw. Sind Begriffe, die immer wieder in diesem Zusammenhang fallen. Wir zeigen, angefangen bei realen Projektsituationen, was für uns funktioniert, welche Auswirkungen das Vorgehen intern hat – was oft als "Nachteil" gesehen wird, weil es ein Budget benötigt - zumindest anfänglich
*Der Track+ besteht aus Präsentationen der Sponsoren und Austeller. Diese Präsentationen unterliegen nicht der Qualitätssicherung des German Testing Day Conference-Boards.
Agile test enthusiast, driven by quality, team spirit and the desire to learn.
Studying computer science, starting as a software programmer, he changed to the „dark side“ some years later - and stayed with testing since then to convert it to the bright side of life.
Based on his experience in numerous projects with different industries, he founded and leads a testing division within the company and created the monthly "TeaTime" together with Utz Winter - a knowledge sharing platform within the company, open to public from time to time.
Steffen’s topics are agile testing, agile teams and teamwork, test automation, test processes, test coaching, team building, continuous learning.
Steffen loves to share, learn and discuss experiences and knowledge in conferences and talks.
Since 2018 he shares his knowledge as ISTQB trainer for the Certified Tester certifications.
Wirtschaft muss wachsen. Gewinne machen. Professionell geführt werden. Immer effizienter arbeiten. Werbung betreiben.
Bei Getränken auch: Mengenrabatte einräumen. Freiware verteilen. Und so weiter, und so weiter – lauter angeblich unverrückbare Gesetze, und wer die als Unternehmer nicht befolgt, wird im Wettbewerb untergehen, oder?
Premium-Cola beweist seit über 21 Jahren, dass es auch anders geht. Wir gehen rein in ein System, das uns nicht gefällt. Schauen darin, wie die Dinge funktionieren und dann verbiegen wir sie.
Dass das geht, und wie das geht, erzählt der Gründer und nicht-Geschäftsführer Uwe Lübbermann. Er zeigt uns Beispiele für Veränderungen, die vielleicht auch in unserem Berufsalltag Sinn machen.
Uwe Lübbermann ist Gründer des kollektiv geführten Unternehmens Premium-Cola. Aufbauend auf seinen nunmehr zwanzigjährigen Erfahrungen mit Premium arbeitet Lübbermann auch als Berater, Referent und Trainer. Zu seinen Auftraggebern gehörten in der Vergangenheit DAX-notierte Unternehmen ebenso wie das Fusion-Festival oder die Regierung der Vereinigten Arabischen Emirate. Als Dozent ist und war er tätig an verschiedenen Hochschulen, darunter die Leuphana Universität Lüneburg, die Hochschule für Nachhaltige Entwicklung Eberswalde und die Alanus Hochschule in Alfter. Lübbermann lebt in Hamburg