Synchronisation zwischen Embedded-Softwareentwicklung und Testautomatisierung im agilen Entwicklungsprozess

Rund 70 % der Unternehmen setzen heute auf agile Softwareentwicklung¹, auch im Embedded-Umfeld setzen erfahrungsgemäß die meisten Firmen auf agile Methoden. Agilität bedeutet wie der Name bereits andeutet vor allem Flexibilität. Diese Flexibilität erhöht jedoch zugleich die Anforderungen an eine enge Kommunikation und eine systematische Synchronisation zwischen Entwicklung und Test.

In diesem Artikel gehen wir gezielt auf die Synchronisation zwischen agiler Embedded-Softwareentwicklung und der Entwicklung eines Testautomatisierungssystems (TAS) ein.

Zunächst betrachten wir den agilen Softwareentwicklungszyklus, klären, für welche Projekte sich ein TAS lohnt und für welche nicht, erläutern den grundsätzlichen Aufbau eines solchen Systems und zeigen abschließend, wie sich Produktentwicklung und die Entwicklung des TAS sinnvoll miteinander synchronisieren lassen.

Der agile Softwareentwicklungszyklus (SDLC)

Bevor wir verstehen, wie sich diese beiden Prozesse synchronisieren lassen, müssen wir zunächst einmal verstehen, aus welchen Teilen ein agiler Softwareentwicklungszyklus besteht.

1. Anforderungen sammeln
   • In der Phase der Anforderungserhebung arbeiten alle relevanten Stakeholder eng zusammen, um die Ziele, Erwartungen und Prioritäten des Projekts zu identifizieren.
2. Anforderungen ausarbeiten
   • In dieser Phase werden die gesammelten Anforderungen in konkrete, umsetzbare Aufgaben überführt. Auf dieser Basis werden später auch Testfälle und Abnahmekriterien definiert.
3. Design & Entwicklung
   • Die Softwarearchitektur wird entworfen und in kurzen, iterativen Entwicklungszyklen (Sprints) umgesetzt. Jeder Sprint liefert funktionsfähige Teilversionen des Produkts.
4. Test
   • Tests sind fester Bestandteil jeder Iteration. Unit-Tests überprüfen einzelne Softwarekomponenten und werden von den Entwicklern geschrieben. Integrations- und Systemtests stellen sicher, dass einzelne Komponenten des Systems oder das System als Ganzes die Anforderungen erfüllt. Diese Tests werden in der Regel von dedizierten Testern entworfen und durchgeführt.
5. Release
   • Die entwickelten Software-Inkremente werden regelmäßig (häufig durch OTA-Updates) in die Produktionsumgebung überführt.
6. Feedback sammeln
   • Stakeholder und Anwender geben kontinuierlich Rückmeldungen, die in der Praxis häufig über den Product Owner (PO) gebündelt werden. Die gewonnenen Erkenntnisse fließen in die weitere Planung und Entwicklung des Produkts ein.²

Bei dem Embedded-Entwicklungszyklus als ganzen kommt noch neben der Software die Entwicklung der eigentlichen Hardware mit dazu. In der Praxis werden erste Prototpyen häufig auf Development-Boards von dem jeweiligen Hersteller entwickelt, fehlende Funktionalitäten werden durch Module oder zusätzliche Development-Boards ergänzt. Die Entwicklung der Hardware erfolgt dann meist parallel zu der Softwareentwicklung.

Mit der Entwicklung eines TAS kommt nun ein drittes Zahnrad in den Prozess. Wir haben jetzt einen Entwicklungszyklus mit drei beweglichen Teilen.

Um effizient und effektiv zu arbeiten ist es daher wichtig, dass diese drei Zahnräde perfekt in einander greifen und synchronisiert sind. In diesem Artikel gehen wir gezielt auf die Synchronisation zwischen zwei dieser Zahnräder ein: der Embedded-Softwareentwicklung und der Entwicklung des TAS.

Manuelles vs. automatisiertes Testen im agilen Embedded-Umfeld

Der klassische Ansatz, bei dem Software zunächst vollständig entwickelt und erst am Ende getestet wird, kann grundsätzlich funktionieren, ist jedoch nicht agil. In agilen Softwareprojekten lautet die entscheidende Frage nicht, ob kontinuierlich getestet wird, sondern wie kontinuierlich getestet wird. Ein agiler Entwicklungsprozess testet per Definition fortlaufend, um möglichst schnell und häufig Feedback zu erhalten. Ziel dieses schnellen Testfeedbacks ist es, Fehler frühzeitig zu erkennen und dadurch den gesamten Entwicklungsprozess zu beschleunigen.

