Testkonzept - Testfallermittlung

Ein Testfall ist eine Zusammenfassung aller Eingaben (Fachwissen, Fachkonzept), die zur gleichen Wirkung führen.

Die Zielsetzung einer systematischen bzw. methodischen Testfallermittlung ist es eine erhöhte Abdeckung der fachlichen Anforderungen zu erreichen.

Bei einem Testfall handelt es sich um eine abstrakte Beschreibung des zu testenden Sachverhaltes, welche durch Testdaten konkretisiert wird.

Die Spezifikationen eines Testfalls sollten im Projekt möglichst zu einem frühen Zeitpunkt definiert werden.

Prozess Testfallfindung

Der Prozess der Testfallfindung zielt darauf ab, mit minimalem Aufwand eine maximale Testabdeckung zu erreichen und potenzielle Fehlentwicklungen aufzudecken. Ein strukturiertes Vorgehen ist hierfür essenziell, um Ressourcen effizient einzusetzen und die Testabdeckung zuverlässig bewerten zu können.

Testfallschablone von Use Case ableiten

Grundlage
Die Use-Cases des Projekts bilden die Basis für die Generierung von Testfällen.
Testfallschablone
Für jeden Use-Case wird eine Testfallschablone erstellt, die hilft, relevante Systeme und Testobjekte zu identifizieren, die vom Use-Case betroffen sind.

Ausgangsbedingungen

Definition
Klare Formulierung der notwendigen Ausgangsbedingungen für jede Testfallschablone.
Aktivitäten und Checkpunkte
Dokumentation aller relevanten Aktivitäten (Testschritte) und Formulierung der erwarteten Ergebnisse als Checkpunkte.0

Formulieren von abstrakten Testfällen

Ableitung von Attributen
Festlegung der für den Test relevanten Attribute und deren mögliche Ausprägungen basierend auf den Mustertestfällen.
Abstrakte Testfälle
Durch die Kombination der Attribute werden abstrakte Testfälle entwickelt, die eine sinnvolle Balance zwischen Komplexität und Nutzen bieten.

Aufwand ableiten

Aufwandschätzung
Die erstellten Testfälle lassen sich nach dem definierten Vorgehen leicht mit einem erwarteten Aufwand beziffern.

Testfälle konkretisieren

Produktionsnahe Daten
Das Testen mit Daten, die der Produktionsrealität nahekommen, wird angestrebt.0
Identifizierung von Testdaten
Auf Basis der abgeleiteten Vorgaben werden entsprechende Testdaten im Produktionssystem identifiziert und für die Erstellung konkreter Testfälle genutzt.
Prämisse
Jeder Testfall ist spezifisch für die jeweilige Abteilung und das betroffene System zu formulieren.

Negative Testfälle

Bedeutung
Negative Testfälle sind ebenso wichtig wie positive Testfälle und dienen der Überprüfung der Systemstabilität.
Erstellung
Durch die Kombination von Attributen werden auch hier sinnvolle negative Testfälle entwickelt.

Testfalldurchführung

Priorisierung
Vor der Ausführung durch Tester werden Testfälle priorisiert, um eine gezielte Testdurchführung zu ermöglichen.
Zuweisung
Testfälle werden bestimmten Testern zugewiesen, wobei die Verfügbarkeit und Expertise der Tester berücksichtigt wird.

Ein systematischer Ansatz in der Testfallfindung trägt maßgeblich zur Qualitätssicherung bei, indem er sicherstellt, dass Tests zielgerichtet, umfassend und effizient durchgeführt werden können.

Abstrakter Testfall

Ein abstrakter Testfall dient als Vorlage oder Schema, das die wesentlichen Komponenten eines Tests definiert, ohne spezifische Eingabewerte oder Details zu verwenden. Diese Art von Testfall ist besonders nützlich, um standardisierte Testprozesse zu entwickeln, die auf eine Vielzahl ähnlicher Testszenarien anwendbar sind. Hierbei wird der Fokus auf die generelle Teststruktur und die zu prüfenden Bedingungen gelegt, nicht auf individuelle Testdaten.

