Basiswissen Abnahmetest E-Book

Florian Fieber

• Herausgeber: dpunkt.verlag
• Kategorie: Wissenschaft und neue Technologien
• Serie: Basiswissen
• Sprache: Deutsch
• Veröffentlichungsjahr: 2021

Seitenzahl: 265

Beschreibung

Grundlagen des Abnahmetests für Product Owner, Business-Analysten und Tester

• Fokus auf kollaborative Zusammenarbeit
• mit einem durchgängigen Fallbeispiel
• mit Exkursen auf Basis industrieller Projekterfahrungen

Mit Abnahmetests – Acceptance Testing – wird überprüft, ob eine Software aus Sicht des Benutzers wie beabsichtigt funktioniert und dieser die Software akzeptiert.
Das Buch verbindet die Business-Analyse und Softwaretesten mit Blick auf die Konzepte, Methoden und Praktiken der Zusammenarbeit zwischen Business-Analysten und Testern beim Abnahmetest.
Business-Analysten und Projektleiter lernen, wie sie durch die Unterstützung bei der Ausrichtung des Produkts an den Geschäftsanforderungen zu den Abnahmetestaktivitäten in einer Organisation beitragen.
Tester erfahren, wie sie effizient mit Business-Analysten und anderen Stakeholdern während allen Abnahmetestaktivitäten zusammenarbeiten.
Dieses Buch umfasst das erforderliche Wissen als Vorbereitung auf die Prüfung zum "Certified Tester (Foundation Level) – Acceptance Testing" nach ISTQB®-Standard. Ein durchgängiges Fallbeispiel verbindet das theoretische Wissen des Lehrplans mit dessen praktischer Anwendung beim Abnahmetest. Das Buch eignet sich damit nicht nur bestens für die Prüfungsvorbereitung, sondern dient gleichzeitig als kompaktes Basiswerk zu diesen Themen in der Praxis und an Hochschulen.

Leseprobe

Über die Autoren

Diplom.-Inform. M.Sc. Florian Fieber ist Gründer und Geschäftsführer der QualityDojo IT-Consulting GmbH in Berlin und als Berater und Trainer im Bereich der Qualitätssicherung von Softwaresystemen tätig. Seine Schwerpunkte liegen dabei im Testmanagement, der Testprozessverbesserung sowie der Businessanalyse von Enterprise-Anwendungen.

Er ist seit 15 Jahren als Trainer für »ISTQB® Certified Tester«-Seminare aktiv und hat in dieser Zeit zahlreiche Seminarinhalte entwickelt und weit über 100 Seminare geleitet. Er ist stellvertretender Vorsitzender des German Testing Board e. V. und engagiert sich dort u. a. als Leiter der Arbeitsgruppe »Acceptance Testing« für die Weiterentwicklung des entsprechenden ISTQB®-Lehrplans.

Diplom.-Inform. M.Sc. Marc-Florian Wendland arbeitet seit über zwölf Jahren als wissenschaftlicher Mitarbeiter im Fraunhofer-Institut FOKUS und befasst sich mit der Optimierung von Qualitätssicherungsverfahren in komplexen, softwareintensiven Systemen. Er war für die Ausarbeitung von Strategien, Lösungen und Prototypen in zahlreichen nationalen und internationalen Forschungsund Industrieprojekten in den verschiedensten Branchen verantwortlich, insbesondere für die Automatisierung des Testentwurfs und der Testdurchführung.

Er ist seit 2019 Mitglied im German Testing Board e. V. und engagiert sich in den Arbeitsgruppen »Acceptance Testing« und »Testautomatisierungsentwickler«, deren stellvertretende Leitung er auch innehat.

Neben seiner industrienahen Forschungstätigkeit im Fraunhofer-Institut FOKUS und seiner Mitarbeit in verschiedenen Standardisierungsaktivitäten ist er seit 2015 zudem als freier Trainer für die verschiedenen »ISTQB® Certified Tester«-Schulungen tätig.

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.plus

Florian Fieber · Marc-Florian Wendland

BasiswissenAbnahmetest

Aus- und Weiterbildung zumISTQB® Foundation Level Specialist– Acceptance Testing

Florian Fieber

[email protected]

Marc-Florian Wendland

[email protected]

Lektorat: Christa Preisendanz

Lektoratsassistenz: Anja Weimer

Copy-Editing: Ursula Zimpfer, Herrenberg

Satz: Birgit Bäuerlein

Herstellung: Stefanie Weidner, Frank Heidt

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

Fachliche Beratung und Herausgabe von dpunkt.büchern zum Thema »ISTQB® Certified Tester«: Prof. Dr. Andreas Spillner · [email protected]

ISBN:

Print

978-3-86490-829-3

PDF

978-3-96910-286-2

ePub

978-3-96910-287-9

mobi

978-3-96910-288-6

1. Auflage 2021

Copyright © 2021 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Hinweis:

Die Tatsache, dass wir im gesamten Text vorwiegend das männliche Pronomen (er/sein) verwenden, dient der leichteren Lesbarkeit und spiegelt in keiner Weise eine geschlechtsspezifische Einstellung wider.

Hinweis:

Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag noch Herausgeber können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Vorwort

Die Idee zu diesem Buch kam uns beiden während der im Buddy-Review durchgeführten Lokalisierungsarbeiten am »Acceptance Tester«-Lehrplan im Rahmen unserer Arbeitsgruppentätigkeit beim German Testing Board e.V. (GTB). Während der doch recht zeitraubenden Reviewsitzungen stellten wir uns irgendwann die Frage, wie eigentlich die Situation unterstützender Literatur auf dem deutschen Buchmarkt dediziert zum Thema Abnahmetest aussähe. Das Ergebnis war ernüchternd bzw. aus Neu-Autorensicht recht erfreulich – nicht sehr umfangreich oder anders gesagt: Wir fanden keine einzige Veröffentlichung speziell über den Abnahmetest! Und da wir schon seit Längerem mit einem gemeinsamen Buchprojekt geliebäugelt hatten, führte eines zum anderen und schlussendlich zu dem vorliegenden Buch.