Für die Umsetzung des Testens stehen grundsätzlich zwei Methoden zur Verfügung manuelles und automatisiertes Testen. In der Praxis ist eine Kombination beider Ansätze ideal. Selbst bei sehr kleinen Entwicklungsprojekten sollten Unit-Tests implementiert werden, diese werden grundsätzlich automatisiert ausgeführt.

Die zentrale Fragestellung stellt sich auf der Integrations- und Systemtestebene: Soll der überwiegende Teil dieser Tests manuell oder automatisiert durchgeführt werden? Der Begriff überwiegend ist dabei bewusst gewählt, da automatisierte Tests nicht alle manuellen Tests ersetzen können und manuelle Tests umgekehrt nicht alle automatisierten Tests ersetzen können. Exploratives Testen beispielsweise basiert auf menschlicher Intuition und Erfahrung und ist daher nicht sinnvoll automatisierbar. Auf der anderen Seite gibt es Testarten wie Performance- oder Stresstests die ohne Automatisierung praktisch nicht durchführbar sind.

Daraus ergibt sich, dass manuelle und automatisierte Tests komplementäre Rollen im Testprozess einnehmen. Eine effektive Teststrategie kombiniert beide Ansätze gezielt, um sowohl funktionale Korrektheit als auch Systemverhalten unter realistischen und extremen Bedingungen zuverlässig bewerten zu können.

Im Embedded-Umfeld sind automatisierte, hardwarenahe Integrations- und Systemtests besonders relevant. Als TAS kommen hier häufig Hardware-in-the-Loop-Testumgebungen (HiL) zum Einsatz, deren Aufbau abhängig von der Systemkomplexität sehr aufwendig sein kann. Daher ist eine sorgfältige Evaluierung erforderlich, um zu entscheiden, ob sich der Einsatz eines HiL-Testumgebung wirtschaftlich lohnt. Aufgrund der hohen Relevanz von HiL-Testumgebungen im Embedded-Umfeld wird im weiteren Verlauf dieses Artikels gezielt auf diese eingegangen.

Lohnt sich eine HiL-Testumgebung?

Um herauszufinden, ob sich eine HiL-Testumgebung finanziell lohnt solltet ihr euch Fragen wie groß die Ersparnis durch solch ein System wären und wie groß das Investment sein muss.

Die Ersparnis hängt, u.a. von folgenden Faktoren ab:

• benötigte Zeit für die manuelle Ausführung eines Testfalls, inkl. Setup der Testumgebung
• Anzahl der Testfälle
• Anzahl der Testdurchläufe

Dem gegenüber steht das Investment in die HiL-Testumgebung, das u.a. von folgenden Faktoren abhängt:

• Aufwand für den Aufbau der HiL-Testumgebung
• Durchschnittlicher Wartungsaufwand für die HiL-Testumgebung
• Anzahl nicht automatisierter Testfälle
• Durchschnittlicher Entwicklungsaufwand für das schreiben (automatisieren) von Testfällen
• Anzahl automatisierter Testfälle
• Durchschnittlicher Wartungsaufwand pro automatisierten Testfall³

Dies ist ein vereinfachtes Modell und berücksichtigt ausschließlich den direkten Vergleich zwischen manuellem und automatisiertem Testen. Indirekte wirtschaftliche Effekte, wie verkürzte Entwicklungszyklen, geringere Fehlerkosten durch frühzeitige Fehlererkennung infolge kürzerer Ausführungszeiten und höherer Testfrequenz oder eine schnellere Markteinführung durch frühzeitiges Feedback, sind in der Betrachtung nicht berücksichtigt und erhöhen den tatsächlichen wirtschaftlichen Nutzen in der Praxis zusätzlich. Diese Vorteile lassen sich allerdings nur schwer quantitativ erfassen.

Wenn also bereits auf Basis der genannten Faktoren die erwarteten Einsparungen die Investitionskosten übersteigen, kann mit hoher Sicherheit davon ausgegangen werden, dass sich der Einsatz einer HiL-Testumgebung wirtschaftlich lohnt.