Beispiel: Testfall für einen Zahlungseingang

Vorabbedingungen
- Vorhandensein eines aktiven und validen Kontos.
- Erfüllung aller notwendigen regulatorischen und internen Compliance-Anforderungen.
Ausführen
- Initiierung eines Zahlungseingangs durch eine externe Quelle oder einen internen Transfer.
- Erfassung der Transaktion im entsprechenden Buchhaltungssystem.
Checkpunkte
- Korrekte Verbuchung der Zahlung auf dem vorgesehenen Konto.
- Sichtbarkeit der Transaktion im Finanzstrom und in den entsprechenden Überwachungstools.
- Überprüfung der Transaktionsdetails wie Betrag, Datum, Absender und Empfängerinformationen gegen die erwarteten Werte.

Ein abstrakter Testfall wird ohne konkrete Ein- und Ausgabewerte für Eingabedaten und vorausgesagte Ergebnisse beschrieben. Es werden logische Operatoren verwendet, weil die konkreten beispielsweise noch nicht definiert oder verfügbar sind. Der abstrakte Testfall wird daher auch logischer Testfall bezeichnet.

Konkreter Testfall

Ein konkreter Testfall verwendet spezifische Daten, um die Funktionalität und Korrektheit von Systemprozessen unter realen Bedingungen zu überprüfen. Er wird aus einem abstrakten Testfall abgeleitet, indem konkrete Daten und Szenarien eingeführt werden, die die tatsächlichen Betriebsbedingungen simulieren. Dieser Ansatz ermöglicht es, die Präzision und das Verhalten des Systems unter festgelegten Bedingungen zu evaluieren.

Beispiel: Testfall für einen Zahlungseingang

Vorabbedingungen
- Existenz eines aktiven und validen Kontos.
- Das Konto muss alle regulatorischen Bedingungen erfüllen und für die Transaktion freigegeben sein.
Ausführen
- Veranlassung eines Zahlungseinganges:
- Produkttyp: Point of Sale (POS)
- Kundennummer: 123456
- Zahlungsbetrag: 100 €
- Erfassung der Zahlung im Buchhaltungssystem.
Checkpunkte
- Überprüfung, ob die Buchung korrekt durchgeführt wurde:
- - Buchungsbetrag: 100 €
  - Belastetes Konto: 123456
- Sichtbarkeit der Buchung im Finanzstrom:
- - Überprüfung in Echtzeit-Berichterstattungs- und Überwachungssystemen.
  - Verifikation der Transaktionsdetails in den Transaktionshistorien.

Zufallstest

Mit diesem Verfahren werden die Testfälle durch ein zufälliges Auswählen, Generieren oder Definieren von Testdaten ermittelt.

Über einen Zufallsgenerator sollte hierbei sichergestellt werden, dass wirklich zufällige Daten geliefert werden, die jedoch sinnvoll (zum Beispiel maximales Alter einer Person) sein müssen.

Bei dieser Methode sind Zufallstests in der Regel nicht so effektiv wie andere Testmethoden. Des Weiteren ist die Nachvollziehbarkeit und Regressionsfähigkeit bei solchen Tests oft nur eingeschränkt gegeben.

Ad-hoc Testfallermittlung

Ein Ad hoc Test kann prinzipiell in jeder Phase einer Testvorbereitung bzw. einer Testausführung zum Einsatz kommen. Vom Vorgehen her überlegt sich ein Tester – anhand von bestimmten fachlichen Arbeitsunterlagen - spontan eine Testsituation, dokumentiert diese und führt sie auch aus.

Die erreichbare Testabdeckung ist hier stark vom Zufall und der Kreativität des Testers abhängig, so dass dieses Verfahren praktisch nur für unkritische Testobjekte geeignet ist. Des Weiteren ist eine Wiederholbarkeit derartiger Tests oftmals nur bedingt möglich.

