Aus- und Weiterbildung zum ISTQB® Foundation Level Specialist – Acceptance Testing
E-Book, Deutsch, 242 Seiten
Reihe: Basiswissen
ISBN: 978-3-96910-287-9
Verlag: dpunkt
Format: EPUB
Kopierschutz: Wasserzeichen (»Systemvoraussetzungen)
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.
Autoren/Hrsg.
Weitere Infos & Material
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–1
Allgemeines 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–2
Relative 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...