Die folgende Grafik zeigt den Verlauf von kumulierten Investitionen und kumulierten Einsparungen über mehrere Sprints. Der Punkt, an dem sich beide Kurven schneiden, markiert den Break-even-Point der HiL-Testumgebung, also den Zeitpunkt, ab dem diese beginnt, einen positiven wirtschaftlichen Effekt zu erzielen. Daraus lässt sich ableiten, dass sich die Entwicklung solch einer Testumgebung insbesondere für Projekte mit längerer Laufzeit oder hoher Testfrequenz wirtschaftlich lohnt.

Die Grafik dient lediglich der Veranschaulichung. Abhängig von der Höhe der Investition in die HiL- Testumgebung sowie von den erzielten Einsparungen kann sich der Zeitpunkt, ab dem ein finanzieller Vorteil entsteht, also der Break-even-Point entsprechend nach vorne oder hinten verschieben.

Eine HiL-Testumgebung ist daher keine „magische“ Lösung, die automatisch Zeit und Kosten einspart und für jedes Projekt zwingend erforderlich ist. Zunächst muss die HiL-Testumgebung selbst entwickelt und bereitgestellt werden und auch nach der Inbetriebnahme erfordert es kontinuierliche Anpassungen, Erweiterungen und Wartung. Dies gilt insbesondere dann, wenn sich das zu testende Produkt bzw. System (System under Test, kurz SuT) wesentlich verändert.

Grundsätzlich lässt sich festhalten: Für sehr kleine Entwicklungsprojekte lohnt sich der Einsatz einer HiL-Testumgebung in der Regel nicht. Bei größeren Projekten oder bei Entwicklungen mit längerer Laufzeit trägt eine HiL-Testumgebung hingegen direkt durch die Zeitersparnis der Tester zu Kosteneinsparungen bei und indirekt durch schnelleres und häufigeres Feedback an die Entwickler.

Architektur einer HiL-Testumgebung

Um die Synchronisation zwischen der Entwicklung einer HiL-Testumgebung und der Produktentwicklung zu verstehen, ist es notwendig, die grundlegende Architektur der HiL-Testumgebung näher zu betrachten. Dazu gehören insbesondere die Aufgaben des Testautomatisierungs-Frameworks (TAF), das einen zentralen Bestandteil jedes selbst entwickelten HiL-Systems bildet, sowie dessen Interaktion mit anderen wesentlichen Elementen des Entwicklungsprozesses. Das TAF bildet gemeinsam mit seinen Schnittstellen zu diesen Elementen sowie der Labor- und Netzwerkinfrastruktur das HiL-System. Das HiL-System in Kombination mit dem SuT und den zugehörigen Software- und Prozesskomponenten, wie Konfigurationsmanagement, Testmanagement und Testfall-Repositories wird im Folgenden als HiL-Testumgebung bezeichnet.

Das ISTQB definiert mit der general Test Automation Architecture (gTAA) ein generisches Referenzmodell für Testautomatisierungssysteme.⁴ Wie der Name bereits andeutet, handelt es sich dabei um eine allgemeine Standardarchitektur, die insbesondere zur strukturellen Einordnung und Veranschaulichung dient. Die folgende Abbildung zeigt eine auf der gTAA basierende, für selbst entwickelte HiL-Testumgebungen angepasste Architektur.

1. Testautomatisierungs-Framework (TAF)
   • Das TAF bildet das technische Herzstück des HiL-Systems. Es steuert die Ausführung und Auswertung der Testfälle, indem es die Kommunikation mit dem SuT und der Netzwerk- und Laborinfrastruktur orchestriert. Das TAF selber kann in zusätzliche Blöcke unterteilt werden:
     • Core Libraries und Logik: Enthalten die generischen, systemunabhängigen Funktionen des TAFs. Dazu gehören grundlegende Mechanismen zur Steuerung von Tests, zur Protokollierung, zur Fehlerbehandlung sowie allgemeine Hilfsfunktionen, die projektübergreifend wiederverwendet werden können. Darüber hinaus umfasst diese Schicht auch generische Algorithmen und Auswertelogik, mit denen Testdaten verarbeitet, analysiert und interpretiert werden, unabhängig davon, aus welchem konkreten SuT diese Daten stammen.
     • Ansteuerung und Beobachtung SuT-unabhängiger Infrastruktur: Umfasst die Anbindung und Steuerung von Laborgeräten sowie grundlegende Kommunikationsmechanismen, beispielsweise Netzteile, Messgeräte oder Relaiskarten. Diese Komponenten sind nicht spezifisch für ein einzelnes SuT und können über mehrere Projekte hinweg genutzt werden.
     • Ansteuerung und Beobachtung SuT-spezifischer Infrastruktur: Bezieht sich auf spezialisierte Hardware und Schnittstellen, die ausschließlich für ein bestimmtes SuT benötigt werden. Dazu zählen beispielsweise Programmiergeräte, zum Aufspielen der Firmware oder spezielle Auswertehardware sowie proprietäre Protokolle, die nur im Kontext dieses Systems verwendet werden.
     • Ansteuerung und Beobachtung des Systems under Test (SuT): Umfasst alle Protokolle und Schnittstellen, über die das TAF direkt mit dem SuT kommuniziert. Dazu gehören sowohl dedizierte Testschnittstellen als auch standardisierte Zugänge.