Intuitiver Test

Für einen intuitiven Test besteht an den Tester die Anforderung, dass dieser für den fachlichen Sachverhalt ein ausgewiesener Experte ist und er aufgrund seiner praktischen (langjährigen) Erfahrung nach Risikogewichtung ein festgelegte menge von Praxisfällen (ggf. durch Hinzuziehen von entsprechenden Unterlagen) beschreiben kann.

Diese Beschreibungen sollten so detailliert erfolgen, dass die Testfallausführung bei Bedarf auch durch andere Tester erfolgen kann.

Unter einer intuitiven Testfallermittlung ist ein Testverfahren zu verstehen, bei dem die Erfahrung von bestimmten Experten genutzt wird, um mögliche vorkommende Fehlerzustände in einem Softwaresystem oder einer Komponente vorherzusagen. Auf dieser Basis können Testfälle so abgeleitet werden, dass diese diesbezügliche Fehlerzustände aufdecken.

Error Guessing

Error Guessing (= ein Test der Ausnahmen vom üblichen Ablauf bzw. von komplexen Situationen ) ist eine informelle Technik, die für Vermutungen zu möglichen Fehlern – in der Regel während einer Testdurchführung - die Kenntnisse und Erfahrungen der Tester nutzt und sich damit als eine Ergänzung zu den formalen Testmethoden abgrenzt.

Im Modultest ist diese Vorgehensweise kaum möglich, weil die Testfälle hier vor der Durchführung grundsätzlich spezifiziert und dokumentiert sein müssen.

Entscheidungstabellentest

Entscheidungstabellentests verfolgen das Ziel einen Testabdeckungsgrad zu erhöhen, indem eine fachliche Wirkung nicht direkt sondern nur im Zusammenspiel mit anderen Parametern ausgelöst wird.

Unter einer Entscheidungstabelle versteht man eine Menge von Regeln, die jeweils aus eine Kombination von Bedingungen und den dazugehörigen Aktionen bestehen und für die Erstellung von Testfällen dienen.

Bei mehreren Kombinationsmöglichkeiten besteht hierbei häufig ein Risiko, dass nicht vollständig alle Testfälle sondern nur die nahe liegenden beschrieben werden.

Für die Beschreibung dieser Testfälle sollten folgende Regel beachtet werden

» Jede Bedingung muss einzeln (d.h. nicht mit UND/ ODER Anweisungen verbunden) sein

» Nur positive Formulierung sollen doppelte Verneinungen vermeiden

» Pro Testobjekt eine separate Entscheidungstabelle, damit Anzahl an Testfällen überschaubar

In der Entscheidungstabelle werden die einzelnen Bedingungen und Ergebnisse aufgeführt. Bei den Bedingungen steht zum Beispiel eine „1“ für die Erfüllung dieser Bedingung und eine „0“ für eine nicht erfüllt Bedingung sowie ein „2“ zeigt an, dass diese Bedingung das Ergebnis nicht beeinflusst.

Für die Erstellung von logischen Testfällen muss in der Entscheidungstabelle geprüft werden, ob es Kombinationen von Bedingungen gibt, die sich gegenseitig ausschließen. Diese Testfälle sind in einem solchen Fall aussortiert und in der Entscheidungstabelle als „nicht durchführbar“ zu kennzeichnen.

Für die Erstellung von konkreten Testfällen werden die die logischen Testfälle mit konkreten Testdaten gefüllt. Um verschiedene Testdaten nutzen zu können, kann eine Anwendung der Grenzwertanalyse hilfreich sein.

Die Anzahl der zu testenden Testfallkombinationen lässt sich weiter optimieren, wenn statt der Mehrfachbedingungsabdeckung andere Testabdeckungsmaße genutzt werden.

