Konferenzprogramm

Die im Konferenzprogramm des GTD 2024 angegebenen Uhrzeiten entsprechen der Central European Time (CET).

Ihr benötigt mehr Übersicht vor Ort?
» Zur Programmübersicht als PDF (Mittwoch)
» Zum Raum- und Expoplan

Konferenzprogramm 2024

Thema: Testautomatiserung

Nach Tracks filtern
Nach Themen filtern
Alle ausklappen
  • Dienstag
    07.05.
  • Mittwoch
    08.05.
, (Dienstag, 07.Mai 2024)
16:00 - 16:35
Di2.1
Cypress vs. Playwright — Gegenspieler oder Verbündete?
Cypress vs. Playwright — Gegenspieler oder Verbündete?

Wer nach einem Testwerkzeug für End-2-End-Tests von Web-Anwendungen sucht, hat inzwischen die Qual der Wahl. Erst hat Cypress Selenium als Platzhirsch in diesem Bereich abgelöst, jetzt schickt sich Playwright an, dasselbe mit Cypress zu tun. Doch was sind eigentlich die Unterschiede zwischen den Werkzeugen? Was schränkt ihre Anwendbarkeit ein und warum sollte ich mich für das eine oder andere entscheiden? Wir stellen die Technik hinter den Werkzeugen vor und geben Tipps für die Entscheidung anhand praktischer Beispiele.

Zielpublikum: Tester, Testautomatisierer, Entwickler
Voraussetzungen: Projekterfahrung, Grundkenntnisse in Web-UI-Testautomatisierung
Schwierigkeitsgrad: Advanced

Extended Abstract:
Nachdem lange Jahre Selenium der Platzhirsch bei den End-2-End-Tests von Web-Anwendungen war, gibt es inzwischen zwei etablierte Alternativen. Erst kam Cypress und behauptete, vieles besser zu machen als Selenium, und eroberte sich seinen Platz bei den Testern. Nun taucht ein weiterer Protagonist auf, der mit einem ähnlichen Werbeslogan auftritt und wiederum vieles anderes und besser machen möchte als die beiden anderen Testwerkzeuge. Selenium, Cypress und Playwright nutzen ganz verschiedene Ansätze, um das Web-Frontend im Browser für den Test zu steuern. Da jeder dieser Ansätze Limitierungen hat, betreffen diese Einschränkungen auch das jeweilige Testwerkzeug. Cypress punktet bspw. mit Component-Tests, schwächelt aber bei Multi-Origin- und Multi-Tab-Anwendungen. Playwright dagegen ist aufgrund der Architektur auf End-2-End-Tests festgelegt, überzeugt dort aber durch "Multiple everything" — Multi-Origin, Multi-Tab, Multi-User. Vielleicht ist es ja kein Entweder-oder, sondern ein Sowohl-als-auch? Wir schauen uns an, wann welches Werkzeug seine Stärken ausspielen kann und ob und wann es sinnvoll ist, sich nicht nur auf ein Testwerkzeug festzulegen.

Dehla Sokenou fühlt sich in allen Phasen der Software-Entwicklung zu Hause, einen besonderen Schwerpunkt bilden allerdings alle Themen rund um Qualitätssicherung und Testen. Bei WPS - Workplace Solutions ist sie als Test- und Qualitätsmanagerin und Software-Architektin tätig. Daneben ist sie Sprecherin der GI-Fachgruppe Test, Analyse und Verifikation von Software (TAV) und im Sprechergremium des Arbeitskreises Innovative Testmethoden.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/dehla.sokenou

Dehla Sokenou
Plateau
Dehla Sokenou
Plateau

Vortrag Teilen

16:45 - 18:05
Di4.2
ISTQB-Testdesign-Methoden und modellbasiertes Testen — eine erfolgreiche Symbiose
ISTQB-Testdesign-Methoden und modellbasiertes Testen — eine erfolgreiche Symbiose

Wie schreiben wir unsere Testfälle? Meist per Hand, inzwischen vielleicht auch mit KI-Unterstützung. Vermutlich jedoch nicht modellbasiert. Was schade ist, denn viele Testdesign-Methoden des ISTQBs bilden eine perfekte Symbiose mit modellbasierten Testverfahren.
In diesem Tutorial wollen wir einige grundlegenden Vorgehensweisen des strukturierten Testdesigns rekapitulieren und uns anschauen, wie sich diese mit modellbasierten Testansätzen erfolgreich kombinieren lassen. Denn anders als vom ISTQB suggeriert, ist MBT kein reines Spezialisten-Thema! Außerdem werfen wir einen Blick darauf, wie KI den Test im allgemeinen und MBT im Besonderen verändert hat bzw. verändern wird.