2. System under Test (SuT)
   • Das SuT ist das zu prüfende Embedded-System beziehungsweise Produkt und umfasst die reale Hardware, auf der die Software ausgeführt wird. In der Regel handelt es sich dabei um die Leiterplatten (PCBs), die auch im späteren Produktivsystem eingesetzt werden; in frühen Entwicklungsphasen können jedoch auch Evaluierungsboards oder Prototypen verwendet werden.
   • Das SuT wird über eine oder mehrere Schnittstellen vom TAF gesteuert und überwacht. Diese Schnittstellen sind von zentraler Bedeutung, da über sie Testfälle ausgeführt und die für die Testauswertung relevanten Daten erfasst werden.
3. Netzwerk- und Laborinfrastruktur
   • Über die Laborinfrastruktur wird das SuT unter anderem mit Spannung versorgt, wodurch gezieltes An- und Ausschalten und Reboots möglich sind, ein Vorgang, der insbesondere nach Flash- oder Update-Prozessen häufig erforderlich ist. Weitere Komponenten der Infrastruktur dienen dazu, das SuT zu beobachten und es gezielt in definierte Zustände zu versetzen.
   • Zu den Messgeräten zählen unter anderem Oszilloskope, Digitalmultimeter und Logikanalysatoren sowie Geräte zur gezielten Ansteuerung des Systems, etwa Wellenformgeneratoren oder Relais.
   • Darüber hinaus sind auch Netzwerkverbindungen und weitere Dienste wie beispielsweise MQTT-Broker häufig integrale Bestandteile des HiL-Systems.
4. Testfälle
   • Die Testfälle definieren, welche Features und Eigenschaften des SuT überprüft werden sollen. Sie werden vom TAF ausgeführt und die resultierenden Systemreaktionen ausgewertet. Erfahrungsgemäß sollten Testfälle vom TAF getrennt gehalten werden, da dies die Wiederverwendbarkeit des TAF über mehrere HiL-Testumgebungen hinweg deutlich erhöht.
5. Testmanagement
   • Das Testmanagementsystem dient der Verwaltung, Nachverfolgung und Auswertung der Testergebnisse. Über entsprechende Schnittstellen häufig in Form von Python- oder Bash-Skripten oder als Bestandteil von CI/CD-Pipelines werden die Testergebnisse an externe Systeme übertragen, in denen sie gespeichert und analysiert werden.
6. Konfigurationsmanagement
   • Das Konfigurationsmanagement bestimmt, in welcher HiL-Testumgebung ein Test ausgeführt wird. Es legt beispielsweise fest, welche Hardware verwendet wird, welche Firmware-Version auf das SuT aufgespielt wird, welche Schnittstellen aktiv sind und welche Parameter gelten. In kleinen HiL-Testumgebungen, die beispielsweise nur ein einzelnes SuT umfassen, ist ein formales Konfigurationsmanagement oft kaum erforderlich; mit zunehmender Projektgröße und Komplexität gewinnt es jedoch stark an Bedeutung und wird für eine stabile und skalierbare HiL-Testinfrastruktur unerlässlich.
   • Auf dieser Grundlage lädt das TAF die jeweils passende Testumgebung und stellt sicher, dass Tests reproduzierbar und konsistent ausgeführt werden.

Zwischenfazit

An Abbildung 4 wird deutlich, dass Teile der HiL-Testumgebung, insbesondere die Schnittstellen zum Konfigurations- und Testmanagement, weitgehend unabhängig vom SuT sind. Diese Komponenten können daher bereits in einem frühen Projektstadium konzipiert und implementiert werden, noch bevor die eigentliche Produktentwicklung begonnen hat.

Auch innerhalb des TAF existieren Bestandteile, die kaum oder gar nicht vom zu testenden System abhängen. Diese eignen sich besonders gut, um frühzeitig entworfen und umgesetzt zu werden.

