Christoph Knopp & Daniel Simon

Christoph Knopp und Daniel Simon sind Teamleader für die Bereiche Testdatenmanagement, Test Consulting und Automatisierung bei der Trimetis GFB IT-Consulting GmbH. Wenn sie nicht gerade ihre Kunden beraten und deren Testvorgehen analysieren und optimieren sind sie auf der Suche nach neuen Trends und Entwicklungen im Softwaretest, immer mit dem Fokus auf Testdaten und agilen Testprozessen.

Dank Themen wie DevOps, Microservices und Kubernetes wird ein immer höherer Automatisierungsgrad in der Softwareentwicklung erreicht. Im Softwaretest muss deswegen Schritt gehalten werden – ohne Testautomatisierung geht es nicht mehr. Doch meist besteht hier noch eine Automatisierungslücke beim Testdatenmanagement. Manuelle Prozesse zum Extrahieren der richtigen Testdaten aus einem Produktionssystem mit anschließender langwieriger Anonymisierung der Daten passt in die DevOps-Welt einfach nicht mehr hinein. Ein Umdenken ist hier notwendig. In unserem diesjährigen Vortrag aus unserer Reihe „Zukunftssicheres TDM“ wollen wir anhand eines Praxisbeispiels zeigen, wie man auf dem Weg zur DevOps-Transformation diese Automatisierungslücke bei den Testdaten schließen oder zumindest schon mal verkleinern kann.

Currently I am working at parcIT GmbH as a software developer in the test automation department. Due to my expertise in the banking control, logistics, managed hosting, wholesale & retail and dialog marketing industries, I have versatile and intensive insights into different software landscapes and into very different business requirements.

It is often said that “test automation is software development”, so doesn’t any test automation need a software architecture? In this talk, I would like to use the example of our test automation with Cucumber to show how we concluded that we needed a software architecture, why we chose the hexagonal (or onion) architecture, and how it works. Maybe your test automation needs a software architecture too, or maybe not.

.

Bei fast jedem Softwareprojekt sind Last-/Performance-Tests Teil des Softwareentwicklungsprozesses.
Es gibt viele Werkzeuge und Methoden, um diese Tests durchzuführen.
In meinem Vortrag möchte ich meine Erfahrungen mit Last- und Performancetests weitergeben,
von der Erstellung des Testkonzepts über die Entscheidung für ein Tool oder Framework bis hin zu den fertigen Testfällen und deren Ergebnissen.
Der erste Teil des Vortrags befasst sich mit den Unterschieden zwischen Last- und Performancetests.
Danach werden Begriffe wie Metriken, Prüfungen und Schwellenwerte eingeführt. Im nächsten Teil des Vortrags werden Teststruktur und Testszenarien für Lasttests vorgestellt und ausführlich erläutert.
Mein Vortrag endet mit Beispielen für die Implementierung von Lasttests mit k6 und einigen anderen Performance-Testing-Tools
3 Denkanstöße:
1) Performance- und Lasttests haben besondere Eigenschaften, die bei der Testplanung zu berücksichtigen sind.
2) API-Lasttests sollten gründlich vorbereitet werden. Ihre Testziele und Erwartungen sollten klar definiert sein.
3) API-Lasttests sind eine sehr nützliche Methode zur Validierung der Leistung eines Softwareprodukts.

Jakub Kratochvil hat über 10 Jahre Erfahrung in diversen Rollen im Rahmen der Qualitätssicherung. Seit 2023 ist er als Test Architekt bei Capgemini für innovative Ansätze in Testmanagement und Testautomation verantwortlich. Gemäß seines Mottos: “Klasse, statt Masse” berät er Kunden rund um das Thema Qualitätsicherung. In seiner Freizeit widmet sich der Diplom-Informatiker feiner Schokolade und Rum.