Zielpublikum: Tester:innen, Testmanager:innen
Voraussetzungen: keine (es ist mein erklärtes Ziel, alle abzuholen)
Schwierigkeitsgrad: Basic

Extended Abstract:
Die meisten von uns sind geübte Autofahrer, aber würden wir die theoretische Fahrprüfung noch einmal bestehen? Vermutlich nicht. Vieles haben wir verinnerlicht, manches jedoch nie gebraucht und vergessen, von den Änderungen seit damals mal ganz abgesehen.
Die meisten von uns sind geübte Tester, aber würden wir die CTFL-Prüfung auf Anhieb noch einmal bestehen. Auch eher unwahrscheinlich. Manches, wie die Äquivalenzklassenbildung ist uns in Fleisch und Blut übergegangen, aber vieles kam nie zum Einsatz. Wie oft nutzen Sie Entscheidungstabellen oder zustandsbasierte Testentwurfsverfahren? Wie schaut es mit MBT aus? Und haben Sie schon Erfahrungen mit KI-gestützter Testfallerstellung?
Das Tutorial richtet sich an alle, die systematisch testen wollen, in der Praxis jedoch Verbesserungspotenzial in ihren Projekten sehen. Er basiert auf dem CTFL-Lehrplan V4.0 sowie dem demnächst aktualisierten ISTQB MBT-Lehrplan. Neulinge im Test erhalten einen raschen Überblick über die wichtigsten Testentwurfsverfahren. Erfahrene Testerinnen und Tester erhalten ein Update und Einblicke in die Vorteile des modellbasierten Testens und die konkreten Einsatzmöglichkeiten.
Des Weiteren werden wir uns gemeinsam anschauen, welche Möglichkeiten es gibt, KI im Testdesign zu nutzen und wo die Grenzen sowohl der KI-Modelle als auch der MBT-Modelle liegen.
 

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/autor/Anne_Kramer

Anne Kramer
Satellit
Anne Kramer
Satellit

Vortrag Teilen

, (Mittwoch, 08.Mai 2024)
10:35 - 11:10
Mi1.1
TestOps mit Low-Code-/No-Code-Tools: Wenn die Produktverantwortlichen die Tests im Alleingang automatisieren!
TestOps mit Low-Code-/No-Code-Tools: Wenn die Produktverantwortlichen die Tests im Alleingang automatisieren!

Die Raiffeisen Bank International hielt lange an der Überzeugung fest, dass Testautomatisierung Softwareentwicklung ist. Also Code-Schreiben. Doch ein unkonventioneller Testathon mit Low-Code/No-Code-Tools änderte alles. Zwei Produktverantwortliche – ohne Programmiererfahrung – automatisierten in Minuten Testfälle mit einer LC/NC-Test-Platform. Das führte zu einem Proof of Concept für zwei SAS-Anwendungen (Jira/GitHub), bei dem ein Ferienpraktikant ohne Programmiererfahrung erfolgreich die gesamte Regressions-Test-Suite automatisierte. Der Vortrag teilt die Erkenntnisse aus diesem Projekt und wie eine Paradigmenwechsel hin zu TestOps stattfand.

Zielpublikum: Produkt-Manager, Software-Entwickler, Tester, jeder der sich mit dem Thema Test Automation für Nicht-Techniker auseinandersetzen will
Voraussetzungen: Keine
Schwierigkeitsgrad: Basic

Rudolf Grötz ist seit 30 Jahren in der IT unterwegs und seit 2008 passionierter Softwaretester. Er ist als Agile Engineering Coach für das Thema & Test Automation bei der Raiffeisen Bank International in Wien tätig und lebt den Leitspruch „Testautomation is Software Development!“. Neben diverser Autorentätigkeiten, u.a. für das IX-Magazin, organisiert er in Wien das Agile (Test) Automation Meetup und 6x pro Jahr die TestBustersNight Vienna.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Rudolf.Gr%C3%B6tz

Rudolf Grötz
Plateau
Rudolf Grötz
Plateau
Vortrag: Mi1.1

Vortrag Teilen