Softwarequalität ist unsere berufliche Leidenschaft, die es gelegentlich sogar ins Private schafft. Seit rund 15 Jahren (der eine mehr, der andere weniger, im Durchschnitt passt es dann wieder) setzen wir uns intensiv in wechselnden Rollen und unterschiedlichen Geschäftsbereichen mit dem Thema Qualitätssicherung auseinander. Dabei stehen für uns insbesondere das Testen sowie die Testaktivitäten in all ihren schrecklich schönen und zahlreichen Facetten im Vordergrund. Besonders heikel, da spannend, wird es immer dann, wenn wir uns an den Schnittstellen zu anderen Disziplinen und Rollen bewegen. Requirements Engineering beispielsweise oder auch die Modellierung von Softwaresystemen, gerne auch in Kombination mit dem modellbasierten Testen, sind Themen, die uns immer wieder einholen und auf Trab halten. Spannenderweise verbindet der Abnahmetest und vor allem der ISTQB®-Lehrplan zu »Acceptance Testing« diese verschiedenen Tätigkeiten und Rollen, was für uns die perfekte Voraussetzung bzw. Motivation darstellte, um das Begleitbuch dazu zu verfassen. Die jahrelange Erfahrung in Industrie- und Forschungsprojekten, die wir sammeln konnten, füllen zudem einige Lücken des Lehrplans bzw. erweitern diesen an der ein oder anderen Stelle zielführend und – zumindest aus unserer Sicht – für den Leser absolut gewinnbringend. Das vorliegende Buch ist daher mehr als nur eine elaboriertere Version des Lehrplans, sondern liefert einen echten Mehrwert.

Unsere Projekterfahrungen lassen wir natürlich auch als Trainer in die verschiedenen Seminare einfließen. Den Schwerpunkt bilden dabei insbesondere die Seminare zu den verschiedenen Lehrplänen des »ISTQB® Certified Tester «-Schemas.

Ein solches Buch schreibt man nicht alleine – nun gut, die Aussage in sich ist schon eine Tautologie, sind wir doch zwei Autoren, aber wir meinten die Aussage eher im Sinne von »es haben weitere Personen maßgeblich an der Veröffentlichung dieses Buches Anteil«. Diesen helfenden Köpfen möchten wir gerne namentlich unseren Dank ausdrücken.

Zum einen ist da Frau Preisendanz vom dpunkt.verlag, die in der von Homeschooling und Corona-Kinderbetreuung geprägten Zeit schon das ein oder andere Mal Geduld mit uns hatte. Vielen Dank dafür.

Zudem möchten wir uns recht herzlich bei Andreas Spillner, Herausgeber von dpunkt.büchern zum Thema »ISTQB® Certified Tester«, für das fachliche Review und die konstruktiven Anmerkungen bedanken – und nebenher spendierte er uns auch das Geleitwort zu diesem Buch.

Weiterhin möchten wir uns bei unseren externen Reviewern für ihre wertvollen Anmerkungen bedanken. Zum einen bei Jogi Sievers und seinem Team »Test-Management-Plattform« bei der SIGNAL IDUNA für ihr Review aus den Perspektiven »Businessanalystin«, »Product Owner« und »Test-Service-Spezialist«, zum anderen bei Maik Nogens für seine prägnanten Verbesserungsvorschläge.

Wir möchten uns bei allen Kolleginnen und Kollegen im German Testing Board e.V. für die Unterstützung und den professionellen Austausch bedanken.

Nicht zuletzt bedanken wir uns bei unseren Familien, die auf uns doch die ein oder andere Stunde während dieses Buchprojekts verzichten mussten und dies nicht nur akzeptiert, sondern sehr unterstützt haben. Euch auch vielen Dank.

Und ab und an tut es auch nicht weh, sich selbst – oder gegenseitig – auf die Schulter zu klopfen und zu sagen: »Danke, lieber Ko-Autor, dass du meine zahlreichen Kommentare, Anmerkungen und Kritiken professionell aufgenommen hast. Und ich muss zugeben, dass deine Anmerkungen dazu beigetragen haben, dass unsere Namen nun auf einem Buch stehen, auf das ich schon ein bisschen stolz bin.«

Nun aber Schluss der vielen einführenden und dankenden Worte. Wir wünschen Ihnen, liebe Leserinnen und Leser, viel Spaß und einen maximalen Erkenntnisgewinn mit diesem Buch. Wir sind gespannt auf Ihr Feedback.

Florian Fieber und Marc-Florian Wendland

Berlin, Mai 2021

Geleitwort

Mit dem Buch zum Abnahmetest haben die beiden Autoren ein sehr wichtiges Thema aufgegriffen: Der Abnahmetest ist das letzte Glied der Kette von Maßnahmen zur Qualitätsbestimmung und Qualitätssicherung eines Softwaresystems, bevor es zum Einsatz kommt. Der Abnahmetest ist somit der Schritt, der darüber entscheidet, ob das Softwaresystem als angemessen realisiert anzusehen ist und zur betrieblichen Anwendung kommt.

Allzu oft wird der Abnahme eines neuen oder erweiterten Softwaresystems zu wenig Bedeutung vonseiten des Kunden bzw. Auftraggebers beigemessen. Die Abnahme wird als notwendiges Übel gesehen, das nur Zeit und damit Geld kostet. Dem ist aber nicht so.

Ein Beispiel soll die Bedeutung der Abnahme illustrieren: Angenommen, Sie haben den Bau eines Hauses in Auftrag gegeben und das Haus ist nun bezugsfertig und es muss »nur« noch abgenommen werden. Als Bauherr werden Sie die Abnahme als letzten bedeutenden Schritt sehen. Sie werden möglicherweise Fachleute beauftragen, um Sie bei der Abnahme zu beraten und zu unterstützen. Sie werden die Umsetzung Ihrer Vorstellungen – Ihrer Anforderungen – bei den unterschiedlichen Gewerken einzeln prüfen und auch deren Zusammenspiel. Sie werden Pläne (Modelle, Grundriss, Aufriss, …) zum Vergleich dabeihaben und Sie werden eine Liste oder Tabelle vorbereitet haben, damit Sie keinen wichtigen Punkt vergessen, und Sie werden die Liste Punkt für Punkt »abarbeiten«. Sie werden das gesamte Haus vom Keller bis zum Dachboden begehen und dabei alle Aspekte berücksichtigen, die »Ihr« Haus ausmachen. Sie werden sich dabei Zeit nehmen und alle Auffälligkeiten dokumentieren, um diese dann mit dem Bauträger zu diskutieren und möglichst einvernehmlich auf die Beseitigung von bestehenden Mängeln dringen.