Oft habe ich meiner Kollegin in der Entwicklungsabteilung gefragt, wie weit sie mit den Entwicklungsarbeiten fortgeschritten sind. Die häufigste Antwort lautete dabei: “Wir sind fast fertig!“ In den letzten Jahren vermehrt lautet diese Antwort: „Klar, wir sind fast fertig es muss nur noch der Barrierefreiheittest durch die externe Prüfstelle durchgeführt werden.“ Und dann findet diese Barrierefreiheitstest statt. Beim ersten Anlauf werden bereits viele Befunde festgestellt. Der Screenreader liest nicht korrekt vor, die Seite kann in bestimmten Auflösungen nicht korrekt abgebildet werden und die Tastaturbedienung funktioniert an einigen Seiten nicht oder die Tabsequenzen sind nicht intuitiv. In dem nächsten Sprint wird dann fleißig entwickelt, dann muss der Test wiederholt werden, die Anzahl der Findings wird dabei zwar niedriger. Oft ist aber ein dritter oder sogar vierter Anlauf notwendig bis der erwünschte Testat erreicht werden kann. Erschwerend kommt dazu noch, dass die Dauer der Feedbackschleife bei Barrierefreiheitstest sehr lang ist. Häufig muss ein separater externer Dienstleister beauftragt werden, der Test muss in bestimmten Umgebungen oder gar einem Usability Labor durchgeführt werden. Es ist nicht unüblich, dass zwischen den zwei Testläufen mehrere Wochen oder gar Monate vergehen. Das resultiert in Projektverzögerungen, aus fast fertig wird nicht ganz fertig.

Dr. Anne Kramer war lange Zeit bei der sepp.med gmbh als Projektleiterin, Prozessberaterin und Trainerin tätig, bis sie Ende 2021 beschloss, noch einmal völlig neue Wege zu gehen. Seit April 2022 ist Anne Global Customer Success Managerin bei Smartesting, einem französischen Hersteller von SW-Testwerkzeugen. Sie widmet sich somit voll und ganz der Softwarequalitätssicherung im Allgemeinen und dem modellbasierten Test im Besonderen. Seit neuestem befasst sie sich zudem mit den Einsatzmöglichkeiten von künstlicher Intelligenz im Bereich der Qualitätssicherung.

Alle Welt spricht von “Generative AI” (GenAI) und den scheinbar unendlichen Möglichkeiten, wie wir uns diese relativ neue Form künstlicher Intelligenz zu Nutzen machen können. Vermutlich haben die meisten unter uns bereits versucht, mit ChatGPT oder einem anderen Large Language Model (kurz: LLM) eine Aufgabe zu lösen. War das Ergebnis überzeugend? Radio Eriwan liefert die Antwort: “Im Prinzip ja, aber…” Die Art und Weise, wie ich der GenAI eine Aufgabe stelle, hat enormen Einfluss auf die Qualität der Antwort. Abgesehen vom erforderlichen Kontext ist es beispielsweise sinnvoll, Schritt für Schritt vorzugehen und nicht gleich alles auf einmal zu verlangen bzw. zu erwarten. Wie bringe ich also ChatGPT & Co dazu, sinnvoll zur Qualitätssicherung beizutragen? Welche Möglichkeiten, gibt es überhaupt, wie ich KI im Test nutzen kann und welche Risiken gehe ich damit ein? In diesem Vortrag werden wir uns ein paar konkrete Beispiele vornehmen und schauen, wie man am geschicktesten vorgeht, um schnell zu brauchbaren Ergebnissen zu kommen. Wir konzentrieren uns dabei auf Aufgaben rund um die Qualitätssicherung, wie z.B. die Testfallerstellung und deren Visualisierung. Außerdem schauen wir uns an, wie ich erkenne, ob meine KI “halluziniert” und wie sich dieser Effekt vermeiden lässt.

…