10:35 - 11:10
Mi3.1
Modellbasiertes Testen in zwei Phasen — Testautomatisierung, die gelingt
Modellbasiertes Testen in zwei Phasen — Testautomatisierung, die gelingt

Die Autoren stellen ein neues Verfahren zum modellbasierten Testen vor. Das Verfahren verbessert die Effektivität und Effizienz von GUI-Tests erheblich, insbesondere bei DevOps. Zuerst werden die Probleme der heutigen MBT-Ansätze analysiert. Anschließend wird das neue Verfahren vorgestellt, das diese Probleme löst. Dabei wird in der ersten Phase ein abstraktes, aber für Tester leicht verständliches Testmodell entworfen. Die zweite Phase dient der effizienten werkzeuggestützten Testimplementierung. Veranschaulicht wird das Verfahren mit einem Fallbeispiel aus der eigenen Praxis mit dem MBT-Tool Harmony und dem Automatisierungstool PlayWright.

Zielpublikum: Fachtester, Testanalysten, GUI-Tester, Testmanager, DevOps-Tester, MBT-Spezialisten
Voraussetzungen: Grundlagen des Testens
Schwierigkeitsgrad: Advanced

Extended Abstract:
Die geschätzten jährlichen Kosten von Softwareproblemen in den USA übersteigen eine Billion Dollar. Die Ausgaben für die Fehlerbehebung machen etwa 20 % der gesamten IT-Kosten aus und belaufen sich weltweit auf viele weitere Milliarden Dollar in nur einem Jahr. Ein Großteil dieser Verluste ist nicht auf die inhärente Schwierigkeit zurückzuführen, Softwarefehler zu finden, sondern darauf, dass der Testentwurf ineffektiv und ineffizient ist. Die Autoren sind der Meinung, dass ein erheblicher Teil dieser Kosten durch die Anwendung modernster Testentwurfsverfahren und Automatisierung gemindert werden kann. Eine effiziente Testautomatisierung umfasst sowohl den Testentwurf als auch die Testimplementierung und -Durchführung. Automatisierter Testentwurf wird dabei durch modellbasierte Testwerkzeuge (MBT) umgesetzt. Die heute gängigen MBT-Werkzeuge haben allerdings mehrere Probleme. Sie erfordern einerseits sehr umfassende Modellierungskenntnisse, die über ein Analysemodell weit hinausgehen. Herkömmliche Modelle sollten "computerlesbar" sein, d.h., das Modell sollte von einem Computerprogramm analysiert und verarbeitet werden können. Wenn das erfolgt ist, werden die ausführbaren Tests generiert. Daher muss das Modell alle Details der Anwendung einschließlich Design und Implementierung enthalten, sodass eine Automatisierung von vornherein fast unmöglich ist. Ein weiteres Problem stellt das erwartete Ergebnis dar. Auch die Ausgaben des Testobjekts sollten im Modell enthalten sein, sodass der Tester sie bei der Modellierung berechnen muss. In diesem Vortrag stellen die Autoren ein neues MBT-Verfahren, das Zwei-Phasen-MBT vor, das diese Probleme löst. Sie zeigen an einem Fallbeispiel aus der Praxis die Vorteile des Verfahrens. Beim Zwei-Phasen-MBT wird zuerst ein abstraktes und dann ein konkretes Testmodell erstellt. Das abstrakte Modell, das die Autoren im Fallbeispiel genutzt haben, besteht aus einem speziellen Flussgraphen, dessen Knoten Testschritte sind. Jeder Testschritt enthält eine (Benutzer-)Aktion, eine oder mehrere (System-)Antworten — optional — und einen Testzustand — optional. Dieses Testmodell ist für manuelle Tester leicht erlernbar und deckt sowohl das Verhalten des Testobjekts in den Interaktionen, wie z.B. das bei Anwendungsfallspezifikationen oder verhaltensgetriebener Entwicklung (behavior-driven development, BDD) der Fall ist, als auch das zustandsabhängige Verhalten. Testfälle werden aus dem Graphen generiert. Ein Testfall ist ein Pfad vom Anfangsknoten zu einem Blattknoten. Das abstrakte Modell ist "menschenlesbar", aber noch nicht „computerlesbar“, d.h., aktuelle Anwendungen sind nicht in der Lage, es zu verarbeiten, um Testcode zu erzeugen. Stattdessen werden aus dem abstrakten Modell abstrakte Testfälle generiert. Diese Testfälle können von den Testern ausgeführt werden, aber auch hier kann kein ausführbarer Testcode erzeugt werden. Abstrakte Testfälle können die Anforderungen vor der Implementierung validieren. Auf diese Weise können verschiedene Fehler, nicht erwarteter Code usw. eliminiert werden, was den SDLC kostengünstig und den Code qualitativ hochwertig macht. In der zweiten Phase erfolgt die Generierung eines konkreten Modells und des ausführbaren Testcodes. Dies kann durch die manuelle Ausführung der abstrakten Testfälle am implementierten Testobjekt erfolgen. Während der Ausführung wird ein konkretes Modell generiert. Der ausführbare Testcode wird vom MBT-Werkzeug sofort generiert und ausgeführt. Wenn die manuellen Testschritte ausgeführt werden, wird diese Ausführung mit einem geeigneten Werkzeug automatisiert, sofort ausgeführt und man ist fertig. Hierbei hat sich das Testautomatisierungswerkzeig PlayWright in unserer Fallstudie ausgezeichnet bewährt. Das generierte konkrete Modell ist computerlesbar, womit wir bei der traditionellen Lösung angekommen sind. Auf diese Weise kann das Zwei-Phasen-MBT als eine Weiterentwicklung des traditionellen Modells betrachtet werden. Anhand des Fallbeispiels werden die Teilnehmer die Vorteile des Zwei-Phasen-MBT gegenüber herkömmlichem MBT verstehen:

  • kompakter
  • verständlicher
  • viel schneller
  • führt zu qualitativ hochwertigem Code
  • erfordert keine Berechnung der erwarteten Ergebnisse, es reicht, sie zu validieren
  • Abstrakte Tesetfälle können vor der Testimplementierung generiert werden
  • In-Sprint-Testautomatisierung ist möglich