Die Komplexität des Verfahrens lässt sich reduzieren, indem Entscheidungstabellen nur auf Elemente angewendet werden, die direkt innerhalb einer Fachlichkeit voneinander abhängig sind.

Eliminationsmethode

Die Eliminationsmethode verfolgt das Ziel, dass zur Abdeckung einer fachlichen Anforderung so wenige Testfälle wie möglich erstellet werden müssen.

Hierfür werden zu den mit Bedingungen enthaltenen fachlichen Regeln tabellarisch alle möglichen logischen Kombinationen gebildet und anhand definierter fachlichen Wirkungen gruppiert. Damit können Kombinationen, die zu identischen Wirkungen führen, identifiziert und zusammengefasst werden.

Unterscheidungen beim Testabdeckungsgrad

Ein Ableiten der Testfälle für die maximale Testabdeckung wird dadurch erreicht, dass aus jeder Regel ein separater Testfall abgeleitet wird. Die im vorhergehenden Schritt definierte Zuordnung der Regeln zu den Wirkungen wird hierbei ignoriert.

Ableiten der Testfälle für die minimale Testabdeckung wird auf Basis der Wirkungen spezifiziert, wobei jede Wirkung mindestens einmal ausgeführt werden muss.

Eine systematische Reduzierung der Testfälle für eine optimale Testabdeckung verfolgt das Ziel, dass die Regeln mit identischer Wirkung zu einem Testfall zusammengefasst und dadurch die Überdeckungen mit anderen Wirkungen minimiert werden. Im günstigsten Fall ist das Ergebnis identisch mit der minimalen Überdeckung.

Schaubild: Abdeckungsgrade für die Eliminationsmethode

Testabdeckungsgrad	Bedeutung
Maximal	Berücksichtigung aller theoretisch möglichen Kombinationen für zur Überdeckung der Bedingungskombinationen
Minimal	Sämtliche Wirkungen müssen mindestens einmal berücksichtigt werden (Wirkungsabdeckung 100%).
Optimal	Kombinationen mit gleicher Wirkung werden zusammengefasst (Bedingungsabdeckung 100%).

Äquivalenzklassenanalyse

Die Äquivalenzklassenmethode verfolgt das Ziel, mit einem einigen Testfall eine ganze Klasse von gleichartigen Fehlern aufzudecken.

In einer Äquivalenzklasse dürfen folglich nur solche angenommen Eigenschaften (Konstellationen) enthalten sein, die aus konkreten Eingabewerten und konkreten Anfangszuständen beim jeden Testlauf nur zu denselben Fehlerarten mit derselben Fehleranzahl führen können.

Unter Äquivalenzklassen ist ein Teil des Wertebereichs von Ein- oder Ausgaben zu verstehen, in dem basierend auf der zugrunde liegenden Spezifikation ein gleichartiges Verhalten der Komponente oder des Softwaresystems angenommen wird.

Die Clusterung (Gruppierung) von geeigneten Äquivalenzklassen - welche nicht zwingend überschneidungsfrei sein müssen - kann einen Testaufwand erheblich reduzieren.

Im Rahmen einer Äquivalenzklassenbildung werden Testfälle grundsätzlich so ausgewählt, dass jede Äquivalenzklasse mindestens einmal abgedeckt wird.

Vorgehen für die Ermittlung von Testfällen mit Hilfe der Äquivalenzklassenmethode

Einteilung des Eingabewertebereiches und mögliche Anfangszustände des Testobjektes in Äquivalenzklassen unter Berücksichtigung der Zielvorgabe für die zu testenden Gesichtspunkte.

Prüfung der Äquivalenzklassen auf Vollständigkeit und ggf. auf Überschneidungsfreiheit. Ungültige Äquivalenzklassen werden bei Bedarf ergänzt oder aussortiert.

Auswahl und Spezifizierung der konkreten Eingabedaten, Anfangszustände, Ausgabewerte und Endzustände.