Wenn es um die Abnahme eines Softwaresystems geht, das vom Aufwand und von den Kosten mit einem Hausbau durchaus vergleichbar ist, ergibt sich oft ein anderes Bild: Der Bauherr geht einmal um sein Haus herum, prüft, ob der Schlüssel in die Haustür passt, geht durch das Erdgeschoss und öffnet ein Fenster zum Garten – das war’s.

Damit der Abnahmetest von Software angemessen und aussagekräftig durchgeführt wird, ist das Buch eine hervorragende Grundlage – auch um der Bedeutung des Abnahmetests gerecht zu werden. Folgende Buchinhalte, die neben vielen anderen im Buch ausführlich behandelt werden, sollen kurz hervorgehoben werden:

Anforderungen & Abnahmekriterien

Ohne dass die Anforderungen an das Softwaresystem möglichst umfassend und präzise geklärt sind, kann kein Abnahmetest und somit keine Abnahme erfolgen. Kriterien, die festlegen, was das Softwaresystem leisten soll, sind vorab zu definieren und von allen Beteiligten zu akzeptieren. Je früher klar ist, welche Abnahmekriterien welchen Stellenwert haben, je besser kann das Softwaresystem auf die Bedürfnisse der späteren Anwender zugeschnitten werden. Die Gefahr, dass »am Kunden vorbei entwickelt wird«, verringert sich dadurch erheblich.

Modelle & Tabellen

Viele Softwaresysteme unterstützen Geschäftsprozesse. Wie die jeweiligen Prozesse ablaufen und wie dabei das Softwaresystem Aufgaben übernehmen kann, wird am besten in Form von Grafiken und Tabellen veranschaulicht. Die bildhafte Darstellung der Abläufe in den Modellen hilft dabei, Unklarheiten und Ungenauigkeiten zu klären. Eine Diskussion über den jeweiligen Sachverhalt wird bei der grafischen Darstellung in Modellen eher angeregt als bei reinen Textbeschreibungen. Tabellen schaffen Übersicht und verhindern ein Übersehen von einzelnen Aspekten bzw. Kombinationen.

Kommunikation & Kollaboration

Auch bei der Abnahme von Softwaresystemen bringt ein »Miteinander« viel mehr als ein «Gegeneinander«. Auf die kooperative Zusammenarbeit und ein gegenseitiges Verständnis kommt es an. Grundlage hierfür ist eine gemeinsame Sprache und das gleiche Verständnis der Fachbegriffe. Das Buch und der Lehrplan zum »ISTQB® Foundation Level Specialist – Acceptance Testing« bieten hierfür die perfekten Grundlagen.

Ein Punkt soll nicht unerwähnt bleiben: das sehr ausführliche und durchgängige Fallbeispiel »CA-Cockpit«. Alle Schritte und Aspekte des Abnahmetests werden mit dem Fallbeispiel verdeutlicht. Die theoretischen Grundlagen werden durch das praktische Beispiel realisiert und führen zu einem besseren Verständnis des Sachverhalts.

Leserinnen und Leser werden bei der Lektüre des Buches viele Anregungen und praktische Hinweise für den Abnahmetest erhalten. Wird die Zertifizierung zum »ISTQB® Foundation Level Specialist – Acceptance Testing« angestrebt, wofür im Buch das notwendige Wissen anschaulich aufbereitet zur Verfügung steht, wünsche ich eine erfolgreiche Prüfung.

Andreas Spillner

Bremen, im Frühjahr 2021

Inhaltsübersicht

1Einleitung

2Grundlagen des Abnahmetests

3Abnahmekriterien, Abnahmetests und erfahrungsbasierte Praktiken

4Nicht funktionale Anforderungen im Abnahmetest

5Modellierung von Geschäftsregeln und Geschäftsprozessen

6Kollaborativer Abnahmetest

Anhang

AWichtige Hinweise zum Lehrstoff und zur Prüfung zum Certified Tester

BAbkürzungsverzeichnis

CGlossar

DQuellenverzeichnis

Index

Inhaltsverzeichnis

1Einleitung

1.1Vertrauen, Qualität, Sicherheit!

1.2ISTQB® Certified Tester – das Zertifizierungsprogramm für Softwaretester

1.3Nutzen dieses Buches

1.4Kapitelübersicht

1.5Fallbeispiel »CA-Cockpit«

2Grundlagen des Abnahmetests

2.1Der Abnahmetest im Softwarelebenszyklus

2.1.1Testen im Softwarelebenszyklus

2.1.2Zweck und Ziele des Abnahmetests

2.1.3Abnahmetests in sequenziellen vs. agilen Softwareentwicklungsmodellen

2.2Grundlegende Beziehungen

2.2.1Geschäftsziele, Geschäftsbedarfe und Anforderungen

2.2.2Anforderungen/User Stories, Abnahmekriterien und Abnahmetests

2.2.3Die Wichtigkeit der Qualität der Anforderungen

2.3Businessanalyse und Abnahmetests

2.3.1Beziehungen zwischen Businessanalyse- und Testaktivitäten

2.3.2Zusammenarbeit zwischen Businessanalysten und Testern beim Abnahmetest

2.3.3Wie der Abnahmetest den Entwicklungsprozess vorantreiben kann: ATDD und BDD

3Abnahmekriterien, Abnahmetests und erfahrungsbasierte Praktiken

3.1Abnahmekriterien erstellen

3.2Abnahmetests entwerfen

3.2.1Testvorgehensweisen und Testverfahren für den Abnahmetest

3.2.2Testfälle mit der Gherkin-Sprache erstellen

3.3Erfahrungsbasierte Ansätze für den Abnahmetest

3.3.1Exploratives Testen

3.3.2Beta-Tests

4Nicht funktionale Anforderungen im Abnahmetest