Matthias war bis zu seiner Pensionierung Ende 2019 Managing Consultant bei Sogeti Deutschland. Im GTB und ISTQB® engagiert er sich weiterhin ehrenamtlich und ist für das Glossar sowie den Lehrplan Advanced Test Analyst verantwortlich.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/matthias.hamburg

Matthias Hamburg
Solar
Matthias Hamburg
Solar

Vortrag Teilen

10:35 - 12:40
Mi4.1
Ausgebucht Performance Testing Is for Everyone!
Performance Testing Is for Everyone!

What is spontaneously your first thought when it comes to performance testing? "uh... nothing for me because too complex" or "that's something for developers or infra colleagues". Don't panic, this reaction is perfectly normal because performance testing is usually underexposed. However, its importance cannot be underestimated because the performance of a system -in addition to its functionality- largely determines the user experience. Even though performance testing has an important technical component, we need everyone during the journey, including you, the manual tester. This workshop will explain how you can play a role in this journey.

Target Audience: (Manual) testers in general
Prerequisites: No technical background required. Even more, it is better if people don't have experience with performance testing. This workshop will just show them how they can play a role in the performance testing journey
Level: Basic

Max. number of participants: 36
If you would like to attend this workshop, we kindly ask you to note the course selection when purchasing your ticket. Please be at the lecture room 10 minutes before the workshop starts.

Extended Abstract:
What is spontaneously your first thought when it comes to performance testing? "uh... nothing for me because too complex" or "that's something for developers or infra colleagues". Don't panic, this reaction is perfectly normal because performance testing is usually underexposed. However, its importance cannot be underestimated because the performance of a system -in addition to its functionality- largely determines the user experience. Even though performance testing has an important technical component, we need EVERYONE during the journey, including you, the (manual) tester. "But what can I do in such a project"? you may be asking yourself. That's exactly what this tutorial is going to answer. Non-technical aspects such as collaboration, communication, creativity are just as important. How else can you properly answer the following questions:

  • How to determine the requirements for performance testing when you have no (existing) baseline
  • How does the strategy differ from functional testing?
  • What information to report to your stakeholders and in which format?
  • Why is this -more than other testing types- an interdisciplinary activity? 

Rest assured, during this tutorial we will take you step by step through the exciting journey of performance testing using a mix of exercises, quizzes, case studies, polls. And we promise that we don’t dive too deep in the technical complexity of performance testing.

Wim has more than 25 years of experience in software testing during which he has developed into a versatile generalist with different aspects (people & operational management, (technical) implementation, service delivery, presales). Driven by versatility, a down-to-earth & pragmatic attitude, Wim always looks at how and where he can stretch his comfort zone to take on new challenges. In his spare time, Wim is a huge AFOL (Adult Fan of Lego) and likes running & gravel biking.