Prüfung der konkreten Testdaten auf deren Wirksamkeit zwecks Aufdeckung von möglichen Fehlern

Grenzwertanalyse

Die Grenzwertanalyse definiert die Wertauswahl der Gültigkeitsbereiche (Randwerte für gültige bzw. ungültige Daten) für eine Testfallermittlung. Die Grenzwertanalyse kann als im Rahmen einer Äquivalenzklasseneinteilung sowohl für Eingabe- als auch für Ausgabedaten verwendet werden.

Die Grenzwertanalyse ist Black Box Testverfahren, bei dem die Testfälle unter der Verwendung von Grenzwerten mit der Zielverfolgung entstehen, insbesondere die Werte mit einer besonderer Fehleranfälligkeit (höherer Fehlerwahrscheinlichkeit) zu prüfen.

Es empfiehlt sich die festgelegten Grenzen (z.B. min. und max. einer Variablen aus dem Intervall min. bis max.; minimale und maximale Anzahl von Schleifendurchläufen etc.) von Größen an den Schnittstellen auf Plausibilität zu untersuchen.

Unter Grenzwert ist ein Ein- oder Ausgabewert zu verstehen, der am Rand einer Äquivalenzklasse (kleinste und größte Wert eines Bereichs) liegt.

Klassifikationsbaum-Methode

Bei der Klassifikationsbaum Methode handelt es sich um einen Datenkombinationstest, welcher zum Test einer Funktionalität sowohl auf Detail- als auch auf Gesamtsystemebene geeignet ist.

Aus Sicht der einzelnen Datenattribute muss überlegt werden, welche Ausprägungen der Variationen der Daten getestet werden sollen.

Eine Clusterung (Gruppierung) von geeigneten Äquivalenzklassen - welche nicht zwingend überschneidungsfrei sein müssen - kann einen Testaufwand erheblich reduzieren.

Für die Testbasis können verschiedene Informationen berücksichtig werden

» Formale Dokumentationen (Funktionelles Design, Datenmodelle, Anforderungen)

» Informelle Dokumentationen (Handbücher, Voruntersuchungen, Memos)

» Undokumentierte Erfahrungswerte

Vorgehen beim Datenkombinationstest

Identifizierung

der

Testsituationen

Identifizierung aller Attribute, die die Funktionalität beeinflussen, Bestimmung der dazugehörigen Äquivalenzklassen und Ermittlung der Abhängigkeiten der Attribute zueinander.

Anschließend werden die Attribute als ein Klassifizierungsbaum dargestellt und die Äquivalenzklassen wie die Blätter eines Baumes angehängt.

Kritische Kombinationen aus Attributen können zusätzlich als Attributpaare definiert werden, um ein Testen in allen möglichen Kombinationen sicherstellen zu können.

Erstellung

logischer

Testfälle

In Form einer Tabelle werden unter dem Klassifikationsbaum die logischen Testfälle im rahmen eines Gitterrasters (senkrechte Linien = Äquivalenzklassen, wagerechte Linien = logischer Testfall) entwickelt.

Welche Äquivalenzklassen pro Testfall genutzt werden sollen, kann durch eine Markierung auf dem Schnittpunkt der Verbindungslinien markiert werden.

Dei der Auswahl der Kombinationen ist darauf zu achten, dass Abhängigkeiten der Attribute untereinander beachtet werden.

Erstellung

konkreter

Testfälle

Die einzelnen Attribute werden mit konkreten Daten – die z.B. anhand einer Grenzwertanalyse ermittelt werden können - belegt und führen somit zu konkreten Testfällen.

Festlegung

des Startpunktes

Um die korrekten Testfälle nutzen zu können, muss die Belegung der für diese Testfälle relevanten Stammdaten festgelegt werden.

Bei einer Abhängigkeit des Attributes C vom Attribut B ergeben sich bei der Bestimmung von logischen Testfällen (siehe nachfolgendes Schaubild) 6 Testfälle.

