Die im Konferenzprogramm des GTD 2022 angegebenen Uhrzeiten entsprechen der Central European Time (CET).
Gerne können Sie die Konferenzprogramm auch mit Ihren Kolleg:innen und/oder über Social Media teilen.
Der Track+ besteht aus Präsentationen der Sponsoren und unterliegt somit nicht der Qualitätssicherung des Conference Boards.
Bitte beachten Sie, dass es für vereinzelte Workshops ggf. eine Teilnehmendenbeschränkung gibt. Weitere Infos hierzu finden Sie in den Workshop-Beschreibungen.
G+D currency technology develops highly complex embedded software that operates in a challenging mechatronics environment. A major challenge has been the manual analysis of our automatic nightly test execution results - in particular with growing test sets and a complex test execution environment. Via an in-house developed tool that combines ideas of patterns and learning we have reduced our analysis time from hours to less than a minute. We believe this idea can drastically reduce time spent on analysis for any tester - even in manual system test - and will show how it can even help to automate processes in other contexts.
Target Audience: testers, developers, test managers, project managers
Prerequisites: Experience in test automation or analysis of test execution results
Level: Basic
Extended Abstract:
G+D currency technology has been developing its banknote processing system (BPS) products for many years now using an agile development approach which is supported by a sophisticated continuous integration (CI) pipeline. Every night thousands of unit tests as well as hundreds of functional tests are executed on our servers to ensure that the subsystem software operates correctly and that no regressions have been introduced during the day by software development. Our most complex BPS subsystem - the coordination subsystem - consists of multiple communicating processes which are developed based on a common platform by 6 independent teams in parallel sprints.Our test system used for functional tests is equally complex and includes simulations of other subsystems. Each functional test covers the entire cycle from subsystem software installation to taking the product through a complete workflow in a virtualized environment, and can take from 30 to 60+ min to execute. In each agile team, one automation tester is responsible for developing new and maintaining existing regression tests as well as monitoring each day the results of nightly automatic test execution. The effort spent on analysis is generally reasonable as long as most regression tests pass, but the required effort easily triples, e.g., when sporadic failures from our complex test environment interfere from time to time. We started realizing that the testers that work independently on similar but different products follow similar patterns in their (manual) analysis. A brilliant idea for a simple test result analysis tool enabled us to slash our time spent on analysis for each tester from hours to minutes.In this presentation, we want to present our pattern based approach and its integration into our CI pipeline, which we strongly believe can easily also be used by other testers to reduce their effort. We will talk about the ways in which we deployed the tool to even further automate our testing process at G+D, e.g., for smart automation of reruns for tests that have failed sporadically. Currently, we are even investigating to use this approach also to solve another big challenge we have been facing, which is to accurately and completely automatically track feature test coverage independent of the test implementation and the tests executed.
Graham Rawlings is a Test Architect at Giesecke + Devrient Currency Technology. With a mechatronics background and 38 years of software development and architecture experience in English and German companies, including 24 years with Giesecke + Devrient, he is now helping to extend and improve their TTCN-3 automated test infrastructure.
Dr. Stephan Schulz is a Test Architect at Giesecke + Devrient Currency Technology. For the past 20 years he has been researching, educating, consulting, and authoring numerous publications and standards on test automation and model based testing.
Vortrag Teilen
Gone are the days of throwing software builds over the proverbial wall to a team of testers that sit and click pages all day. The agile way of working has shown that maybe a small revolution has started to happen in the world of software developers. The rising of software developers writing e2e functional tests that check their front-end using real browsers. Challenges of having success in this way of doing test automation are real. Let's be sincere! Software Developers don't like to write tests much, but the right TA framework can help. In this talk I will describe what we did to make this dream come true.
Target Audience: Agile Teams, Developers, Testers
Prerequisites: Basic knowledge in Agile methods
Level: Basic
Extended Abstract:
Gone are the days of throwing software builds over the proverbial wall to a team of testers that sit and click pages all day. The agile way of working has shown that maybe a small revolution has started to happen in the world of software developers. The rising of software developers writing e2e functional tests that check their front-end using real browsers. Challenges of having success in this way of doing test automation are real. Let's be sincere! Software Developers don't like to write tests much, but the right TA framework can help. In this talk I will describe what we did to make this dream come true.
This is a real life story of how our product team made possible to succeed in delivering quality and speed in every sprint.
I have been working in IT for 15 years and I am a passionate software developer and solution architect. I work as a Web Technology Solutions Lead in the IT department at Raiffeisen Bank Albania in Tirana. In the last 2 years, I am also in the role of IT Delivery Lead for retail lending products. In this role I am promoting continuous testing philosophy inside product value teams as the most critical part to achieve speed and quality for the deliverables. I'm focused more and more to create a good developer experience in test automation and putting the word fun into doing it. In addition, I am an associate professor, who enjoys a lot learning to students the magic of web software development.
Die Auswahl von Testfällen aus einer Menge vorhandener Tests erfolgt in aller Regel anhand der Erfahrungen der Test-Manager oder Tester. Wir haben untersucht, inwiefern dabei Methoden der Künstlichen Intelligenz Unterstützung bringen. Welche Metriken können hier zum Einsatz kommen? Ist ein Neuronales Netz oder doch ein Entscheidungsbaum der effektivere Algorithmus? Und lässt es sich mit wenigen Zeilen Code in eine bestehende Testautomatisierung einbauen?
Zielpublikum: Tester, Testautomatisierer, Testmanager, Projektleiter
Voraussetzungen: Grundlagen SW-Test und Testautomatisierung, Grundlegende Java-Kenntnisse von Vorteil, aber nicht zwingend
Schwierigkeitsgrad: Advanced
Extended Abstract:
Eine Glaskugel, ob ein Test bei der Ausführung in Zukunft PASSED oder FAILED liefern wird, können wir leider nicht anbieten. Einen Algorithmus, der anhand von Daten früherer Testausführungen eine Wahrscheinlichkeit berechnet, ob ein Tests FAILED sein wird, hingegen schon. Im Rahmen des Vortrags werden wir diesen Ansatz vorstellen, verschiedene Metriken diskutieren (Letzte Ergebnisse, Ähnlichkeit von Testnamen, ...) und einen Vergleich verschiedener Machine-Learning-Methoden durchführen (kNN, DNN, SVM, Hoeffting-Tree). Die dabei entstandene Bibliothek 'CurrantRunner' ist auf GitHub als OpenSource verfügbar , demonstriert das Vorgehen am Beispiel von TestNG + JaCoCo + Maven und ist im entsprechenden Kontext sofort einsetzbar.
Andreas Döring studierte Computervisualistik in Magdeburg und ist seit 2011 im Test-Umfeld aktiv. Als Test-Manager kam er 2020 zur profi.com AG und unterstützt den Bereich der Testautomatisierung. Schwerpunkt seiner Tätigkeit ist die Frage, wie innovative Testautomatisierungslösungen erfolgreich umgesetzt werden können.
Getreu dem Motto 'Sing mal wieder' ist er Tenor bei den Spiritual- und Gospel-Singers Dresden, ergründet die Ruhe und Komplexität des Go-Spiels und zaubert mit Lenkdrachen akrobatische Figuren in den Himmel.
Je älter und größer Softwaresysteme sind, desto wichtiger ist eine verlässliche, automatisierte Testsuite. Da die Suite (und deren Ausführungsdauer) jedoch mit wächst, kommt ihr Feedback immer später, was das Lokalisieren von Fehlern erschwert. Eine wirksame Lösung ist, eine Teilmenge der Tests häufiger auszuführen. Zur Auswahl einer solchen Teilmenge haben wir Pareto-Testing und die Test-Impact-Analyse entwickelt. Im Vortrag stellen wir beide Ansätze vor und berichten vom Einsatz bei der Bayerischen Versorgungskammer, wo wir sie auf der großen automatisierten Testsuite eines komplexen Softwaresystems angewendet und verglichen haben.
Zielpublikum: Tester, Testmanager, Projektleiter
Voraussetzungen: Basiswissen über automatisiertest Testen.
Schwierigkeitsgrad: Advanced
Extended Abstract:
Je älter und größer ein Softwaresystem ist, desto wichtiger ist eine verlässliche, automatisierte Testsuite. Insbesondere, wenn viele Änderungen umgesetzt und kurze Release-Zyklen angestrebt werden. Mit der Größe des Systems wächst jedoch die Testsuite, und damit steigt auch deren Ausführungsdauer. Wir sehen bei unseren Kunden immer öfter Testsuites, die mehrere Stunden oder sogar Tage laufen. Langlaufende Testsuites werden aber meist seltener ausgeführt als schnelle, z.B. wöchentlich statt täglich. Dadurch müssen Entwickler länger auf Feedback warten, was es ihnen erschwert, die Ursache für fehlschlagende Tests zu lokalisieren. Ironischerweise mindert das den Wert der Testsuites gerade für die Systeme, für die sie besonders wichtig sind.
Ein wirksamer Lösungsansatz ist, eine Teilmenge mit viel kürzerer Laufzeit häufiger auszuführen, z.B. stündlich. Wenn diese Teilmenge gut gewählt ist, findet sie einen Großteil der Fehler in sehr kurzer Zeit, und die gesamte Testsuite kann weiterhin wöchentlich ausgeführt werden, um den Rest der Fehler zu finden. Damit erreichen wir, trotz langsamer Testsuite, sehr schnelles Feedback für die meisten Fehler.
Dieser Ansatz steht und fällt natürlich mit der Auswahl der Teilmenge an Tests, die häufig ausgeführt werden. Hierfür haben wir in den letzten Jahren zwei unterschiedliche Ansätze entwickelt: Pareto-Testing und Test-Impact-Analyse. Im Vortrag stellen wir erst die Grundideen und Forschungsergebnisse vor und dann die Erfahrungen, die wir bei der Bayerischen Versorgungskammer damit gesammelt haben, als wir beide Ansätze auf der großen automatisierten Testsuite eines komplexen Softwaresystems angewendet und verglichen haben.
Dr. Sven Amann ist Berater für Software-Qualität bei der CQSE GmbH. Er studierte Informatik an der TU Darmstadt und der PUC in Rio de Janeiro und promovierte am Fachgebiet Softwaretechnik der TU Darmstadt. Seit über 10 Jahren spricht Sven auf Konferenzen und Fachtagen. Sein Themenschwerpunkt ist Software-Qualitätssicherung auf allen Ebenen.
Mehr Inhalte dieses Speakers? Schaut doch mal bei SIGS.de vorbei: https://www.sigs.de/experten/sven-amann/
Seit Jahren spricht die Community über Automatisierung. Aber wie bringt man in der Praxis in kurzer Zeit Automatisierung ans Laufen? Wir zeigen Beispiele für erfolgreiche Automatisierung in Projekten der Deutschen Bundesbank. Die Projektteams haben einen modernen Open-Source Stack für Testautomatisierung mit BDD sowie Automatisierung im Bereich Infrastruktur aufgebaut. Stakeholder sind nun in der Lage auf Knopfdruck aus JIRA heraus komplette Testumgebungen zu erstellen, dort ihre Tests automatisiert auszuführen und Analysen der Ergebnisse zu bekommen. Du lernst hier wie ein solches Projekt aufgesetzt und die Lösung skaliert werden kann.
Zielpublikum: alle, die Kontakt zu Test haben
Voraussetzungen: keine
Schwierigkeitsgrad: Basic
Extended Abstract:
Seit Jahren sprechen wir in der Community über Automatisierung jeglicher Art wie bspw. Testautomatisierung oder Infrastruktur. Viele Ansätze aus Agile Testing, DevOps, etc. sind den meisten theoretisch bekannt. Aber wie sieht es in der Praxis aus? Wie schafft man es in kurzer Zeit die Methodik + Tools + Skills wirklich 'ans Laufen' zu bringen?In diesem Vortrag zeigen wir mehrere Beispiele für erfolgreiche Automatisierung in Projekten der Deutschen Bundesbank. Es handelt sich um Projekte von 10 bis >100 Personen. Diese Teams haben es geschafft einen modernen Open-Source Stack für Testautomatisierung mit BDD sowie komplette Automatisierung im Bereich Infrastruktur (Docker, Kubernetes, Rancher, Jenkins, etc.) aufzubauen und miteinander zu verheiraten. Jegliche Stakeholder in Projekten sind jetzt in der Lage 'auf Knopfdruck' innerhalb von wenigen Minuten komplette Umgebungen (komplexe Host-Systeme inkl. sämtlicher Einschränkungen eines Banking-Systems) zu erstellen, dort ihre Tests automatisiert auszuführen und Analysen der Testergebnisse automatisiert zu bekommen. Das ganze zentral aus JIRA heraus und im Umfeld komplexer Tests für den Zahlungsverkehr. So geht Testautomatisierung in der Bankwelt heute! Als Zuhörer:in lernst Du wie ein solches Projekt aufgesetzt werden kann, welche Stolpersteine wir dabei lösen mussten und wie eine solche Lösung skaliert werden kann. Das ganze sehr praxisnah an realen Beispielen aus Großprojekten mit einer guten Dosis Spaß an der Arbeit :)
Katja ist eigentlich Biologin, zählt aber neuerdings lieber bugs als Moleküle. Neben ihrer Arbeit als Testerin sucht sie Lösungen für die alltäglichen Probleme eines Testers in großen, agilen Projekten.
Nach seinem Abschluss in Wirtschaftsinformatik ist Simon nun seit über 10 Jahren in der QS unterwegs. Aktuell arbeitet er als Testmanager bei der Deutschen Bundesbank mit dem Fokus auf Zahlungsverkehr-Anwendungen.
Tobias programmiert seid 23 Jahren treu Java, nach seinem Informatik Studium begann er im Bereich Anwendungsentwicklung und QS zu arbeiten. Heute arbeitet er bei QualityMinds als Teamlead des R&D Teams.
Vortrag Teilen