Wim Demey
Sirius
Wim Demey
Sirius

Vortrag Teilen

12:05 - 12:40
Mi1.3
ABGESAGT: Serverless Simplicity: Mastering Local Cloud Testing
ABGESAGT: Serverless Simplicity: Mastering Local Cloud Testing

Bei der Initiierung einer serverlosen Architektur stellt sich oft die Frage, wie diese automatisiert getestet werden kann, ohne eine Verbindung zur Cloud zu benötigen. In meinem Vortrag werde ich verschiedene Ansätze und Frameworks vorstellen, die es ermöglichen, serverlose Architekturen in der lokalen Entwicklungsumgebung zu testen und nahtlos in die Deployment-Pipeline zu integrieren, ohne auf die Cloud angewiesen zu sein. Anhand praktischer Beispielen und Best Practices werde ich zeigen, wie Entwickler diese Herausforderung meistern können, um eine effiziente und zuverlässige serverlose Architektur zu realisieren.

Zielpublikum: Softwarearchitekten, Entwickler, IT-Leiter
Voraussetzungen: Erfahrung mit Tests und Serverless
Schwierigkeitsgrad: Advanced

Extended Abstract:
Stell dir vor, du entwickelst eine serverlose Architektur und möchtest sicherstellen, dass sie einwandfrei funktioniert, ohne ständig mit der Cloud verbunden zu sein. Aber wie kann ich serverlose Anwendungen effektiv testen und in die Deployment-Pipeline integrieren, ohne die Cloud-Ressourcen zu belasten? Dies ist das zentrale Problem, das in diesem Vortrag gelöst wird. Serverlose Architekturen sind eine leistungsfähige Möglichkeit, Anwendungen zu entwickeln und bereitzustellen. Die Entwicklungs- und Testphase erfordert jedoch besondere Aufmerksamkeit, da sie Cloud-Ressourcen und -Kosten beanspruchen kann. In diesem Vortrag zeige ich dir, wie du dieses Problem angehen und serverlose Anwendungen effizient und zuverlässig entwickeln und testen kannst. Ich stelle dir Beispiele und Frameworks vor, mit denen du serverlose Architekturen in deiner eigenen lokalen Umgebung testen und nahtlos in deine Deployment-Pipeline integrieren kannst. Du wirst lernen, wie du Kosten in der Cloud minimieren und Ressourcen optimal nutzen kannst, ohne auf die Vorteile serverloser Architekturen verzichten zu müssen. Mein Ziel ist es, dir bewährte Methoden und Best Practices zu vermitteln, um eine stabile, skalierbare und wartbare serverlose Architektur zu schaffen, die unabhängig von der Cloud getestet werden kann.

Florian Lenz ist Gründer der neocentric und entwickelt gemeinsam mit seinen Kunden strategische Konzepte für den Einsatz von Serverless Cloud-Lösungen und modernsten Technologien, um die Effizienz zu steigern, Kosten zu senken und die Wettbewerbsfähigkeit zu stärken.

Florian Lenz
Satellit
Florian Lenz
Satellit

Vortrag Teilen

14:45 - 15:20
Mi2.4
Continuous Performance Testing in Delivery-Pipelines (GitHub, Azure)
Continuous Performance Testing in Delivery-Pipelines (GitHub, Azure)

Continuous Testing ist der wichtigste Prozess, durch den DevOps erst erfolgreich wird. Dabei handelt es sich um einen Prozess, der automatisiert und kontinuierlich die Veränderungen des Codes überprüft, um sowohl funktionale als nicht-funktionale Anforderungen zu validieren. Das Ziel ist es, proaktiv Fehler zu finden und frühzeitig in der Entwicklung zu beheben. Aber wie sieht es bei Last- und Performancetests im wirklichen Leben aus?

Zielpublikum: Erfahrene Softwaretester, Testanalysten, Testautomatisierer, Testmanager, Test Consultants, Tool-Verantwortliche, Mobile Tester
Voraussetzungen: Keine
Schwierigkeitsgrad: Advanced