Anmerkung:

Ohne Verwendung von Attributpaaren wären es hingegen nur 3 Testfälle.

Systematische Testfallentwicklung

Die systematische Testfallentwicklung verfolgt das Ziel eine optimale Abdeckung der Fachlichkeiten zu erreichen.

Hierfür wird als erstes die Methode der Äquivalenzklassenanalyse verwendet um für jedes Feld der Testobjekte die Elementklassen zu bestimmen. Der Testfall wird beschrieben anhand der Kombinationen und durch direkte Zuordnung zu Elementklassen. Besitzt eine Elementklasse nur eine definitive Wirkung im Zusammenhang mit einer Elementklasse eines zweiten Eingabefeldes, besteht eine Abhängigkeit.

Bestimmen der Elementklassen und der fachlichen Wirkungen

» Definitionsbereich je Eingabefeld ist durch eine/mehrere Elementklassen vollständig abgedeckt

» Inhalte zweier Elementklassen dürfen sich nicht überlappen

» Zulässige Elementklassen ermöglichen Verarbeitung/ unzulässige verhindern Verarbeitung

» Zwei Elementklassen dürfen hinsichtlich der Wirkungen nicht identisch sein

Als nächstes wird die Methode der Entscheidungstabellen verwendet, um die Wirkungen von Eingaben durch alle möglichen Kombinationen von Elementklassen zu erzeugen. Zum Abschluss soll mittels der Eliminationsmethode versucht werden, die überflüssigen Kombinationen zu identifizieren und auszuschließen.

Die systematische Testfallermittlung ist beendet, wenn :

» Alle Elementklassen mindestens in einem Testfall enthalten sind

» Bei abhängigen Elementklassen alle relevanten Kombinationen in mindestens einem Testfall
referenziert sind

» Alle zulässigen Elementklassen bzw. alle Kombinationen, die zu einer Verarbeitung führen,
sind in mindestens einem positiven Testfall enthalten

» Alle Wirkungen sind mindestens einmal erreicht

Bottom-Up Methode

Basierend auf den Ergebnissen aus dem Funktionstest wird mittels einer Bottom Up Methode ein Funktionskettentest aufgebaut. Sofern die Bottom Up Methode auch für IT Tests verwendet werden soll, sind die technischen Kriterien (z.B. Zugriffe auf gleiche Datenobjekte, Zugehörigkeit zu einer Teilkomponente) zu gruppieren.

Ziel der Bottom Up Methode ist es die Grenzen festzustellen, innerhalb derer eine Verknüpfung von Funktionen oder Module zu Funktionsketten möglich ist. Hieraus lassen sich dann Testfallketten bilden, die eine möglichst große Abdeckung der Abhängigkeiten innerhalb eines Teilsystems ermöglichen.

Top Down Methode

Eine Top Down Methode ist prinzipiell der umgekehrte Weg einer Bottom Up Methode.

Der Überblick über die relevanten zu testenden Geschäftsprozesse oder Anwendungen erfolgt durch ein Herunter brechen von auf Funktionsgruppen, Funktionen und Module „von oben nach unten“.

Auf dieser Basis kann auch eine Risikoschätzung – welche letztendlich für Erstellung von Testfallketten herangezogen wird - vorgenommen werden.

Geschäftsprozesstest

Diese Testmethode prüft nicht das Design von Systemen sondern die Korrektheit deren Struktur. Der Schwerpunkt dieser Testart liegt in der Abdeckung der verschiedenen Verarbeitungsmöglichkeiten auf der Grundlage einer Pfadabdeckung.

Die Grundlage für den Durchlauf eines Geschäftsprozesstest sind von daher strukturierte Informationen (Flussdiagramm, Kontextdiagramm, Prozessdiagramm) über das erforderliche Systemverhalten (= erwartetes Ergebnis) und ggf. zusätzliche Anforderungen an die Testdaten/ an Testrollen.