Using AI in sw development is quite “en vogue” nowadays.
But this often only relates to using it for coding – either coding for implementing the feature, or coding for implementing the automated test cases.
We will discuss a holistic approach – using AI across the whole software development process.
Either calling it the v-modell, or agile development phases like backlog creation, backlog refinement, sprint planning or “sprint implementation”.
Be curious about how we can expect being supported by AI, how we can improve or speed up our different tasks in developing software products – or not? Will there be no benefit? Will we be mislead by the system?
Having an idea for a quite simple new feature in our product, we will start a normal conversation with AI, like we would do with a team mate.
And as in a normal conversation, we will discover new aspects of this feature, different ways to implement it, be disappointed, get different views on the feature and on and on and on.

Dr. Wiesbrock arbeitet seit über 24 Jahren als Experte für Anforderungsmanagement und Test eingebetteter Systeme in den Bereichen Automotive, Medizintechnik und Energietechnik. Zuvor war er mehrere Jahre an verschiedenen Universitäten in der Forschung und Lehre für Mathematik und Theoretische Physik tätig. Anschließend arbeitete er zwei Jahre als wissenschaftlicher Mitarbeiter der DaimlerCrysler AG. Seit 2004 ist er Projektleiter und Fachexperte für eingebettete Systeme bei ITPower Solutions GmbH.

Dr. Sadeghipour studierte und promovierte am Fachbereich Informatik der TU Berlin. Seit dem Jahr 2000 ist er geschäftsführender Gesellschafter der ITPower Solutions GmbH. Das Berliner Unternehmen bietet branchenübergreifend Entwicklern eingebetteter Systeme Tools, Dienstleistungen und Beratung für die Entwicklung und den Test von Embedded Software. Darüber hinaus wirkt er seit 30 Jahren in verschiedenen Forschungsprojekten zu Testmethoden von Embedded Software mit und publiziert über dieses Thema in Fachzeitschriften und auf Konferenzen.

Der systematische Software-Test ist ein methodisches, werkzeugunterstütztes und wohlerprobtes Vorgehen, bei dem der Eingaberaum des Testobjekts adäquat durch Tests abgedeckt wird (Category Partition Method, Grenzwertanalyse, Klassifikationsbaum-Methode). Es ist ein Blackbox-Verfahren, welches eine von der Entwicklung unabhängige Prüfung der Qualität erlaubt. Ein solches, unabhängiges Vorgehen für den Test moderner KI-Systeme, die überwiegend auf Machine Learning (ML) basieren, gibt es bisher nicht, viele damit verbunden Fragen sind daher noch offen:  Wie und in welchem Umfang sollen Testdaten zur Qualitätssicherung eines KI-Systems gewählt werden?  Wie sollen die ausgeführten Tests bewertet werden?  Welche Aussage über die Qualität des Testobjekts lässt sich aus den ausgeführten Tests ableiten?  Wann soll man mit dem Testen aufhören (Testendekriterien)? Zwar gibt es Ansätze, welche Teilfragen beantworten, z.B. Ontologien, um Grenzbereiche zu identifizieren, oder Simulatoren, um die Zuverlässigkeit des Systems in speziellen Situationen zu messen. Diese Ansätze lassen jedoch die Frage nach der Gesamtqualität für den geplanten Einsatz des entwickelten KI-Systems offen. Dabei ist zu beachten, dass Akkuratheit und Präzision, die gängigen Qualitätsmerkmale ML-basierter Systeme, anhand der Trainingsdaten durch die Entwicklung bestimmt werden, und nicht durch einen unabhängigen Test. Die genannten Fragen entstehen, da ein KI-System probabilistisch arbeitet, statistisch schließt und keine deterministischen Ein/Ausgabe-Relationen in ihr implementiert sind. Daher ist ihre Qualität auch nach statistischen Kriterien zu bewerten. Im Vortrag wird ein Testansatz präsentiert, in dem die probabilistische Natur der KI im Mittelpunkt steht. Ein solcher Ansatz besitzt das Potential, die oben genannten Fragen zu beantworten und kann deshalb als Grundlage für den systematischen Test von KI-Systemen dienen.