Extended Abstract:
Continuous Testing ist der wichtigste Prozess, durch den DevOps erst erfolgreich wird. Dabei handelt es sich um einen Prozess, der automatisiert und kontinuierlich die Veränderungen des Codes überprüft, um sowohl funktionale als nicht-funktionale Anforderungen zu validieren. Das Ziel ist es, proaktiv Fehler zu finden und frühzeitig in der Entwicklung zu beheben. Aber wie sieht es bei Last- und Performancetests im wirklichen Leben aus? In diesem Vortrag werden folgende Aspekte beleuchtet:

  • Last- und Performancetests im Continuous-Delivery-Umfeld
  • Best Practices beim Testen webbasierter Oberflächen
  • Best Practices für die Entwicklung dedizierter Performance-Pipelines
  • Die Rolle von Open Source beim Continuous Testing
  • Die Schritte zum Continuous Testing
  • Continuous Performance Testing/Last- und Performancetests zum Anfassen – Live Demo (Azure, GitHub)

Fazit: Damit Continuous Performance Testing erfolgreich sein kann, werden die richtigen Tools und qualifizierte Experten (ISTQB Performance Tester) benötigt. Continuous Performance Testing ist weit mehr als Automatisierung!

Wilson Campero ist Gründer der Qytera Software Testing Solutions GmbH sowie ISTQB® Certified Full Advanced Tester. Seit 16 Jahren ist das Testen von Software sein Spezialgebiet. Hierbei fokussiert er sich auf Continuous Testing sowie Testautomatisierung und Testmanagement. Herr Campero war schon für zahlreiche internationale DAX-notierte Unternehmen aus den Bereichen Telekommunikation, Banken, Industrie sowie den öffentlichen Dienst tätig.

Moritz Salein ist schon seit über 20 Jahren in der IT und inzwischen über 10 Jahre im Softwaretest tätig. Hierbei war er bei unternehmergeführten Softwareentwicklungs- und Consultingfirmen sowie bei verschiedenen DAX-Unternehmen im Logistik- und Finanzbereich im Einsatz. Dabei sammelte er seit über 8 Jahren viel Erfahrung als Teil von agilen Teams und konnte die unterschiedlichsten Tätigkeiten und Rollen eines Softwaretester einnehmen. Inzwischen spezialisierte er sich immer mehr auf die Umsetzungen von Testautomatisierungs- und Last & Performancetest-Lösungen, gerade auch im Open Source Bereich und ist hier als Consultant für die Qytera Software Testing Solutions GmbH tätig.

Wilson Campero, Moritz Salein
Solar
Wilson Campero, Moritz Salein
Solar

Vortrag Teilen

15:30 - 16:05
Mi2.5
Eine CI/CD-Reise: Weniger Pipelines, mehr Spaß
Eine CI/CD-Reise: Weniger Pipelines, mehr Spaß

CI/CD gilt in der Software-Entwicklung als unverzichtbar, auch die Automobilzulieferer haben diesen Trend entdeckt. Sie wollen Produkte von der Stange anbieten, aber OEMs wollen Alleinstellungsmerkmale. Wie kommt man in dieser Multiprojektlandschaft zu effizientem CI/CD? Die Versuchung ist groß, Jenkins Pipelines zu erstellen und 24 h Nightly Builds zu etablieren. Aber wer hat Lust, am nächsten Morgen Fehler zu analysieren, die weder nachvollziehbar noch reproduzierbar sind? Wir nicht! Unser Weg zum Glück führt über sauberes Dependency Handling mit CMake und nachvollziehbaren Tests in Python hin zu schnellen Builds mit reproduzierbaren Ergebnissen.

Zielpublikum: Spezielle Vorkenntnisse sind nicht erforderlich. Das Thema betrifft CI/CD-Anfänger und -Experten gleichermaßen. Wir möchten die Hochs und Tiefs unserer CI/CD-Reise in der Automobilindustrie darstellen.
Voraussetzungen: Für die verwendeten Beispiele können Kenntnisse in Jenkins Pipelines und Python hilfreich sein, sind aber nicht notwendig.
Schwierigkeitsgrad: Basic

Matthias war lange in der Automobilbranche als SW-Entwickler, jetzt arbeitet er als DevOps Engineer und beschäftigt sich sowohl mit modernen Arbeitsweisen, als auch mit aktuellen Technologietrends.

Karsten ist seit 18 Jahren im Automobilbereich in den Bereichen Embedded, Tools und CI/CD unterwegs. Zur Zeit ist er im Rhein-Main-Team der Marquardt GmbH und beschäftigt sich mit Software Product Lines.

Matthias Eggert, Karsten Günther, Judith Reichwein
Solar
Matthias Eggert, Karsten Günther, Judith Reichwein
Solar

Vortrag Teilen

Zurück