4.1Nicht funktionale Qualitätsmerkmale und Nutzungsqualität

4.1.1Das ISO-25010-Qualitätsmodell

4.1.2Das ISO-25010-Modell der Nutzungsqualität

4.1.3Nicht funktionale Qualitätsmerkmale im Abnahmetest

4.2Gebrauchstauglichkeit und Benutzererlebnis

4.2.1Gebrauchstauglichkeit

4.2.2Benutzererlebnis (UX)

4.2.3Gebrauchstauglichkeitstest

4.3Performanz

4.3.1Anforderungen und Abnahmekriterien für Performanzabnahmetests

4.3.2High-Level-Performanzabnahmetests

4.4IT-Sicherheit

4.4.1Anforderungen und Abnahmekriterien für IT-Sicherheitsabnahmetests

4.4.2High-Level-IT-Sicherheitsabnahmetests

5Modellierung von Geschäftsregeln und Geschäftsprozessen

5.1Grundlagen der Modellierung

5.2Geschäftsprozess- und Geschäftsregelmodellierung mit BPMN und DMN

5.2.1Einführung in BPMN

5.2.1.1Kernbereiche der BPMN

5.2.1.2Prozesse

5.2.2Einführung in DMN

5.2.2.1Verwendungsarten von DMN

5.2.2.2Kernbereiche von DMN

5.2.2.3Klassische Entscheidungstabellen

5.2.2.4DMN-Entscheidungstabellen

5.2.2.5DMN-Entscheidungstabellen mit BPMN verknüpfen

5.3Geschäftsprozess-/Geschäftsregelmodelle im Abnahmetest verwenden

5.3.1Modellbasiertes Testen

5.3.2Bewährte Testmodellierungspraktiken

5.4Abnahmetests aus Geschäftsprozess-/Geschäftsregelmodellen ableiten

5.4.1Ableitung von Abnahmetests aus Geschäftsprozess- und Geschäftsregelmodellen

5.4.1.1Strukturelle Überdeckungskriterien

5.4.1.2Weitere Überdeckungskriterien

5.4.1.3Testentwurf und -realisierung mit BPMN

5.4.2Ableitung von Abnahmetests aus Entscheidungstabellen

5.4.2.1Vollständige Entscheidungstabellen

5.4.2.2Reduzierung vollständiger Entscheidungstabellen mit dem Prüfsummenverfahren

5.4.2.3Testentwurf und -realisierung mittels Entscheidungstabellen

6Kollaborativer Abnahmetest

6.1Zusammenarbeit

6.2Aktivitäten

6.2.1Fehleranalyse

6.2.2Berichterstattung

6.2.3Qualitätssicherungsaktivitäten für den Abnahmetest

6.3Werkzeugunterstützung

6.3.1Werkzeugarten im Abnahmetest

6.3.2Auswahl und Einführung

Anhang

AWichtige Hinweise zum Lehrstoff und zur Prüfung zum Certified Tester

A.1Lernziele des Lehrplans

A.1.1Lernziele zu Kapitel 2:

Grundlagen des Abnahmetests

A.1.2Lernziele zu Kapitel 3:

Abnahmekriterien, Abnahmetests und erfahrungsbasierte Praktiken

A.1.3Lernziele zu Kapitel 4:

Nicht funktionale Anforderungen im Abnahmetest

A.1.4Lernziele zu Kapitel 5:

Modellierung von Geschäftsregeln und Geschäftsprozessen

A.1.5Lernziele zu Kapitel 6:

Kollaborativer Abnahmetest

BAbkürzungsverzeichnis

CGlossar

DQuellenverzeichnis

D.1Bücher und Artikel

D.2Lehrpläne

D.3Normen und Standards

D.4Web

Index

1Einleitung

1.1Vertrauen, Qualität, Sicherheit!

Der Abnahmetest nimmt im Softwareentwicklungsprozess eine besondere Stellung ein, das Bild auf dem Cover illustriert einige der grundlegenden Aspekte des Abnahmetests – Vertrauen (Händedruck), Qualität (Häkchen) und Sicherheit (Schild-Symbol). Der Abnahmetest ist eine vertrauensbildende Maßnahme! Er soll beim Auftraggeber ausreichendes Vertrauen in die Qualität des Produkts erzeugen, sodass dieser das Produkt schließlich vom Auftragnehmer abnimmt. Vertrauen gibt es aber meist nicht frei Haus, Vertrauen muss erarbeitet werden und sprichwörtlich besser kontrolliert werden. Durch einen (möglicherweise formalen) Nachweis der Qualität des Produkts entsteht die notwendige Sicherheit, das Produkt für seinen Einsatzzweck betreiben zu können und einen Mehrwert oder Nutzwert daraus zu ziehen. Vertrauen entsteht also durch den Nachweis von Qualität. Je höher die Qualität des Produkts ist, desto höher ist die Wahrscheinlichkeit, dass die Erwartungen des Auftraggebers erfüllt werden.

Abnahmetest bei der Entwicklung von Geschäftslösungen

Die Entwicklung von Geschäftslösungen erfordert komplementäres Wissen und Expertise aus unterschiedlichen Disziplinen sowie sich ergänzende Rollen, die eine Vielzahl verschiedener Aktivitäten ausführen. Informationssilos müssen vermieden werden, denn je besser diese Disziplinen miteinander integriert sind und die Rollen zusammenarbeiten, desto höher ist die Wahrscheinlichkeit, dass qualitativ höherwertige Produkte entstehen. Zusammenarbeit wird nicht nur in modernen, agilen Softwareentwicklungsmodellen forciert, auch in den traditionellen (d. h. sequenziellen) Softwareentwicklungsmodellen unterstützen sinnvolle Kollaborationen den Projekterfolg.