Christoph Knopp und Daniel Simon sind Teamleader für die Bereiche Testdatenmanagement, Test Consulting und Automatisierung bei der Trimetis GFB IT-Consulting GmbH. Wenn sie nicht gerade ihre Kunden beraten und deren Testvorgehen analysieren und optimieren sind sie auf der Suche nach neuen Trends und Entwicklungen im Softwaretest, immer mit dem Fokus auf Testdaten und agilen Testprozessen.

Dank Themen wie DevOps, Microservices und Kubernetes wird ein immer höherer Automatisierungsgrad in der Softwareentwicklung erreicht. Im Softwaretest muss deswegen Schritt gehalten werden – ohne Testautomatisierung geht es nicht mehr. Doch meist besteht hier noch eine Automatisierungslücke beim Testdatenmanagement. Manuelle Prozesse zum Extrahieren der richtigen Testdaten aus einem Produktionssystem mit anschließender langwieriger Anonymisierung der Daten passt in die DevOps-Welt einfach nicht mehr hinein. Ein Umdenken ist hier notwendig. In unserem diesjährigen Vortrag aus unserer Reihe „Zukunftssicheres TDM“ wollen wir anhand eines Praxisbeispiels zeigen, wie man auf dem Weg zur DevOps-Transformation diese Automatisierungslücke bei den Testdaten schließen oder zumindest schon mal verkleinern kann.

Derzeit arbeite ich bei der parcIT GmbH als Softwareentwickler im Bereich Testautomatisierung. Aufgrund meiner Expertise in den Branchen Bankensteuerung, Logistik, Managed Hosting, Groß- und Einzelhandel sowie Dialogmarketing verfüge ich über vielseitige und intensive Einblicke in unterschiedliche Softwarelandschaften und in ganz unterschiedliche Geschäftsanforderungen. Currently I am working at parcIT GmbH as a software developer in the test automation department. Due to my expertise in the banking control, logistics, managed hosting, wholesale & retail and dialog marketing industries, I have versatile and intensive insights into different software landscapes and into very different business requirements.

Es wird oft gesagt, dass „Testautomatisierung Softwareentwicklung ist“. Braucht also keine Testautomatisierung eine Softwarearchitektur? In diesem Vortrag möchte ich am Beispiel unserer Testautomatisierung mit Cucumber zeigen, wie wir zu dem Schluss kamen, dass wir eine Softwarearchitektur benötigen, warum wir uns für die hexagonale (oder Zwiebel-)Architektur entschieden haben und wie sie funktioniert. Vielleicht benötigt Ihre Testautomatisierung auch eine Softwarearchitektur, vielleicht auch nicht. It is often said that “test automation is software development”, so doesn’t any test automation need a software architecture? In this talk, I would like to use the example of our test automation with Cucumber to show how we concluded that we needed a software architecture, why we chose the hexagonal (or onion) architecture, and how it works. Maybe your test automation needs a software architecture too, or maybe not. Es wird oft gesagt, dass „Testautomatisierung Softwareentwicklung ist“. Braucht also keine Testautomatisierung eine Softwarearchitektur?