Diese modulare Aufteilung der HiL-Testumgebung ermöglicht zudem eine spätere Wiederverwendung zentraler Komponenten, wie in Abbildung 5 zu sehen ist, ohne große Teile des Systems neu entwickeln zu müssen und ohne unnötige Komplexität aufzubauen und im Chaos zu versinken.

SuT-spezifische Adapter und Testfälle bilden hingegen die variable Projektschicht, die pro Produkt neu erstellt wird.

Vorgehen in der Praxis – Synchronisation zwischen TAS und SuT

Nachdem die grundsätzliche Entscheidung für oder gegen eine HiL-Testumgebung, als konkrete Ausprägung eines TAS, getroffen wurde, stellt sich die nächste zentrale Frage: Wann und wie sollte mit dessen Entwicklung begonnen werden? Diese Entscheidung ist von großer Bedeutung und erfordert eine sorgfältige Abwägung.

Grundsätzlich gilt: Die Entwicklung eines TAS sollte nicht ad hoc und ohne konzeptionelle Planung erfolgen. Auch ein TAS ist ein eigenständiges Embedded-Projekt, wenn auch in enger Abhängigkeit vom jeweiligen SuT.

Testbarkeit als Teil der Produktanforderungen

Bereits während der Definition der Anforderungen für das SuT sollten Tester eingebunden werden. Sie können beurteilen, ob Anforderungen überhaupt testbar sind, und aktiv zur Produktarchitektur beitragen, indem sie Maßnahmen zur Verbesserung von Observability und Controllability anstoßen, beispielsweise durch zusätzliche Schnittstellen, die eine spätere Testautomatisierung erleichtern. Observability bezeichnet dabei die Fähigkeit, interne Systemzustände über geeignete Schnittstellen und Messpunkte sichtbar zu machen, während Controllability die Möglichkeit beschreibt, das System gezielt in definierte Zustände zu versetzen und von außen zu steuern. Eine frühzeitige Berücksichtigung dieser Aspekte führt zu erheblichen Zeitersparnissen im Testprozess und reduziert erfahrungsgemäß die Anzahl sogenannter Flaky Tests, also Testfälle, die bei scheinbar identischen Bedingungen wechselnde Ergebnisse liefern deutlich.

Start der TAS-Entwicklung

Aus fachlicher Sicht sollte mit der Entwicklung des TAS begonnen werden, sobald die erste Produktarchitektur definiert ist. In agilen Softwareprojekten wird diese Architektur zwar nicht selten erweitert oder angepasst. Während Erweiterungen in der Regel unkritisch für das TAS sind, können tiefgreifende Architekturänderungen problematisch werden: Werden Komponenten entfernt oder grundlegend überarbeitet, muss dies auch im TAS nachgezogen werden. Das Risiko kann aber wie im nächsten Abschnitt näher bschrieben durch geeignete Maßnahmen deutlich reduziert werden.

Der erste Schritt besteht daher darin, die Architektur des Produkts zu verstehen und darauf aufbauend Anforderungen an das TAS zu definieren sowie dessen Architektur zu entwerfen. Hier ist es, aber auch sehr wichtig, dass eine enge Zusammenarbeit zwischen Entwicklern und Testautomatisierern gegeben ist. Denn TAS und SuT müssen perfekt ineinander greifen. Das TAS wird auf das SuT zugeschnitten, während das SuT aktiv für die Testbarkeit optimiert wird. Ohne gegenseitige Abstimmung und Kompromisse hinsichtlich der Testbarkeit des SuTs, bspw. durch dedizierte „Test-Schnittstellen“ sinkt der Projekterfolg.

Die folgende Abbildung veranschaulicht die Synchronisation zwischen manuellen Tests, dem TAS und der SuT-Entwicklung im agilen Kontext.

Hinweis: Der dargestellte manuelle Iterationszyklus stellt die Sicht aus der Perspektive des Testers⁵ auf den operativen Testfall-Lebenszyklus dar. Testprozessübergreifende Aktivitäten aus Sicht des Testmanagements, wie Testplanung, Testüberwachung und Testabschluss sind darin bewusst nicht enthalten, da sie auf einer strategischen Ebene angesiedelt sind und projektübergreifend wirken.

Neben dem SuT muss auch das TAS selbst getestet werden. Hierfür sind in der Regel keine komplexen Integrations- oder Systemtests erforderlich, jedoch sollten zumindest Unit-Tests für die verwendeten Libraries, Hilfsfunktionen und Algorithmen des TAS existieren, um die Stabilität und Wartbarkeit zu verbessern.

