Track: Testing & Quality
- Dienstag
07.02. - Mittwoch
08.02. - Donnerstag
09.02.
Measuring quality requires many questions to be answered. The most obvious ones may be: “What is quality?”, but also “How can we measure it?”, “Which metrics are most accurate?”, “Which are most practical?”.
In this talk, I share some general motivations for measuring quality. I review commonly used metrics that claim to measure quality, I rate them with regards to how they may be helpful or harmful to achieve actual goals. I give some examples how the weaknesses of one metric might be countered by another one to create a beneficial system.
Target Audience: Developers, Project Leader, Manager, Decision Makers, Quality Engineers, Testers, Product Owners
Prerequisites: Basic Software Project Experience, Rough Understanding of Software Development
Level: Advanced
Extended Abstract:
Measuring quality requires many questions to be answered. The most obvious ones may be: “What is quality?”, but also “How can we measure it?”, “Which metrics are most accurate?”, “Which are most practical?”.
In my experience, one question is often not answered or postponed until it is too late: “Why do we want to measure quality?” Is it because we want to control how well our developers are performing? Is it to detect problems early? Is it to measure the impact of changes? Is it the product or the process we care about? Is it to improve locally in a single team or globally across the company? Is there a specific problem that we are trying to solve, and if so, which one?
Instead of trying to define what software quality is – which is hard and depends on a lot of factors – we should first focus on the impact of our measuring. Some metrics may work great for one team, but not for the company as a whole. Some will help to reach your team or organizational goal, some will not help at all, and some will even have terrible side effects by setting unintended incentives. Some can be gamed, others might be harmful to motivation. Consider an overemphasis on lead time, which can lead to cutting corners. Or measuring the number of bugs found, which can cause a testers versus developers situation.
In this talk, I share some general motivations for measuring quality. I review various commonly used metrics that claim to measure quality. Based on my experience, I rate them with regards to how they may be helpful or harmful to achieve actual goals and which side effects are to be expected. I give some examples how the weaknesses of one metric might be countered by another one to create a beneficial system.
Michael Kutz has been working in professional software development for more than 10 years now. He loves to write working software, and he hates fixing bugs. Hence, he developed a strong focus on test automation, continuous delivery/deployment and agile principles.
Since 2014 he works at REWE digital as a software engineer and internal coach for QA and testing. As such his main objective is to support the development teams in QA and test automation to empower them to write awesome bug-free software fast.
UI testing is an essential part of software development. But the automation of UI tests is still considered too complex and flaky.
This talk will cover the "state of the art" of UI testing with an overview of tools and techniques. It will be shown which kind of representations are used by today's test tools and how the addressing of elements in the UI is done.
In addition, the role of artificial intelligence in the different approaches is shown and a prediction of testing tools of the future is presented.
Target Audience: Developers, Testers
Prerequisites: Basic Knowledge of UI-Testing
Level: Advanced
Extended Abstract:
UI testing is an essential part of software development. Despite technological progress, the automation of UI tests is still considered too complex to function completely without manual intervention.
In addition to classical selector-based approaches, more and more image-based methods are being pursued.
This talk will cover the "state of the art" of UI testing with an overview of tools and techniques. In particular, current problems and future developments will be discussed. Furthermore, it will be shown which kind of UI representations are used by today's test tools and how the addressing of elements in the user interface is done.
In addition, the role of artificial intelligence in the different approaches is shown and a prediction of testing tools of the future is presented on the basis of current research.
Johannes Dienst is Developer Advocate at askui. His focus is on automation, documentation, and software quality.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Johannes.Dienst
At first glance, testing AI systems seems very different from testing “conventional” systems. However, many standard testing activities can be preserved as they are or only need small extensions.
In this talk, we give an overview of topics that will help you test AI systems: Attributes of training/testing/validation data, model performance metrics, and the statistical nature of AI systems. We will then relate these to testing tasks and show you how to integrate them.
Target Audience: Developers, Testers, Architects
Prerequisites: Basic knowledge of testing
Level: Basic
Extended Abstract:
From a testing perspective, systems that include AI components seem like a nightmare at first glance. How can you test a system that contains enough math to fill several textbooks and changes its behavior on the whims of its input data? How can you test what even its creators don’t fully understand?
Keep calm, grab a towel and carry on - what you have already been doing is still applicable, and most of the new things you should know are not as arcane as they might seem. Granted, some dimensions of AI systems like bias or explainability will likely not be able to be tested for in all cases. However, this complexity has been around for decades even in systems without any AI whatsoever. Additionally, you will have allies: Data scientists love talking about testing data.
In this talk, we give an overview of topics that will help you test AI systems: Attributes of training/testing/validation data, model performance metrics, and the statistical nature of AI systems. We will then relate these to testing tasks and show you how to integrate them.
Gregor Endler holds a doctor's degree in Computer Science for his thesis on completeness estimation of timestamped data. His work at Codemanufaktur GmbH deals with Machine Learning and Data Analysis.
Marco Achtziger is a Test Architect working for Siemens Healthcare GmbH in Forchheim. He has several qualifications from iSTQB and iSQI and is a certified Software Architect by Siemens AG.
Vortrag Teilen
Manuelle Tests wirken altmodisch, aufwendig und langsam. Trotzdem spielen sie in vielen wichtigen Softwaresystemen eine zentrale Rolle, auch langfristig.
In diesem Vortrag stelle ich Analysetechniken vor, die den Aufwand und die Durchführungszeit von manuellen Tests optimieren. Diese Techniken sind ursprünglich für automatisierte Tests entwickelt worden, lassen sich aber für manuelle Tests adaptieren, oft sogar mit besseren Ergebnissen.
Ich stelle die Grundlagen dieser Analysen vor und zeige Erfahrungen im Einsatz in der Praxis.
Zielpublikum: Tester, Test-Manager
Voraussetzungen: Erfahrungen mit manuellen Tests
Schwierigkeitsgrad: Anfänger
Extended Abstract:
Manuelle Tests wirken altmodisch, aufwendig und langsam: Im Vergleich zu automatisierten Tests haben sie einen sehr hohen manuellen Aufwand für die Durchführung. Test-Phasen dauern damit oft Wochen statt Stunden und verhindern dadurch potentiell kürzere Release-Zyklen.
Trotzdem spielen sie bei vielen missionskritischen Softwaresystemen eine entscheidende Rolle in der Qualitätssicherung: Weil sich einige Tests nicht oder nur mit unverhältnismäßig hohem Aufwand automatisieren lassen, oder weil manuelle Tests komplementär zu automatisierten eingesetzt werden, um andere Fehlertypen zu finden, etc. Unser Survey [1] unter 38 Testern aus 16 internationalen Firmen hat aufgezeigt, dass diese Firmen auch weiterhin manuelle Tests als integralen Bestandteil ihres QS-Prozesses sehen und beibehalten werden.
In diesem Vortrag möchte ich Analysetechniken vorstellen, um den Aufwand und die Durchführungszeit von manuellen Tests zu optimieren. Diese Techniken sind ursprünglich für automatisierte Tests entwickelt worden, lassen sich aber auch für manuelle Tests adaptieren. Da die Kosten für die manuelle Ausführung oft viel höher sind als bei automatisierten Tests, erzielen sie oft bei manuellen Tests die viel höheren Ersparnisse.
Ich gehe im Vortrag unter anderem auf folgende Analysen ein:
• Test-Priorisierung: Selektionsalgorithmen, die eine Teil-Testsuite ermitteln, die in kurzer Zeit einen möglichst großen Teil der Funktionalität testet. Diese „optimale Smoke-Test-Suite“ kann am Anfang einer Testphase ausgeführt werden, um zu verhindern, dass eine sehr fehlerhafte Version einer Software in den manuellen Test kommt, wo sich viele Fehler gegenseitig überdecken.
• Test-Impact-Analyse: Auswahl der Tests, die eine spezifische Änderung am Code durchlaufen. Dadurch können bei Hotfix-Tests in kurzer Zeit neue Fehler gefunden werden, die ggf. durch den Hotfix entstanden sind.
• Test-Gap-Analyse: Aufdeckung von Änderungen/neuen Features, die im manuellen Test übersehen und nicht getestet wurden (oder sich nach dem manuellen Test ergeben haben, und die Wiederholung des Tests erfordern).
Im Vortrag stelle ich sowohl die Grundlagen und Grenzen dieser Analysen vor, als auch Erfahrungen und Erfolge im Einsatz in der Praxis.
[1] "How Can Manual Testing Processes Be Optimized? Developer Survey, Optimization Guidelines, and Case Studies". Roman Haas, Daniel Elsner, Elmar Juergens, Alexander Pretschner. In Proceedings of the 29th ACM Joint Eurpoean Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE '21').
Dr. Elmar Jürgens 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 Teams bei der Verbesserung ihrer Qualitätssicherungs- und Testprozesse. Jürgens spricht regelmäßig auf Forschungs- und Industriekonferenzen und wurde für seine Vorträge mehrfach ausgezeichnet. Er wurde 2015 zum Junior Fellow der Gesellschaft für Informatik ernannt.
IT is always changing ... In this talk I'll do some crystal ball gazing from two perspectives. At heart, I’m a tester. For two years I’ve also been a CEO. I’ll look at what factors are at work and what kinds of effects will they have on how we work and the roles of testers and software professionals.
Alongside musings about the future, I’ll talk about concrete activities on an individual and company level to best prepare ourselves for this nebulous future.
Target Audience: Everyone
Prerequisites: None
Level: Basic
Extended Abstract:
I’m not the first person to notice that the world is constantly changing and that everything is impermanent. Most especially after the last two years, we have really been forced to come to terms with how quickly and drastically things can change. As IT professionals, we are aware of the intrinsic changeability of projects, contexts and our business, but the events of the last couple of years have put this into sharper focus.
But let’s not get too generally philosophical about the whole world. Let’s look at what is in our more immediate context and perhaps even in our sphere of influence. If our future is anything, it’s nebulous (and I don’t just mean the cloud). How will external changes shape our teams and our work, and how can we shape ourselves proactively in order to be able to respond to changes, make changes or our own and even thrive?
In this talk I’d like to do some triangulated crystal ball gazing from two perspectives. At heart, I’m a tester. For two years I’ve also been a CEO. From my passion for testing and my experience of business and people in organisations, I’ll look at what factors are at work now, what known unknowns we have and what kinds of effects will they have on how we work and the roles of testers and software professionals.
Alongside musings about the future, I’ll talk about concrete activities on an individual and company level to best prepare ourselves for this nebulous future.
Alex Schladebeck ist eine Testerin aus Leidenschaft. Ihr Herz schlägt für Qualität, Agilität und ihre Mitmenschen. Sie ist Geschäftsführerin und Leiterin der Qualitätssicherung bei der Bredex GmbH.
In diesen Rollen unterstützt sie Kollegen, Kunden und Teams in ihre Reise, bessere Qualität zu liefern: in Produkten, in Prozessen und in der Kommunikation.
In früheren Rollen war sie für die Befähigung von Teams und qualitativ hochwertige Systeme verantwortlich. Nun befähigt sie andere, genau das zu machen, und sorgt für eine Umgebung in der Firma, wo jede(r) aufblühen kann.
Alex schaut mit neugierigen Tester-Augen auf die Welt und möchte immer dazu lernen. Sie teilt ihr Wissen und ihre Erfahrungen in Workshops, Coachings und als Sprecherin oder Keynote-Sprecherin auf Konferenzen.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/alexandra.schladebeck
Vortrag Teilen
Dieses Problem kennen wir alle: In Projekten führt eine unzureichende Kommunikation oft dazu, dass die Software am Ende nicht so umgesetzt ist, wie die Auftraggebenden es sich am Anfang vorgestellt hatten.
Behaviour-Driven Development (BDD) setzt von Anfang an darauf, alle Stakeholder an einen Tisch zu holen und ein gemeinsames Verständnis über das gewünschte Verhalten der Software herzustellen. Daraus entsteht eine ausführbare Spezifikation, die zum richtigen Produkt nebenbei noch automatisierte Tests und eine lebendige Dokumentation liefert.
Zielpublikum: Product Owner, Entwickler:innen, Tester, Business-Analysten
Voraussetzungen: Grundkenntnisse in Java
Schwierigkeitsgrad: Anfänger
Extended Abstract:
SZENARIO: OOP Konferenz 2023
ANGENOMMEN DASS du wenig über BDD weißt
WENN du zu diesem Vortrag kommst
DANN lernst du das Grundprinzip kennen
ANGENOMMEN DASS du BDD bisher als Testmethode nutzt
WENN du zu diesem Vortrag kommst
DANN siehst du, dass noch viel mehr dahintersteckt
Behaviour-Driven Development ist ganz sicher keine neue, aber eine häufig missverstandene Methode. In vielen Teams wird BDD nur zum Testen eingesetzt. In diesem Talk gehen wir einmal gemeinsam den Weg von der ersten Beschreibung der Software bis zur Umsetzung im Code, um zu erkennen, dass der Fokus von BDD auf der Kommunikation zwischen allen an der Entwicklung Beteiligten liegt.
Katrin Rabow hat viele Jahre als selbstständige Beraterin kleine Unternehmen in ihrem kaufmännischen Alltag unterstützt, ehe sie sich 2015 für ein Studium der Wirtschaftsinformatik an der TU Darmstadt entschied. Sie sucht immer wieder nach Wegen, „harte“ Themen wie Software-Engineering mit „weichen“ Themen wie der Unternehmenskultur zu verbinden. Seit ihrem Masterabschluss arbeitet sie als IT-Consultant in Frankfurt.
Wann ist Code verständlich?
Wenn die Methoden kurz sind, wenn sprechende Namen verwendet werden, wenn ... diese Liste ist lang und zumindest in Auszügen bekannt. Verständlichkeit wird meist mit Faustregeln und Code-Smells beschrieben.
Wir möchten hier anders ansetzen: Verständlichkeit entsteht im Gehirn. Leicht verständlich bedeutet, dass das Gehirn gefordert wird, schwer verständlich, dass es überfordert wird.
Zielpublikum: Entwickler:innen, Architekt:innen, alle, die es interessiert
Voraussetzungen: Programmiersprachenkenntnisse (nur für die Beispiele)
Schwierigkeitsgrad: Anfänger
Extended Abstract:
Wir erarbeiten gemeinsam anhand eines Modells den Verständnisprozess, lernen wo unser Verständnis an seine Grenzen stößt, und demonstrieren Erkenntnisse an anschaulichen Code-Beispielen.
Interessant für jeden, der sich nicht nur für Code-Smells und Code-Konventionen interessiert, sondern auch gerne ein Blick auf das "Warum" wirft.
Stefan Mandel ist Full-Stack-Entwickler bei andrena objects und beschäftigt sich seit fast 20 Jahren mit Programmiersprachen, Prinzipien und Refactoring.
Als studierter Mathematiker findet Peter Guntermann eigentlich großen Gefallen daran, sich das Hirn über kniffligen Problemen zu zermartern. Doch wenn es darum geht, robuste und leicht wartbare Software zu entwickeln, hält er es am liebsten so simpel und gehirngerecht wie möglich. Clean Code und Domain-driven Design sind hierbei seine wichtigsten Begleiter, um die Herausforderungen im agilen Alltag zu bewältigen.
Vortrag Teilen
Requirements engineering like testing require balance of value and risk. Agile requirements engineering and testing with test-driven requirements engineering (TDRE) balances project risks and cost. Clear advantage: Requirements are understandable, testable, and directly applicable as test case. Lead time and costs in testing are reduced by up to thirty percent.
This presentation at OOP 2023 will practically introduce to agile requirements engineering and test with TDRE. A case study demonstrates an industry use of TDRE.
Target Audience: Project Managers, Architects, Analysts, Requirements Engineers, Product Owners, Software Engineers
Prerequisites: None
Level: Advanced
Extended Abstract:
Requirements engineering like testing require balance. Balance is about balancing value and risk. Requirements must be good enough to mitigate risks but yet not overly specific to contain effort. Same for test, which though never complete needs to address those areas with highest risk.
Requirements engineering and testing belong together. Historically, testers have often only seen the requirements after the system has already been partially implemented. This had two serious disadvantages. On the one hand, insufficient requirements quality came far too late to the table. On the other hand, it was quite a lot of extra work without deriving suitable test cases in the context of requirements definition. A lot of additional work and long correction loops were the result.
Only an agile balance of risk-oriented coverage and testable requirements can improve test effectiveness. Such risk-oriented work also optimizes requirements engineering. Instead of paralysis by analysis in defining numerous requirements, test-driven requirements engineering (TDRE) focusses on specifying what is necessary and of high risk or high value.
TDRE is straight-forward: Test cases are developed in parallel to the requirements. Thus, the feasibility of the requirements is analyzed much faster than in the traditional sequential approach, in which tests are specified relatively late. The test cases are initially described in the same structure as the requirements and as a supplement to the respective requirements. This shifts Test-Driven Development (TDD), which has already proven itself as relevant agile methodology, to the specification level. Regression tests are attributed in order to prepare for later automation. The effort required for testing can be better estimated on this basis, and project and quality risks are thus reduced.
TDRE follows a triple peak model, which is connecting requirements (i.e., needs), design (i.e., solution) and test (i.e., the product).
It intertwines three perspectives:
• Market perspective: “How can I meet customer satisfaction and needs?”
• Design perspective: “How can I implement the solution to meet requirements?”
• Testing perspective: “How can I find a defect and cause the product to fail?”
Here some guidance from our projects, which we will further illustrate in this presentation:
• Every single functional requirement has at least one acceptance check, which is either fulfilled or not fulfilled and serves as the agile DoD (definition of done).
• Each individual quality requirement is described with numerical values that can be measured.
• Business rules are defined so that it can be determined whether they are true or false.
• Business and data objects are defined with all their attributes, types and states so that they can be set and validated at test time.
• System interfaces such as GUIs, reports and service interfaces are included in the requirements document so that values can be assigned to them.
• All use cases have pre- and post-conditions that can be generated and validated.
• All text is marked so that it can be automatically processed to generate test cases.
Agile requirements engineering and testing with test-driven requirements engineering (TDRE) balances project risks and cost. Clear advantage: Requirements are understandable, testable, and directly applicable as test case. Lead time and costs in testing are reduced by up to thirty percent. This presentation at OOP 2023 will practically introduce to agile requirements engineering and test with TDRE. A case study from medical cybersecurity demonstrates an industry use of TDRE.
Christof Ebert is managing director at Vector Consulting Services. He supports clients around the world in agile transformations. Before he had been working for ten years in global senior management positions. A trusted advisor and a member of several of industry boards, he is a professor at the University of Stuttgart and at Sorbonne in Paris. He authored several books including "Requirements Engineering" published by dPunkt and in China by Motor Press. He is serving on the editorial Boards of "IEEE Software" and "Journal of Systems and Software (JSS)".
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/christof.ebert
Wir sind in 20 Jahren zu einer 100-Personen-Entwicklungseinheit herangewachsen, die große komplexe Software-Projekte umsetzt. Jetzt haben wir uns entschlossen, ein Qualitätsmanagementsystem (QMS) nach ISO 9001 einzuführen.
Wir haben dabei festgestellt, wie wichtig die Integration des QMS in unsere Kultur und wie notwendig ein iteratives partizipatives Vorgehen ist. In diesem Vortrag stelle ich einige Herausforderungen vor und wie wir diese so gelöst haben, dass unser QMS unsere Qualität verbessert, ohne die Entwickler:innen zu quälen.
Zielpublikum: Architekt:innen, Projektleiter:innen, Manager, Entscheider
Voraussetzungen: Grundlagen in Qualitätsmanagement
Schwierigkeitsgrad: Fortgeschritten
Dr. Torsten Fink ist Geschäftsführer der Berliner Einheit der akquinet. Neben der Leitung von Softwareprojekten führte er vor seiner Managementtätigkeit Architektur- und Technologieberatungen durch. Aus dem eher technischen Bereich verteilter Systeme kommend, beschäftigt er sich in letzter Zeit immer mehr mit qualitätsorientierten Prozessen und modernen Organisationsstrukturen.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/torsten.fink
Nach einem Studium in der Wirtschaftsinformatik arbeitet Jana Metz in der Berliner Niederlassung der akquinet als Qualitätsmanagementbeauftragte und IT-Projektmanagerin mit den Schwerpunkten E-Health. Telematikinfrastruktur und Medizinproduktentwicklung. Sie ist maßgeblich an dem Aufbau des firmeneigenen QM-Systems beteiligt und unterstützt dessen Einführung und Umsetzung in der agilen Softwareentwicklung.
Christian Koska ist Qualitätsmanagementbeauftragter der Berliner Einheit der akquinet. Er ist somit mitverantwortlich für die Einführung eines individuellen QM-Systems. Ursprünglich im klinischen Studien- und Controllingbereich angesiedelt, ist er heute fachlich beratend in Softwareentwicklungsprojekte für den Health-Sektor involviert. Die letzten Jahre widmete er zunehmend den regulatorischen Anforderungen an Medizinprodukte sowie dem Aufbau und Betrieb von QM-Systemen.
Vortrag Teilen
Qualitätsziele helfen uns, Architekturentscheidungen fundierter zu treffen. Die genau richtige Qualität ist jedoch oft subjektiv und ändert sich über die Zeit hinweg. Dies macht das Arbeiten mit und an Qualitätszielen vor allem bei langlebigen Softwaresystemen spannend.
In diesem Vortrag stelle ich eine neue Sicht auf Softwarequalität vor, bei der wir Qualität im evolutionären Kontext betrachten. Als Basis verwende ich das ISO 25010-Qualitätsmodell sowie Wardley Mapping, um die passende Qualität nach Wichtigkeit und Evolutionsstufen zu finden.
Zielpublikum: Software-Architekt:innen, Entwickler:innen
Voraussetzungen: Erfahrung mit optimierungsbedürftigen Softwaresystemen
Schwierigkeitsgrad: Anfänger
Extended Abstract:
Die Balance der passenden Qualitätszielen ist ein herausforderndes Thema. Qualitätsziele sind aber sehr wichtig in der Entwicklung passender Softwaresysteme. Sie helfen uns, Architekturentscheidungen fundierter zu treffen. Die „genau richtige Qualität“ hängt dabei stark vom Betrachtungspunkt verschiedener Stakeholder ab. Zudem ändern sich Ansprüche an die Qualitäten eines Softwaresystems über die Zeit hinweg. Dies macht das Arbeiten mit und an Qualitätszielen vor allem in langlebigen Softwaresystemen immer wieder spannend.
In diesem Vortrag stelle ich eine neue Sicht auf Softwarequalität vor, wo wir Qualität im evolutionären Kontext betrachten. Als Basis verwende ich hierzu das ISO 25010-Qualitätsmodell sowie Wardley Mapping. Damit lassen sich notwendige Qualitäten nach ihrer Wichtigkeit und Evolutionsstufen von Softwaresystemen kommunizieren. Der Vortrag verzahnt die evolutionäre Sicht auf Softwarequalität mit Beispielen aus der Praxis und zeigt, wie sich damit die richtige Balance zwischen zu viel und zu wenig Qualität gestalten lässt.
Markus Harrer arbeitet seit mehreren Jahren in der Softwareentwicklung und ist vor allem in konservativen Branchen tätig. Als Senior Consultant hilft er, Software nachhaltig und wirtschaftlich sinnvoll zu entwickeln und zu verbessern. Er ist aktiver Mitgestalter in Communities zu den Themen Software Analytics, Softwarearchitektur, Softwaresanierung und Java. Zudem ist er akkreditierter Trainer für den iSAQB Foundation Level und dem Advanced-Level-Modul IMPROVE.
Ist uns Softwerkern wirklich klar, was wir meinen, wenn wir von Technischen Schulden sprechen? “Klar”, ist die Antwort. Wirklich? Warum haben wir dann Schwierigkeiten, POs/Projektleiter/Abteilungsleiter vom notwendigen Budget zu überzeugen?
Im Vortrag zeigen wir, wie es datenbasiert besser geht. Wie man für Technische Schulden KPIs erfasst und wie man jeweils Code-, Architektur-, Test-Qualität, Team-Kollaboration mit den KPIs korreliert, um eine Kosten-Nutzen-Analyse durchzuführen. Trotz Microservices und DevOps - die Herausforderungen bleiben.
Zielpublikum: Architekt:innen, Projekt-/Technische Leiter:innen, Key Developer, Manager, Entscheider
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Ist uns Softwerkern wirklich klar, was wir meinen, wenn wir von Technischen Schulden sprechen? “Klar”, ist die Antwort, “es geht um Smells, Bugs, Bedarf an Refactoring, fehlende Tests …”. Zum Teil können wir deren Umfang und Bedarf sogar messen. Aber wie entscheiden wir, was wir zuerst angehen sollen? Wie und was messen wir, sodass andere Stakeholder uns überhaupt verstehen und wir POs, Projektleiter und Abteilungsleiter vom notwendigen Budget überzeugen können?
Im Vortrag zeigen wir, wie man datenbasiert bessere Antworten findet. Was man mit den Folgen der Technischen Schulden anfängt, Wartungs- und sich verstärkende Mehraufwände in der Entwicklung als KPIs erfasst und deren Hotspots im Code identifiziert. Wie man jeweils Code-, Architektur- und Test-Qualität usw. als Ursachen identifiziert und mit den KPIs korreliert. Und wie man Technische Schulden in der Architektur in Zahlen prognostiziert, um eine Kosten-Nutzen-Analyse durchführen zu können. Und wie sich Team-Kollaboration auch auf Technische Schulden auswirkt.
Diese Herausforderungen sind seit mehreren Jahrzehnten die gleichen. Daran haben auch Microservices nichts geändert.
Die Teilnehmer erhalten Antworten auf folgende Fragen:
• Was sind Technische Schulden genauer?
• Wie misst man die Folgen?
• Wie sieht eine effektive Ursachenanalyse aus?
• Wie überzeuge ich andere Stakeholder von der Notwendigkeit?
• Wie wirkt sich Team-Kollaboration auf Technische Schulden aus?
Jede kleine Änderung an einem Embedded System kann bösartigste Auswirkungen haben. Findet und behebt man die Probleme zu spät, ist die Behebung zudem sehr teuer.
In Vortrag und Demo wird gezeigt, wie man durch Verbindung von Hardware-in-the-Loop und Continuous Integration jede Änderung an einem Embedded System innerhalb von Minuten testen kann, statt lange auf die Durchführung von Systemtests zu warten.
Zielpublikum: Architekt:innen, Embedded Entwickler:innen, Qualitätsmanager, Projektleiter:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Jede kleine Änderung an einem Embedded System kann bösartigste Auswirkungen haben. Findet und behebt man die Probleme zu spät, ist die Behebung zudem sehr teuer.
Daher sollte jede Änderung an einem Embedded System innerhalb von Minuten getestet werden können. Nur so kann man sicherstellen, dass man die Probleme schnell entdecken und beheben kann.
Bei reinen Softwareprojekten hilft eine vollständige Automatisierung der Tests über Continuous Integration (CI). Hierbei löst jede Codeänderung automatisch den Bau und Test der kompletten Software aus. Dadurch kann innerhalb von Minuten ein vollständiger Regressionstest Fehler in bestehendem und neuem Code entdecken.
Aber wie kann man das für System- oder Integrationstests bei Embedded Systemen erreichen?
Dafür nötige Hardware-in-the-Loop-Tests (HIL-Test) oder manuelle System-Tests sind häufig schwer zu automatisieren.
* Echte Hardwareanteile im Testaufbau verhindern die Automatisierung und Wiederholbarkeit
* Häufig kann nur der "Happy Path", nicht aber ein Fehlverhalten getestet werden
* Der Teststand ist häufig zu teuer, um für jedes Projekt, jederzeit für Automatisierung verfügbar zu sein
Durch den leichtgewichtigen Hardware-in-the-Loop-Test mit dem miniHIL kann man die Tests vollständig über Continuous Integration automatisieren.
Wie geht das?
* Hardwareschnittstellen werden nur auf Signalebene simuliert und passen daher gut in die Test-Automatisierung
* Testhardware wird größtenteils durch Softwaresimulationen ersetzt
* Fehlverhalten kann einfach über fehlerhafte Signale simuliert und getestet werden
* Die dazu nötige Hardware ist signifikant einfacher, kleiner und preiswerter als traditionelle HIL-Systeme. Für jedes Projekt steht jederzeit ein eigener Testaufbau für die Automatisierung zur Verfügung.
So kann jede Änderung innerhalb von Minuten automatisch getestet werden. Erst durch die vollständige und schnelle Testautomatisierung kann effektiv in Teams gemeinsam komplexe Embedded Software entwickelt werden.
Der Vortrag schließt mit einer Live-Demo eines solchen Testaufbaus.
Thomas Schütz studierte Luft- und Raumfahrttechnik in München und gründete 1997 die PROTOS Software GmbH. Als Softwareprojektleiter oder Architekt konnte er seine Erfahrung in der Verbindung modellbasierter Ansätze mit den Anforderungen von Embedded Systemen in zahlreiche Projekte einbringen. Thomas Schütz berät Firmen beim Aufbau von domänenspezifischen Werkzeugketten und Testsystemen für Embedded Systeme und ist Projektleiter des Eclipse-Projektes eTrice.
Vortrag Teilen
In der Entwicklungsabteilung der Carl Zeiss SMT GmbH arbeiten mehr als 30 Scrum-Teams. Für diese wurde ein übergreifendes „QA Manifest“ erstellt, das die grundlegenden Werte für die Qualitätssicherung definiert, Empfehlungen ausspricht sowie Anleitungen und Good Practices beinhaltet.
Im Vortrag werden die Ergebnisse vorgestellt, aber besonders wird auf die Erkenntnisse und Überraschungen eingegangen, die während der Workshops, Interviews und Arbeit mit allen Beteiligten auftauchten.
Zielpublikum: Tester, Entwickler:innen, Projektleiter:innen, Manager, Entscheider,
Voraussetzungen: Fachkenntnisse agile Methoden
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Die Entwicklungsabteilung EMI der ZEISS Semiconductor Manufacturing Technology hat sich in den letzten Monaten erfolgreich einer agilen Transition unterzogen. Es gibt nun mehr als 30 Scrum-Teams, die verschiedene Softwareprodukte entwickeln und anpassen. Im nächsten Schritt sollte ein übergreifendes „QA Manifest“ entstehen, das die grundlegenden Werte für die Qualitätssicherung definiert, Empfehlungen ausspricht sowie Anleitungen und Good Practices beinhaltet.
Dabei wurden umfangreiche agile Workshops durchgeführt, um alle Teams abzuholen, gemeinsam mit dem QualityChapter der EMI ein Vorgehen erarbeitet und die Ergebnisse abschließend verprobt.
Ziel war es, einen einfachen Ansatz zu finden, der die Herausforderungen einer agilen Qualitätssicherung gemeinsam mit den Scrum-Teams angeht und dabei die Anforderungen der Stakeholder im Auge behält sowie die Kommunikation mit allen Beteiligten sicherstellt. Darüber hinaus mussten auch Wege gefunden werden, um Anforderungen der Qualitätssicherung in einem skalierten Umfeld effektiv umzusetzen.
Im Vortrag werden die Ergebnisse vorgestellt, aber besonders wird auf die Erkenntnisse und Überraschungen eingegangen, die während der Workshops, Interviews und Arbeit mit allen Beteiligten auftauchten.
Projected learning outcomes / lessons learned for participant:
* Good Practices und Hinweise für agile Qualitätssicherung im komplexen Umfeld
* Ansätze für kollaborative und verteilte Workshops mit vielen Teilnehmern und vielen Teams
* Vorstellung der Schwerpunkte für spezielles Projekt
* Individuelle Ansätze für agiles Testen im skalierten Umfeld
* Einführung (Vorstellung des Projektes und der Aufgabenstellung)
* Erste Schritte (Schulungen, kollaborative und verteilte Workshops mit 20 Teams zur Aufnahme des IST-Standes)
* Gemeinsame Erarbeitung des Testvorgehens (Vorgaben, Anleitung, Good Practices, Definition von gemeinsamen Arbeitspaketen)
* Umsetzung des Testvorgehens (Coaching der Teams, Erarbeitung der gemeinsamen Arbeitspakete)
* Abschluss (Erkenntnisse und Ausblick)
Kay Grebenstein arbeitet als Head of QA für die Business Line Manufacturing Solutions bei der ZEISS Digital Innovation. In seiner Zeit als Testmanager und agiler QA-Coach hat er in den letzten Jahren in Projekten unterschiedlicher fachlicher Domänen (Industrie, Semiconductor, Energie, …) Qualität gesichert und Software getestet.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Kay.Grebenstein
Vortrag Teilen