Vorgehen beim Geschäftsprozesstest

Identifizierung

der

Testsituationen

Um auf der Grundlage eines Flussdiagramms einen Geschäftsprozesstest durchführen zu können, ist es erforderlich, dass für die einzelnen Aktionen der Start und das Ende festgelegt werden und aus den dazwischen befindlichen Teilpfaden entsprechende logische Testfälle abgeleitet werden.

Erstellung

logischer

Testfälle

Aus den einzelnen Teilpfaden werden - bis alle Teilpfade (ggf. mehrfach) genutzt sind - Pfadkombinationen zusammengesetzt, wobei das Ende eines Teilpfades dem folgenden Anfang des Teilpfades entsprechen muss.

Erstellung

konkreter

Testfälle

Die logischen Testfälle werden mit konkreten Werten für Eingaben und vorausgesagte Ergebnisse versehen, welche aus einem Softwaresystem stammen oder entsprechend angelegt werden müssen.

Vorgänger Nachfolger Matrix

Das Vorgänger Nachfolger Matrix Verfahren dient zu einer vollständigen Abbildung aller relevanten Testfallkettenbeziehungen.

Hierfür müssen die für das Testobjekt bekannten Funktionen in einer Matrix mit den Informationen, ob die entsprechende Funktion als Nachfolger der Zeile auftreten kann bzw. ob die Abfolge an Bedingungen geknüpft ist, dargestellt werden. Aus dieser Matrix werden anschließend Funktionsketten gebildet.

	Nachfolgeraktivitäten
Vorgängeraktivitäten	Testobjekt 1	Testobjekt 2	Testobjekt 3	Testobjekt 4
Testobjekt 1
Testobjekt 2
Testobjekt 3
Testobjekt 4

Auf diese Weise lässt sich die Abdeckung aller möglichen Wege durch ein System oder zwischen zu testenden Funktionen nachweislich dokumentieren.

Szenario Planung

Mit einer Szenario Planung wird das Ziel verfolgt, alle Schnittstellen aus fachlicher Sicht im Umfeld eines geänderten Systems durch die Hintereinanderkettung von Funktionalitäten - die in repräsentativen fachlichen Ausprägungen (Varianten) pro Systemkomponente ausgeführt werden - zu überprüfen.

Um dieses Ziel zu erreichen ist zunächst zur Einteilung des Gesamtumfangs des Testvorhabens in thematisch zusammengehörende Teilgebiete eine Beschreibung der groben Geschäftsabläufe erforderlich.

Über eine Zusammenstellung aller eigen und fremd entwickelten Komponenten (Komponentenliste) kann gewährleistet werden, dass alle von der Änderung bzw. Neuerung betroffenen Funktionen im Test berücksichtigt werden.

Für den Testablauf müssen bestimmte Komponenten als Testergebnistypen – welche zur Testauswertung genutzt werden sollen - definiert (Ergebnistypenliste) werden, um die ordnungsgemäße Verarbeitung in der Schnittstelle überprüfen zu können.

Für die Ermittlung der Kritikalität können Kriterien herangezogen werden, die auch für eine Bewertung eines Teilsystems bzw. von Testobjekten im Funktionstest genutzt werden.

Um diese Funktionsketten fachlich vollständig testen zu können, müssen auch die hierfür passenden Verarbeitungstage (Zeitachse Start vs. Ende sowie Turnus: täglich, monatlich, jährlich, ultimo, Jahresende etc.) festgelegt werden.

Die benötigten kritischen und/ oder häufig vorkommende Varianten (Variantenliste) können von Fachbereich vorgeben aber auch mittels einer Äquivalenzklassenanalyse auf steuernde Felder ermittelt werden, wobei das Ende einer Variantenbildung letztendlich von der Funktionalität bestimmt wird.