Insbesondere der Abnahmetest ist ein gutes Beispiel dafür, wie die jeweiligen Rollen aus den unterschiedlichen Disziplinen durch Zusammenarbeit einen Mehrwert für das Produkt und die Organisation schaffen können. Der Abnahmetest verbindet dabei vor allem die Rollen des Businessanalysten (oder des Product Owners) und des Testers. Eine wichtige Aktivität dieser Rollen unabhängig vom gelebten Softwareentwicklungsmodell ist u. a. die Spezifikation von Abnahmekriterien als Unterstützung der Validierung einer Geschäftslösung. Abnahmekriterien sind üblicherweise Bestandteile von Anforderungen, entweder explizit oder implizit. Durch Extraktion der Abnahmekriterien aus den Anforderungen werden letztere in eine feiner granulierte, somit weniger komplexe und besser testbare Form gebracht. Darauf aufbauend werden Testfälle entworfen, die diese Abnahmekriterien umsetzen. Anhand der Testfälle wird die Geschäftslösung verifiziert bzw. validiert. Die Ableitung von Abnahmetests aus Abnahmekriterien ist eine in hohem Maße kollaborative Aktivität, an der Businessanalysten und Tester beteiligt sein sollten.

Kollaboration von Businessanalyst und Tester

Zur Unterstützung der Aus- und Weiterbildung in diesem Bereich hat das ISTQB® den Lehrplan »ISTQB® Foundation Level Specialist – Acceptance Testing« [ISTQB CTFL-AcT] entwickelt. Das Hauptziel des Lehrplans ist es, die Zusammenarbeit von Businessanalysten und Testern zu unterstützen und damit Informationssilos zwischen den Rollen zu vermeiden. Der Lehrplan richtet sich dabei an alle Personen, die in die Aktivitäten des Abnahmetests involviert sind. Dies beinhaltet nicht nur Businessanalysten, Product Owner und Tester, sondern auch weitere Rollen wie Testanalysten, Testingenieure, Testberater, Testmanager, Benutzerabnahmetester und Softwareentwickler.

1.2ISTQB® Certified Tester – das Zertifizierungsprogramm für Softwaretester

Der weltweite Standard für die Aus- und Weiterbildung im Bereich Softwarequalitätssicherung und Softwaretest ist heute das »ISTQB® Certified Tester «-Schema des International Software Testing Qualifications Board (ISTQB) [URL: ISTQB].

Das »ISTQB® Certified Tester «-Ausbildungsschema gliedert sich zum Zeitpunkt der Drucklegung dieses Buches in die drei Säulen »Agile«, »Core« und »Specialist« sowie die drei Ausbildungsstufen »Foundation«, »Advanced« und »Expert« (siehe Abb. 1–1).

Abb. 1–1Übersicht des »ISTQB®/GTB Certified Tester«-Ausbildungsschemas [URL: GTB]

Der Inhalt dieses Buches deckt die prüfungsrelevanten sowie darüber hinausgehende Inhalte des Zertifikats »Acceptance Testing« ab, das auf der Stufe »Foundation« in der Säule »Specialist« angesiedelt ist. Das prüfungsrelevante Fachwissen kann im Selbststudium (z. B. mithilfe dieses Buches) und/oder durch Teilnahme an einem Seminar erworben werden.

In Bezug auf die verschiedenen im »ISTQB® Certified Tester Foundation Level «-Lehrplan [ISTQB CTFL] definierten Ausprägungen von Abnahmetests werden im »Acceptance Testing«-Lehrplan Benutzerabnahmetests (User Acceptance Testing – UAT), vertragliche und regulatorische Abnahmetests sowie Alpha- und Beta-Tests behandelt. Absichtlich nicht behandelt werden hingegen betriebliche Abnahmetests (Operational Acceptance Testing – OAT), da diese in der Regel von Teams durchgeführt werden, die das System betreiben, und nicht von Testern und Businessanalysten.

1.3Nutzen dieses Buches

Das vorliegende Buch soll den Leserinnen und Lesern folgenden Nutzen bringen:

Eine umfassende, sowohl theoretische als auch praktische Einführung in das Thema Abnahmetest bieten.

Das Thema Abnahmetest auf der Grundlage des ISTQB

®

-Lehrplans aufarbeiten sowie alle prüfungsrelevanten Themen des Lehrplans vermitteln.

Relevante Themen über den Lehrplan hinaus vertiefen und durch Exkurse und Praxisbeispiele ergänzen.

Die praxisnahe Anwendung durch ein realistisches und durchgehendes Fallbeispiel illustrieren.

1.4Kapitelübersicht

Das Buch folgt im Wesentlichen der Kapitelstruktur des Lehrplans. Ausnahmen davon sind die Kapitel 4 und 5, die im Lehrplan genau andersherum angeordnet sind. Aus didaktischen Gründen wurde von dieser Anordnung für das Buch abgewichen. Die einzelnen Kapitel gliedern sich inhaltlich wie folgt:

Kapitel 2 behandelt die grundlegende Bedeutung des Abnahmetests im Softwarelebenszyklus. Es werden die Beziehungen des Abnahmetests zur Businessanalyse veranschaulicht und wichtige Begriffe und Konzepte der Businessanalyse, die einen Einfluss auf den Abnahmetest haben, dargestellt.

In Kapitel 3 werden die Aktivitäten und Aufgaben bei der Erstellung und dem Entwurf von Abnahmekriterien dargestellt. Es werden unterschiedliche Testvorgehensweisen vorgestellt und veranschaulicht, wie erfahrungsbasierte Testverfahren den Abnahmetest unterstützen können.

Kapitel 4 diskutiert und beschreibt die für den Benutzerabnahmetest wichtigsten nicht funktionalen Anforderungen und wie der Abnahmetest den Umgang mit diesen durch Abnahmekriterien unterstützt.

In Kapitel 5 werden zwei standardisierte Modellierungssprachen eingeführt, die für die Analyse und Spezifikation von Geschäftsprozessen und Geschäftsregeln eingesetzt werden können: Business Process Model and Notation (BPMN) sowie Decision Model and Notation (DMN). Im Abnahmetest werden Modelle und Modellierungssprachen vor allem während der Testanalyse und dem Testentwurf eingesetzt. Businessanalysten und Tester sollten daher die elementaren Eigenschaften beider Modellierungssprachen kennen, um die Vorteile eines visuellen bzw. modellbasierten Abnahmetests nutzen zu können.

Kapitel 6 erläutert, welche sozialen und kommunikativen Fähigkeiten für einen kollaborativen Abnahmetest wichtig sind und durch welche Aktivitäten und Werkzeuge der Abnahmetest unterstützt wird.

