Track: Testing & Quality
- Dienstag
04.02. - Donnerstag
06.02.
What is the difference of a test architect to a commonly known software architect? And why do I need one? What do they have in common and where do they differ? Is there a gap where we need a bridge (Spoiler: yes)? What are the different expectations of other roles on a test architect?
Questions over questions which will be covered in this talk. With examples where it did go well because there was a test architect and examples where things got haywire maybe because a test architect was missing.
And you will also not be left alone with these questions:
- How can I become such a person which is able to be a test architect.
- How can I establish that role in my organization.
You will get input how we did this at Siemens and build up a living network of test architects.
Target Audience: Testers, Developers, Architects, Project Leads, Test Managers, Team Leads
Prerequisites: Architecture knowledge, challenges in software projects, basic testing knowledge
Level: Advanced
Marco Achtziger is Test Architect working for Siemens Healthineers in Forchheim. In this role he supports teams working in an agile environment in implementing and executing tests in the preventive test phase in a large project. He has several qualifications from iSTQB and iSQI and is a certified Software Architect by Siemens AG and Siemens Senior Key Expert in the area of Testing and Continuous Delivery.
The objective of visual test automation is replace flaky and hard to read selectors with images. Many software packages offer the possibility of using images as selectors, but it rarely works reliably. Appium has the function "findElementByImage," Playwright has functions like "toHaveScreenshot." Code and no-code tools alike provide a number of options to tweak the sensitivity, where both, too low and to high values, produce their own set of artefacts. What makes this so difficult? Doesn't AI provide the solution to reliably compare two images? Wouldn't source code be much more readable if it showed the image of the item, rather than just a file name or its xpath?
Target Audience: Experienced test automators in code and no-code
Prerequisites: Images, test automation, CNN, AI
Level: Expert
Stefan Dirnstorfer is CTO and Cofounder at testup.io, a no-code platform for image based test automation. He is a digital native who started programming in primary school and studied computer science in Munich. His latest interest in test automation and image analysis combines his passion for practical software development and intelligent data analysis.
Vortrag Teilen
Vortrag Teilen
Nachdem lange Jahre zunächst Selenium und dann Cypress den Markt der Web-Testwerkzeuge beherrscht haben, kommen inzwischen neue Player auf das Spielfeld. Mit Playwright und WebdriverIO bekommt insbesondere Cypress eine starke Konkurrenz. Beide stellen sich nicht nur im Bereich der End2End-Tests auf, sondern besetzen auch das Feld der Komponententests. Auch in anderer Hinsicht sind sie Cypress ebenbürtig.
Der Webentwickler hat erneut die Qual der Wahl. Welches Werkzeug passt am besten zur eigenen Arbeitsweise, zum Projekt und zum Softwareprodukt? Wo liegen die Stärken und Schwächen der Gegenspieler? Und lassen sich bestehende Testsuiten einfach auf ein anderes Werkzeug migrieren? Wir werfen einen vergleichenden Blick auf die drei Kontrahenten und demonstrieren ihre Fähigkeiten in Aktion.
Zielpublikum: Tester, Testmanager, Testautomatisierer, Web-Entwickler
Voraussetzungen: Grundlegende Kenntnisse von Web-Entwicklung, TypeScript, Testautomatisierung
Schwierigkeitsgrad: Advanced
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/
Nach Vorfreude auf den AI-Coding-Assistant kam Ernüchterung: Viele Vorschläge waren unbrauchbar, es wurde zu viel „halluziniert“. Wir fragten uns, ob es der richtigen Technik bedarf. Wir experimentierten mit Techniken (Chat-Assistant, Auto-Completion, Comment-driven) und Vorgehensweisen (Chat-first, Code-first, Test-first, TDD).
Dieser Vortrag konzentriert sich auf TDD mit AI-Coding-Assistants. Wir erläutern die Vorgehensweise von AI-Coding-Assistants, erklären Begrifflichkeiten, Einschränkungen, Ansätze und demonstrieren das Vorgehen mit Live-Coding. Wir versuchen, Grenzen der AI-Assistants auszuloten: Verbesserte Code-Completion oder Pair-Programming-Partner.
Zielpublikum: Entwickler:innen
Voraussetzungen: Grundkenntnisse in Programmierung
Schwierigkeitsgrad: Basic
Rouven Röhrig verfügt über 15 Jahren Erfahrung als Software-Engineer mit Expertise in Technical Agile Coaching, Extreme Programming und DevOps. Er ist kundenorientiert und erfolgreich in der Produktentwicklung.
Seit 8 Jahren ist Gregor Wicklein Agile Software-Engineer bei andrena objects. Hier liegt sein Fokus auf Agilen Methoden und Extreme-Programming-Techniken wie test-driven development (TDD) und Pair-Programming.
Vortrag Teilen
Bei langlebiger Software lauern die meisten Fehler in dem Code, der kürzlich verändert wurde. Das zeigen empirische Forschungsarbeiten seit Langem und unser Bauchgefühl sagt uns das vermutlich noch viel länger.
Viele Teams setzen daher die sogenannte Test-Gap-Analyse ein, die Test-Gaps (ungetestete Änderungen) automatisiert aufdeckt. Unsere Erfahrung zeigt jedoch, dass oft mehr Test-Gaps gefunden werden, als (rechtzeitig) getestet werden können.
Im Vortrag stellen wir einen risikobasierten Ansatz zur Priorisierung von Test-Gaps vor, in den mehrere Dimensionen der Code-Änderung einfließen (u.a. Zentralität im Abhängigkeitsgraph, Komplexität der Änderung, Findings-Churn). Wir haben den Ansatz empirisch validiert und stellen die Ergebnisse für acht Systeme der Munich Re und der LV 1871 vor.
Zielpublikum: Tester, Test-Manager, Testautomatisierer, Entwickler, Architekten
Voraussetzungen: Interesse an Software-Qualität und Testen
Schwierigkeitsgrad: Basic
Dr. Elmar Juergens hat über statische Codeanalyse promoviert und für seine Doktorarbeit den Software-Engineering-Preis der Ernst Denert-Stiftung erhalten. Er ist Mitgründer der CQSE GmbH und begleitet seit zehn Jahren Teams bei der Verbesserung ihrer Qualitätssicherungs- und Testprozesse. Juergens spricht regelmäßig auf Forschungs- und Industriekonferenzen und wurde für seine Vorträge mehrfach ausgezeichnet. Elmar Jürgens wurde 2015 zum Junior Fellow der Gesellschaft für Informatik ernannt.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/experten/elmar-juergens/
Roman Haas promoviert zur Verbesserung von Testprozessen an der Universität des Saarlandes als externer Doktorand der CQSE GmbH. Dort arbeitet er seit acht Jahren als Consultant für Softwarequalität.
Obwohl moderne Entwicklungstools das Risiko unbeabsichtigter Sicherheitslücken verringern, bleibt das Thema Sicherheit in Unternehmen hochaktuell. Der Einsatz leistungsstarker KI-Systeme bietet neue Wege, Sicherheitsprozesse zu optimieren und zu automatisieren.
In dieser Session zeigen wir, wie traditionelle Scan-Tools (SAST, SCA) mit den Fähigkeiten von Large-Language-Modellen (LLM) kombiniert werden können, um:
- False- sowie Negative-Positives zu reduzieren,
- den Fokus auf kritische Sicherheitsbefunde zu legen,
- die Analyse und Bewertung von Befunden zu verbessern,
- spezialisierte Tools in größerer Anzahl effektiv einzusetzen.
Wir vergleichen Tausende manuell und per LLM analysierte Befunde und beleuchten die Unterschiede zwischen freien und proprietären Modellen.
Zielpublikum: Entwickler, Architekten, Sicherheitsverantwortliche
Voraussetzungen: Grundlegendes Verständnis für gängige Schwachstellen im Code werden vorausgesetzt
Schwierigkeitsgrad: Advanced
Mirko Richter ist Software-Security-Berater, Sourcecode-Analyse-Spezialist und Schulungsleiter für Grundlagenschulungen bis hin zu Advanced-Coding- und Secure-SDLC-Trainings. Er beschäftigt sich seit Mitte der 90er-Jahre mit Softwareentwicklung, -architektur und -sicherheit. Er ist Sprecher auf Konferenzen und Autor mehrerer Fachartikel.
Ab Juni 2025 müssen in der EU viele digitale Produkte barrierefrei sein. Eines der großen Probleme bei der Umsetzung: der Testaufwand. Viele Dinge müssen von Hand überprüft werden, denn die automatischen Prüftools haben nur eine geringe Abdeckung. Wir Entwickler haben aber gerne ein Sicherheitsnetz von automatisierten Tests in der Pipeline. Wie können wir das für Barrierefreiheit erreichen?
In diesem Vortrag gebe ich euch das Handwerkszeug, um euch in Hinblick auf Barrierefreiheit besser abzusichern. Dabei lernen wir zunächst automatische Tools und ihre Möglichkeiten und Grenzen kennen. Danach schauen wir auf Strategien zum Schreiben eigener Tests mit gängigen Testframeworks. Abschließend schauen wir uns an, was AI in dieser Hinsicht für uns leisten kann.
Zielpublikum: Entwickler
Voraussetzungen: Grundkenntnisse in Webentwicklung
Schwierigkeitsgrad: Advanced
Anna Maier kommt ursprünglich aus der Java-Welt, fühlt sich aber mittlerweile im Frontend auch sehr wohl. Seit 2021 arbeitet sie als IT-Consultant für codecentric. Ihre Leidenschaft seit vielen Jahren ist das Thema Barrierefreiheit. Außerdem setzt sie sich für Frauen in der IT ein.
Am Anfang eines Projekts ist die Produktivität hoch. Architektur, Bausteine und Abhängigkeiten sind klar definiert. Doch mit der Zeit wird der Code immer umfangreicher und die Anforderungen werden komplexer. Es schleichen sich ungewollte Abhängigkeiten ein. Code und Architekturdiagramme passen nicht mehr zusammen.
Architekturtests wirken dem entgegen. Sie funktionieren wie Unit Tests, testen aber Anforderungen an die Architektur. Sie laufen automatisiert im Continuous Build und verhindern dadurch, dass sich Verstöße gegen die anfangs aufgestellten Architekturregeln einschleichen.
Der Vortrag gibt einen Überblick über die Möglichkeiten von Architekturtests und demonstriert anhand einer Beispielarchitektur, wie sich verschiedene Aspekte der Architektur testen lassen. Der praktische Anteil des Vortrags ist sehr hoch. Die Teilnehmer sind nach dem Vortrag in der Lage, das neu erworbene Wissen umgehend in eigenen Projekten praktisch anzuwenden.
Zielpublikum: Architekten und Entwickler
Voraussetzungen: Softwarearchitekturgrundlagen, Grundkenntnisse in .NET
Schwierigkeitsgrad: Advanced
Andreas Lausen ist Software Architect bei der MEDIFOX DAN GmbH. Der Schwerpunkt seiner Tätigkeit liegt auf der Konzeption und Umsetzung von langfristig wart- und erweiterbaren Softwaresystemen. Als Technologien setzt er hauptsächlich .NET und die iOS und Android SDKs ein.
Vortrag Teilen
Als Architekten, Entwickler oder Tester sind wir für die Qualität unserer Software verantwortlich. Trotzdem fokussieren sich viele Qualitätsinitiativen nur auf Richtlinien, Metriken und Werkzeuge und übersehen dabei diesen menschlichen Aspekt. Das führt dazu, dass sie oft ignoriert werden und sich Qualitätsprobleme ansammeln, die unseren Alltag erschweren.
Um dies zu verhindern, setzen wir seit über 10 Jahren erfolgreich Qualitätsretrospektiven bei Dutzenden Kunden ein: In regelmäßigen Workshops des Entwicklungs- oder Testteams werden Qualitätstrends und Verbesserungsvorschläge auf Basis von automatischen Analysen wie statischer Codeanalyse oder Test-Gap-Analyse diskutiert. Damit werden Teammitglieder abgeholt, ein Bewusstsein für Qualität geschaffen, Qualitätsthemen geschult und ein gemeinsames Qualitätsverständnis etabliert. Dieser Ansatz wird von Architekten, Entwicklern und Testern geschätzt, fördert ein Committment zu Qualität(smaßnahmen) und führt zu einer nachhaltigen, messbaren Qualitätssteigerung.
Dieser Vortrag stellt Qualitätsretrospektiven anhand von Kundenbeispielen vor und erläutert, wie man sie auf automatischen Qualitätsanalysen aufbaut und welche Faktoren für ihren Erfolg wichtig sind.
Zielpublikum: Architekten, Entwickler, Tester, Qualitätssicherer, Product Owner, Manager
Voraussetzungen: Interesse an Softwarequalität
Schwierigkeitsgrad: Basic
Dr. Tobias Röhm hat über Softwareanalysen und Programmverstehen promoviert, mehrere Jahre als Freelancer Software entwickelt und ist seit vielen Jahren Berater für Softwarequalität. Mit seinem Team unterstützt er vierzig Entwicklungsteams, Qualitätsanalysen durchzuführen und alltagstaugliche QS-Prozesse aufzusetzen und zu leben. Er hat Best-Paper-Awards auf zwei renommierten wissenschaftlichen Konferenzen gewonnen und spricht regelmäßig auf Konferenzen wie DWX, ESE, JFS und OOP.