Risikominimierung – Reihenfolge der Entwicklung im TAS

Um unnötige Mehrarbeit zu vermeiden, sollten in den frühen Iterationsphasen zunächst die SuT-unabhängigen Bestandteile des TAS entwickelt werden, bevor systemspezifische Komponenten umgesetzt werden. Automatisierte Testfälle sollten erst dann implementiert werden, wenn entsprechende manuelle Tests bereits definiert und ausgeführt wurden. Diese manuellen Tests dienen gleichzeitig auch als Grundlage, um zusätzliche Anforderungen an das TAS abzuleiten da sich an ihnen sehen lässt, welche Fähigkeiten das TAS zur Ausführung bereitstellen muss, sind aber für den ersten Iterationszyklus des TAS weniger wichtig.

Gerade in frühen Iterationszyklen ändern sich Architekturen und Anforderungen des SuT häufig, sodass dieses Vorgehen hilft, das Risiko von Nacharbeit deutlich zu reduzieren.

Was (erstmal) nicht automatisiert werden sollte

Dabei ist jedoch Vorsicht geboten: Besonders komplexe Testszenarien sollten erst in späteren Phasen automatisiert und am besten in separaten Test-Suiten ausgeführt werden, da sie aufgrund ihrer vielen Abhängigkeiten besonders fehleranfällig sind und in frühen Zyklen einen hohen Wartungsaufwand verursachen.

In den frühen Iterationen wird in der Praxis überwiegend manuell getestet, während in späteren Zyklen, sobald das TAS ausreichend stabil ist, zunehmend mehr Testfälle automatisiert werden. Wie bereits erwähnt, ist es weder möglich noch sinnvoll, sämtliche manuellen Tests zu automatisieren. Ziel der Testautomatisierung ist daher nicht, manuelles Testen vollständig zu ersetzen, sondern vor allem repetitive und gut spezifizierte Testfälle zu automatisieren und die Tester für strategische Testentscheidungen, exploratives Testen sowie für nicht oder nur mit unverhältnismäßigem Aufwand automatisierbare Tests einzusetzen.

Fazit

Agile Embedded-Entwicklung entfaltet ihren vollen Nutzen nur dann, wenn Entwicklung und Test als eng miteinander verzahnte Prozesse zusammenarbeiten. Insbesondere im Embedded-Umfeld, in dem Software, Hardware und Testsysteme parallel entstehen, ist eine saubere Synchronisation zwischen SuT und TAS entscheidend für Qualität, Geschwindigkeit und Wirtschaftlichkeit.

HiL-Testumgebungen stellen eine besonders verbreitete Form eines TAS im Embedded-Bereich dar, da sie hardwarenahe Tests unter realistischen Bedingungen ermöglichen.

Sie lohnen sich vor allem für Produkte mit vielen Iterationen, hoher Testfrequenz oder langen Laufzeiten. Entscheidend ist nicht, ob automatisiert getestet wird, sondern was, wann und in welchem Umfang automatisiert wird.

Eine modulare Architektur des TAS, die Trennung von stabilen Kernkomponenten und SuT-spezifischen Teilen sowie die frühzeitige Berücksichtigung von Testbarkeit im Produktdesign bilden die Grundlage für eine nachhaltige und skalierbare HiL-Testumgebung.

Quellen

1. Global Six Sigma USA, LP, „The Guide to Agile SDLC: A Modern Approach to Software Development“, veröffentlicht am 07.01.2025, aufgerufen am 06.01.2026, https://www.6sigma.us/six-sigma-in-focus/agile-sdlc-software-development-life-cycle/ ↩︎
2. vgl. GeeksforGeeks, „Agile SDLC (Software Development Life Cycle)“, veröffentlicht am 23.07.2025, aufgerufen am 06.01.2026, https://www.geeksforgeeks.org/software-engineering/agile-sdlc-software-development-life-cycle/ ↩︎
3. vgl. ISTQB® Certified Tester Test Automation Strategy Syllabus Version 1.0, S.38 unten ↩︎
4. vgl. ISTQB® Certified Tester Advanced Level Test Automation Engineering Syllabus Version 2.0, S.23 ↩︎
5. vgl. ISTQB® Certified Tester – Lehrplan Foundation Level 4.0.1a, S. 24 (unten) ↩︎