Im Anhang werden ergänzende Hinweise zum Lehrstoff, der Prüfung und den Lernzielen des Lehrplans gegeben. Im Glossar finden sich alle prüfungsrelevanten Schlüsselbegriffe sowie weitere wichtige Definitionen. Abschließend finden sich noch das Abkürzungs- und Quellenverzeichnis sowie ein Index.

1.5Fallbeispiel »CA-Cockpit«

Die in diesem Buch vorgestellten Konzepte und Vorgehensweisen beim Abnahmetest werden anhand eines durchgängigen Fallbeispiels veranschaulicht. Dem Fallbeispiel liegt das folgende, aus einem realen Praxisprojekt abgeleitete und vereinfachte Szenario zugrunde:

Ein Telekommunikationsunternehmen (ComAccept AG) betreibt ein Softwaresystem (CA-Cockpit) zum Verkauf von Handytarifen. Dieses Softwaresystem besteht zum einen aus einem Serviceportal, über das die Mitarbeiter der ComAccept AG die Produkte konfigurieren, Kunden betreuen und Buchungen verwalten können, zum anderen aus einem Kundenportal, über das die Kunden Handyverträge abschließen können. Das Softwaresystem ist in die Systemlandschaft des Telekommunikationsunternehmens integriert und hat u. a. Schnittstellen zu einem Customer-Relationship-Management-(CRM-)System (siehe Abb. 1–2).

Abb. 1–2Systemübersicht CA-Cockpit

CA-Cockpit bildet die Geschäftsprozesse der Fachabteilung »Produktmanagement« ab. Die Fachabteilung ist somit der geschäftliche Eigner und Auftraggeber für die (Weiter-)Entwicklung von CA-Cockpit. Die Fachabteilung wird in dem Projekt durch einen Businessanalysten vertreten, der somit die Rolle des Auftraggebers annimmt. Entwickelt wird das System von der internen Entwicklungsabteilung, die als Auftragnehmerin agiert.

Die Geschäftsprozesse werden u. a. durch Anwendungsfälle abgebildet und mithilfe von Geschäftsprozess- und Geschäftsregelmodellen modelliert. Die für die Fallstudie relevanten, bestehenden Geschäftsprozesse und ihre Akteure sind als Anwendungsfälle im folgenden Anwendungsfalldiagramm dargestellt (siehe Abb. 1–3).

Abb. 1–3Fallbeispiel – bestehende Anwendungsfälle

Das Fallbeispiel CA-Cockpit wird in den inhaltlichen Kapiteln dieses Buches kontinuierlich weiterentwickelt. Um die Fallbeispielbeschreibungen übersichtlich zu halten, werden nur die für das Verständnis der jeweils angesprochenen Themen notwendigen Informationen aufgeführt. Die Autoren weisen darauf hin, dass der Informationsgehalt in der Praxis deutlich höher sein kann als in diesem Buch. Beispielsweise werden Anforderungen nur durch einzelne, ausgewählte Attribute (z. B. ID, Name, Beschreibung) spezifiziert. Möglicherweise sind aber noch weitere Attribute (z. B. Autor, Kritikalität, Priorität, Quelle) sowie ergänzende Details (z. B. Ablaufdiagramm, Domänenmodell, Wireframes) relevant.

2Grundlagen des Abnahmetests

Dieses einleitende Kapitel erklärt die grundlegende Bedeutung des Abnahmetests im Softwarelebenszyklus. Es werden die Beziehungen des Abnahmetests zur Businessanalyse veranschaulicht und wichtige Begriffe und Konzepte der Businessanalyse, die einen Einfluss auf den Abnahmetest haben, dargestellt.

2.1Der Abnahmetest im Softwarelebenszyklus

2.1.1Testen im Softwarelebenszyklus

Softwaresysteme werden in der Regel schrittweise und mit zunehmender Detaillierung konzipiert, entworfen und implementiert. Ausgehend von einer Problemstellung und Beschreibung der Kunden- bzw. Nutzeranforderungen, wird eine fachliche Lösung entworfen, die technische Umsetzung geklärt und schließlich die einzelnen Komponenten entwickelt, die dann zu einem Produkt integriert werden.

Testen im V-Modell

Beim Testen muss diese Integration von der einzelnen Komponente bis zum fertigen Produkt berücksichtigt und das System auf den verschiedenen Ebenen betrachtet und geprüft werden [Spillner & Linz 19]. Dieses grundsätzliche Verständnis von Entwicklungs- und Testaktivitäten wird durch das allgemeine V-Modell beschrieben [Boehm 79]. Es beschreibt verschiedene Teststufen sowie deren Beziehungen zu den korrespondierenden Entwicklungsaktivitäten (siehe Abb. 2–1). Wichtig am V-Modell sind dabei nicht die konkrete Anzahl, die Bezeichnungen oder die Reihenfolge der Entwicklungs- und Testaktivitäten, diese können in der Praxis durchaus unterschiedlich sein. Vielmehr verdeutlicht das V-Modell die grundlegende logische Beziehung von Entwicklungs- und Testaktivitäten und deren gleichberechtigte Abbildung.

Abb. 2–1Allgemeines V-Modell

Jede Teststufe ist eine Gruppe von Testaktivitäten, die gemeinsam organisiert und verwaltet werden, und stellt eine Instanz des Testprozesses dar (bestehend aus den Hauptaktivitäten Testplanung, Testüberwachung und -steuerung, Testanalyse, Testentwurf, Testrealisierung, Testdurchführung, Testabschluss).

Teststufen

Die Teststufen stehen mit anderen Aktivitäten des Softwareentwicklungslebenszyklus in Verbindung. Jede Teststufe ist gekennzeichnet durch ihre spezifischen Ziele, Testbasis, Testobjekte, typische Fehlerzustände und -wirkungen sowie Ansätze und Verantwortlichkeiten. Grundsätzlich unterscheidet man die folgenden vier Teststufen:

Komponententest

Konzentriert sich auf einzelne Komponenten, die einzeln (d. h. getrennt bzw. isoliert voneinander) testbar sind.

Integrationstest