Nach dem Abschluss ihres Studiums der Informatik und Computerlinguistik an der LMU hat Maria Shalnova-Weinzierl Erfahrungen in der Testautomatisierung mit verschiedenen Programmiersprachen (C#, Python, C++, TypeScript) und verschiedenen Tools und Test-Frameworks (Playwright, Selenium, Nightwatch, Protractor, Ranorex etc.) gesammelt. Maria arbeitete an der Testautomatisierung in mehreren Branchen: Messgeräte- Herstellung, Data Security, im medizinischen Bereich und in der Automotive-Branche. Seit sieben Jahren ist die Referentin bei der Carl Zeiss Digital Innovation GmbH als Senior Consultant Quality Assurance tätig. Maria ist Co-Organisatorin des MeetUps „BrowserStack Software Testing and Qa Meetup Group Munich“.

Bei fast jedem Softwareprojekt sind Last-/Performance-Tests Teil des Softwareentwicklungsprozesses. Es gibt viele Werkzeuge und Methoden, um diese Tests durchzuführen. In meinem Vortrag möchte ich meine Erfahrungen mit Last- und Performancetests weitergeben, von der Erstellung des Testkonzepts über die Entscheidung für ein Tool oder Framework bis hin zu den fertigen Testfällen und deren Ergebnissen. Der erste Teil des Vortrags befasst sich mit den Unterschieden zwischen Last- und Performancetests. Danach werden Begriffe wie Metriken, Prüfungen und Schwellenwerte eingeführt. Im nächsten Teil des Vortrags werden Teststruktur und Testszenarien für Lasttests vorgestellt und ausführlich erläutert. Mein Vortrag endet mit Beispielen für die Implementierung von Lasttests mit k6 und einigen anderen Performance-Testing-Tools 3 Denkanstöße: 1) Performance- und Lasttests haben besondere Eigenschaften, die bei der Testplanung zu berücksichtigen sind. 2) API-Lasttests sollten gründlich vorbereitet werden. Ihre Testziele und Erwartungen sollten klar definiert sein. 3) API-Lasttests sind eine sehr nützliche Methode zur Validierung der Leistung eines Softwareprodukts.

Oft habe ich meine Kolleg:innen in der Entwicklungsabteilung gefragt, wie weit sie mit den
Entwicklungsarbeiten fortgeschritten sind. Die häufigste Antwort lautete dabei: “Wir sind fast fertig!“ In den letzten Jahren vermehrt lautet diese Antwort: „Klar, wir sind fast fertig es muss nur noch der Barrierefreiheittest durch die externe Prüfstelle durchgeführt werden.“
Und dann findet diese Barrierefreiheitstest statt. Beim ersten Anlauf werden bereits viele Befunde festgestellt. Der Screenreader liest nicht korrekt vor, die Seite kann in bestimmten Auflösungen nicht korrekt abgebildet werden und die Tastaturbedienung funktioniert an einigen Seiten nicht oder die Tabsequenzen sind nicht intuitiv.
In dem nächsten Sprint wird dann fleißig entwickelt, dann muss der Test wiederholt werden, die Anzahl der Findings wird dabei zwar niedriger. Oft ist aber ein dritter oder sogar vierter Anlauf notwendig bis der erwünschte Testat erreicht werden kann. Erschwerend kommt dazu
noch, dass die Dauer der Feedbackschleife bei Barrierefreiheitstest sehr lang ist. Häufig muss ein separater externer Dienstleister beauftragt werden, der Test muss in bestimmten
Umgebungen oder gar einem Usability Labor durchgeführt werden. Es ist nicht unüblich,
dass zwischen den zwei Testläufen mehrere Wochen oder gar Monate vergehen. Das
resultiert in Projektverzögerungen, aus fast fertig wird nicht ganz fertig.

Dr. Anne Kramer war lange Zeit bei der sepp.med gmbh als Projektleiterin, Prozessberaterin und Trainerin tätig, bis sie Ende 2021 beschloss, noch einmal völlig neue Wege zu gehen. Seit April 2022 ist Anne Global Customer Success Managerin bei Smartesting, einem französischen Hersteller von SW-Testwerkzeugen. Sie widmet sich somit voll und ganz der Softwarequalitätssicherung im Allgemeinen und dem modellbasierten Test im Besonderen. Seit neuestem befasst sie sich zudem mit den Einsatzmöglichkeiten von künstlicher Intelligenz im Bereich der Qualitätssicherung.