Die Varianten aller Komponenten sind für einen bestimmten Verarbeitungstag in eine sinnvolle Verarbeitungsreihenfolge zu bringen. Einzelne Teilschritte eines Geschäftsprozesses – welche auch als Szenarios bezeichnet werden – bilden die Verarbeitung an einem Verarbeitungstag ab, wobei zunächst die Online-Zeit des Verarbeitungstages und anschließend die im selben Szenario zu testenden Batch Funktionen betrachtet werden.

Zusätzlich sollte definiert werden, mit welchem Testergebnistyp das Ergebnis des Szenarios überprüft werden soll. Durch eine Zuordnung von Ergebnistypen wird für jedes Szenario festgelegt, mit welchem Ergebnistyp dieses Szenario auszuwerten ist.

Durch eine geeignete Verbindung der Szenarien (Synchronisation) auf die definierten Batch Tage entstehen die durchzuführenden Geschäftsprozesse, die mit einem Datensatz ausgeführt werden können.

Datengetriebener Test

Anwendungsgebiete für datengetriebene Tests sind parameter- oder tabellengesteuerte Systeme. Da dieses jedoch meist nur für einen Teil eines Systems möglich ist, empfiehlt es sich die Qualität der festgelegten Algorithmen durch einen Funktionstest abzusichern.

Grundsätzliche Aufgaben im datengetriebenen Test

» Analyse Datenbasis auf bestehende Voraussetzungen, Annahmen und Konsistenz

» Analyse Ist Ergebnisse und Minimierung von Fehlerlisten

» Ermitteln Grad der Auswirkungen bei einer Variation von Einflussparametern und Regeln

Die Datenbasis für den Test muss hinsichtlich der produktiven Datenqualität für die Anwendung von Regeln oder für eine tabellengesteuerte Umsetzung ausreichen. Bei Tabellen sollte zusätzlich auch insbesondere die Vollständigkeit und eine Plausibilität gegenüber den Ist-Beständen geprüft werden.

Testdaten sind Daten, die vor der Ausführung eines Tests existieren und die Ausführung des Softwaresystems oder einer Komponente im Test beeinflussen bzw. dadurch beeinflusst werden.

Des Weiteren ist die Anzahl von fehlerhaften und ungeeigneten Datensätzen zu ermitteln bzw. welchen Einfluss eine Verarbeitung von Daten mit mangelnder Datenqualität haben würde. Durch eine Erweiterung von Vorgaben kann – bei Bedarf- die Anzahl von unbrauchbaren Daten minimiert werden.

Bei datengetriebenen Tests fällt die Testfallermittlung mit der Testdatendefinition zusammen. Es muss von daher vorab festgelegt werden, mit welchen Daten die Regeln und Einflussparameter überprüft werden können.

Möglichkeiten zwecks Festlegung von Regeln und Einflussparameter auf Daten

Beschreibung von passgenau qualitativ auf die zu prüfenden Aspekte zugeschnittenen synthetische Daten (Einzelfälle), anhand derer die korrekte Verarbeitung der Funktionalität überprüft werden kann.

Einzelne Testdatensätze lassen sich synthetisch anpassen bzw. erstellen.

Beschreibung synthetischer Daten einer repräsentativen Menge und im definierten quantitativen Verhältnis zur Situation in der Produktion.

Es werden geeignete Werkzeuge benötigt, die die einzelne Testdatensätze unter Einhaltung aller benötigten Konsistenzbedingungen vervielfältigten.

Beschreibung einer Auswahl an Produktionsdaten, die für die Überprüfung von spezifischen Auswirkungen geeignet erscheint.

Für die Auswahl von Testdaten aus Produktion sind Datenschutzbestimmungen zu berücksichtigen. Einerseits dürfen personenbezogene Testdaten nicht auf reale Produktionsdaten zurückführbar sein, andererseits muss die Auswirkung einer Anonymisierung auf die Testergebnisse beurteilt werden können.