Konzentriert sich auf die Integration von Komponenten oder Systemen sowie die Interaktion zwischen diesen Komponenten oder Systemen1.

Systemtest

Konzentriert sich auf das Verhalten und die Fähigkeiten des Systems oder Produkts (z. B. Ende-zu-Ende-Aufgaben). Der Systemtest ist die letzte Teststufe in der Verantwortung des Herstellers und wird in der Regel von unabhängigen Testern durchgeführt.

Abnahmetest

Konzentriert sich wie der Systemtest typischerweise auf das Verhalten und die Fähigkeiten eines gesamten Systems oder Produkts. Diese Teststufe liegt in der Regel in der Verantwortung des Kunden bzw. Anwenders.

Auch wenn das V-Modell ein wenig in die Jahre gekommen scheint und obwohl es eigentlich ein rein sequenzielles Softwareentwicklungsmodell ist, sind die grundlegenden Prinzipien für das Testen auch heute noch relevant und lassen sich auf Projekte übertragen, in denen nach einem iterativ-inkrementellen oder agilen Softwareentwicklungsmodell entwickelt wird – gewissermaßen steckt in jeder Iteration der Durchlauf eines kleinen V-Modells.

2.1.2Zweck und Ziele des Abnahmetests

Der Schwerpunkt des Abnahmetests ist es, zu bestimmen, ob ein System abgenommen werden kann. Im Gegensatz zu den Teststufen Komponenten-, Integrations- und Systemtest, bei denen der Softwarehersteller die Verantwortung trägt, liegt die Verantwortung beim Abnahmetest beim Kunden bzw. Anwender2. Sowohl Hersteller als auch Anwender können sich dabei innerhalb derselben Organisation befinden (z. B. Fachbereich und Entwicklungsabteilung) oder auch in einer geschäftlichen Beziehung als verschiedene Organisationen zueinanderstehen (z. B. Auftraggeber und Auftragnehmer).

»In der Verantwortung liegen« muss dabei nicht notwendigerweise bedeuten, dass der Kunde bzw. Anwender den Abnahmetest auch selbst organisiert und durchführt, wichtig ist aber, dass der Abnahmetest aus dessen Sicht durchgeführt wird und der Kunde bzw. Anwender in die Lage versetzt wird, sich ein Urteil zu bilden und das System abzunehmen (oder auch abzulehnen). Je nach Softwareentwicklungsmodell und Grad der Beteiligung des Kunden bzw. Anwenders ist der Abnahmetest unter Umständen der einzige Test, den der Kunde nachvollziehen kann, an dem er direkt beteiligt ist oder für den er sogar verantwortlich ist [Spillner & Linz 19].

Vertrauensbildende Maßnahme

Der Abnahmetest kann auch als vertrauensbildende Maßnahme begriffen werden. Ein Kunde oder Anwender wird ein System nur dann abnehmen (wollen), wenn er ausreichend Vertrauen in das System hat. Während in den vorhergehenden Teststufen das Finden von Fehlern ein typisches Testziel ist, steht beim Abnahmetest eher die Schaffung von Vertrauen im Vordergrund. Werden beim Abnahmetest zu viele Fehler gefunden, ist das nicht unbedingt vertrauensbildend. Der Abnahmetest sollte daher – bei adäquater Testintensität – möglichst keine Fehler aufdecken. Dies gelingt nur, wenn das abzunehmende System in den vorhergehenden Teststufen so weit gereift ist, dass der Abnahmetest idealerweise nur noch die Bestätigung dafür liefern muss, dass alles erwartungsgemäß funktioniert.

Drüber nachgedacht …

Ersetzen Sie das Wort »abnehmen« oder »akzeptieren« durch das Wort »vertrauen«. Wann vertrauen Sie jemandem oder etwas? Was muss diese Person oder Sache dafür erfüllen, bestätigen, nachweisen oder beweisen? Wie viel möchten Sie gerne selbst beurteilen können, um zu vertrauen, wie viel glauben Sie der Person oder Sache?

Letzte Teststufe vor der Inbetriebnahme

»Keine Fehler« finden bedeutet nicht, wenig oder nicht zu testen. Der Abnahmetest ist eine kritische Teststufe und stellt die letzte Möglichkeit dar, zu verhindern, dass Fehler in den Betrieb bzw. Produktion gelangen. Dementsprechend ist es gut, einen Fehler noch im Abnahmetest zu finden, besser jedoch wäre, diesen Fehler bereits in früheren Teststufen gefunden zu haben.

Frühes Testen erwünscht

Dieser Umstand wird als wesentlicher Grundsatz des Testens sehr anschaulich verdeutlicht: »Frühes Testen spart Zeit und Geld«3. Der Grundsatz beschreibt die Tatsache, dass es umso günstiger ist, je früher ein Fehler im Entwicklungsprozess gefunden und behoben wird, da aufwendige Änderungen reduziert oder sogar vollständig vermieden werden können. Die klassische theoretische Grundlage für diesen Grundsatz bildet die Betrachtung der relativen Fehlerbehebungskosten nach [Boehm 79]. In dieser Untersuchung wird beschrieben, wie hoch die relativen Kosten zur Behebung eines Analysefehlers sind, abhängig davon, in welcher Phase des Entwicklungsprozesses der Fehler gefunden und behoben wird (siehe Abb. 2–2).

Abb. 2–2Relative Fehlerbehebungskosten

Während diese Kosten in den frühen Phasen erwartungsgemäß noch eher gering sind, steigen sie exponentiell und sind in den späten Phasen dementsprechend hoch. Die Kosten, um einen Fehler, der während der Analyse des Systems gemacht wurde, erst in der Abnahme zu beheben, liegen um das ca. 50-Fache über den Kosten der Behebung bereits in der Analysephase. Dies verdeutlicht recht einfach die hohe Bedeutung des frühen Testens – Fehler sollten idealerweise immer in der Phase gefunden und behoben werden, in der sie gemacht werden. Dies wird auch Fehlereindämmung innerhalb einer Phase genannt.