Alle Welt spricht von “Generative AI” (GenAI) und den scheinbar unendlichen Möglichkeiten, wie wir uns diese relativ neue Form künstlicher Intelligenz zu Nutzen machen können. Vermutlich haben die meisten unter uns bereits versucht, mit ChatGPT oder einem anderen Large Language Model (kurz: LLM) eine Aufgabe zu lösen. War das Ergebnis überzeugend? Radio Eriwan liefert die Antwort: “Im Prinzip ja, aber…” Die Art und Weise, wie ich der GenAI eine Aufgabe stelle, hat enormen Einfluss auf die Qualität der Antwort. Abgesehen vom erforderlichen Kontext ist es beispielsweise sinnvoll, Schritt für Schritt vorzugehen und nicht gleich alles auf einmal zu verlangen bzw. zu erwarten. Wie bringe ich also ChatGPT & Co dazu, sinnvoll zur Qualitätssicherung beizutragen? Welche Möglichkeiten, gibt es überhaupt, wie ich KI im Test nutzen kann und welche Risiken gehe ich damit ein? In diesem Vortrag werden wir uns ein paar konkrete Beispiele vornehmen und schauen, wie man am geschicktesten vorgeht, um schnell zu brauchbaren Ergebnissen zu kommen. Wir konzentrieren uns dabei auf Aufgaben rund um die Qualitätssicherung, wie z.B. die Testfallerstellung und deren Visualisierung. Außerdem schauen wir uns an, wie ich erkenne, ob meine KI “halluziniert” und wie sich dieser Effekt vermeiden lässt. 

Using AI in sw development is quite “en vogue” nowadays.
But this often only relates to using it for coding – either coding for implementing the feature, or coding for implementing the automated test cases.
We will discuss a holistic approach – using AI across the whole software development process.
Either calling it the v-modell, or agile development phases like backlog creation, backlog refinement, sprint planning or “sprint implementation”.
Be curious about how we can expect being supported by AI, how we can improve or speed up our different tasks in developing software products – or not? Will there be no benefit? Will we be mislead by the system?
Having an idea for a quite simple new feature in our product, we will start a normal conversation with AI, like we would do with a team mate.
And as in a normal conversation, we will discover new aspects of this feature, different ways to implement it, be disappointed, get different views on the feature and on and on and on.

Dr. Wiesbrock arbeitet seit über 24 Jahren als Experte für Anforderungsmanagement und Test eingebetteter Systeme in den Bereichen Automotive, Medizintechnik und Energietechnik. Zuvor war er mehrere Jahre an verschiedenen Universitäten in der Forschung und Lehre für Mathematik und Theoretische Physik tätig. Anschließend arbeitete er zwei Jahre als wissenschaftlicher Mitarbeiter der DaimlerCrysler AG. Seit 2004 ist er Projektleiter und Fachexperte für eingebettete Systeme bei ITPower Solutions GmbH.

Dr. Sadeghipour studierte und promovierte am Fachbereich Informatik der TU Berlin. Seit dem Jahr 2000 ist er geschäftsführender Gesellschafter der ITPower Solutions GmbH. Das Berliner Unternehmen bietet branchenübergreifend Entwicklern eingebetteter Systeme Tools, Dienstleistungen und Beratung für die Entwicklung und den Test von Embedded Software. Darüber hinaus wirkt er seit 30 Jahren in verschiedenen Forschungsprojekten zu Testmethoden von Embedded Software mit und publiziert über dieses Thema in Fachzeitschriften und auf Konferenzen.

Software ist komplex. Komplexität lässt sich beherrschen, indem man sie reduziert. Deshalb zerlegen wir große Features in User Storys bzw. Anforderungen, die wir getrennt voneinander analysieren, bearbeiten und verifizieren. Dies hilft uns bei der Aufwandsabschätzung, der Planung und im Controlling. Insbesondere die Anforderungsüberdeckung ist eine beliebte Metrik, um den Fortschritt und die Qualität des Tests zu bewerten.

Doch wie aussagekräftig ist die vollständige Anforderungsüberdeckung tatsächlich? In ihrem Vortrag wirft Anne einen kritischen Blick auf die mit Abstand verbreitetste Methode, Vollständigkeit der Testabdeckung zu “beweisen” und zeigt alternative Ansätze. Im Anschluss an ihren Impulsvortrag werden wir das Thema in großer Runde (höchstwahrscheinlich kontrovers) diskutieren.