Aus Sicht des Abnahmetests wird hier deutlich, dass es sehr ineffizient ist, erst in der Abnahmephase Fehler zu finden, da hier die Kosten – mit Ausnahme des darauffolgenden Betriebs – am höchsten sind. Werden Analysefehler erst in der Abnahmephase gefunden, so ist das häufig auf ein mangelhaftes Anforderungsmanagement zurückzuführen, da die Anforderungen nicht oder nicht adäquat in der Analysephase definiert wurden. Zusätzlich kommt noch hinzu, dass typischerweise über die Hälfte der Fehler in den frühen Phasen (in der Analyse und dem Entwurf) gemacht werden. Hierbei können statische Tests, wie z. B. Reviews, effizient dazu beitragen, Fehler frühzeitig zu finden und zu verhindern, dass diese in die folgenden Entwicklungsphasen weitergetragen werden.

Der Umfang des Abnahmetests kann stark variieren. Bei fehlender Transparenz und fehlendem Vertrauen in die vorhergehenden Entwicklungs- und Testaktivitäten wird ein Abnahmetest womöglich umfangreicher ausfallen, als wenn die Transparenz und das Vertrauen gegeben sind. Im Foundation Level [ISTQB CTFL] werden vier Arten des Abnahmetests behandelt:

Benutzerabnahmetest

(User Acceptance Testing – UAT)

Wird durchgeführt, um festzustellen, ob vorgesehene Benutzer das System abnehmen.

Betrieblicher Abnahmetest

(Operational Acceptance Testing – OAT)

Wird durchgeführt, um zu bestimmen, ob der Betrieb und/oder die Systemadministration ein System abnehmen können.

Vertraglicher und regulatorischer Abnahmetest

Wird durchgeführt, um zu verifizieren, ob ein System seine vertraglichen Anforderungen erfüllt bzw. den relevanten Gesetzen, Richtlinien und Vorschriften entspricht.

Alpha- und Beta-Test

Eine Art Abnahmetest, der in der Testumgebung des Herstellers durch Akteure außerhalb der Herstellerorganisation durchgeführt wird (Alpha-Test) bzw. der an einem externen Standort durch Akteure außerhalb der Herstellerorganisation durchgeführt wird (Beta-Test).

In diesem Buch werden – analog zum »Acceptance Testing «-Lehrplan – Benutzerabnahmetests, vertragliche und regulatorische Abnahmetests sowie Alpha- und Beta-Tests behandelt. Absichtlich nicht behandelt werden hingegen betriebliche Abnahmetests, da diese in der Regel von Teams durchgeführt werden, die das System betreiben, und nicht von Testern und Businessanalysten.

2.1.3Abnahmetests in sequenziellen vs. agilen Softwareentwicklungsmodellen

Wie in Abschnitt 2.1.1 dargelegt, lassen sich die grundlegenden Prinzipien des mehrstufigen Vorgehens bei der Entwicklung und dem Test eines Systems sowohl in den traditionellen bzw. sequenziellen als auch den iterativ-inkrementellen bzw. agilen Softwareentwicklungsmodellen anwenden. Wie bei allen anderen Entwicklungsaktivitäten auch werden die Aktivitäten des Abnahmetests entsprechend den üblichen Praktiken der jeweiligen Modelle sequenziell oder iterativ ausgeprägt.

Agiler vs. sequenzieller Abnahmetest

In einem sequenziellen Softwareentwicklungsmodell stellt der Abnahmetest häufig die letzte, abschließende Testaktivität vor Freigabe und Inbetriebnahme des Systems dar. In einem agilen Softwareentwicklungsmodell kann sich der Abnahmetest mit den anderen Teststufen überlappen und findet wiederholend in den einzelnen Iterationen statt. Die Abnahmetestaktivitäten können sich hierbei sowohl auf das Testen einzelner User Stories als auch des ganzen Inkrements (z. B. im Rahmen eines Sprint-Reviews) erstrecken.

Fallbeispiel

Ausprägung des Abnahmetests in unterschiedlichen Softwareentwicklungsmodellen

Variante A: Sequenzielles Softwareentwicklungsmodell

In dieser Variante des Fallbeispiels liegen die Teststufen Komponenten-, Integrations- und Systemtest in der Verantwortung der internen Entwicklungsund Testabteilung. Nach Abschluss des Systemtests wird das System an den Fachbereich übergeben. Der Fachbereich verantwortet den Abnahmetest, die Tests werden durch den Businessanalysten der Fachabteilung organisiert und gemeinsam mit den Fachexperten und Testern durchgeführt. Im Abnahmetest wird gegen die Anforderungen der Fachabteilung getestet und auf Basis der Testergebnisse eine Freigabe für den Produktivbetrieb des Systems erteilt – oder auch nicht.

Variante B: Agiles Softwareentwicklungsmodell

In dieser Variante des Fallbeispiels liegen alle Teststufen vom Komponententest bis zum Abnahmetest in der Verantwortung des agilen Teams. Die Abnahmetests werden von den Testern im Team in Zusammenarbeit mit dem Businessanalysten und Fachexperten organisiert und durchgeführt. Die Abnahmetests basieren auf den User Stories, die das gesamte Team während der Sprint-Planung ausgewählt und im Sprint umgesetzt hat. Die Abnahme erfolgt im Sprint-Review, in dem das Inkrement dem Product Owner durch das Team demonstriert und auf dieser Grundlage eine Freigabe für den Produktivbetrieb erteilt wird – oder auch nicht.

2.2Grundlegende Beziehungen

Der wesentliche Zweck des Abnahmetests ist es, ein System oder Produkt basierend auf der Sicht und dem Urteil des Kunden bzw. Anwenders abzunehmen. Wie in Abschnitt 2.1.1 bereits dargelegt, ist der Abnahmetest unter Umständen der einzige Test, den der Kunde nachvollziehen kann, an dem er direkt beteiligt ist oder für den er sogar verantwortlich ist [Spillner & Linz 19].

Die Art und der Umfang der Beteiligung und Verantwortung des Kunden bzw. Anwenders können dabei sehr unterschiedlich ausgeprägt sein und sind häufig abhängig vom Softwareentwicklungsmodell im Projekt (sequenziell vs. agil, siehe Abschnitt 2.1.3).

Kunde, Auftraggeber, Auftragnehmer und Anwender