Testkonzept - Teststufe Funktionstest

Der Funktionstest evaluiert, ob die implementierten Funktionen die ihnen zugewiesenen Aufgaben gemäß den fachlichen Spezifikationen und Kundenanforderungen erfüllen. Es wird dabei nicht nur geprüft, ob das System das tut, was es soll, sondern auch, ob es nichts tut, was es nicht tun sollte. Dazu gehört die Prüfung auf korrekte Verarbeitung von korrekten Eingaben sowie die angemessene Reaktion auf fehlerhafte oder unerwartete Eingaben.

Die Testfälle für den Funktionstest werden typischerweise aus den funktionalen Spezifikationen abgeleitet und können sowohl manuell als auch automatisiert durchgeführt werden. Der Umfang der Testabdeckung wird durch den Überdeckungsgrad bestimmt, der angibt, wie vollständig die funktionalen Anforderungen durch die Tests abgedeckt werden.

In der Praxis beinhaltet der Funktionstest nicht nur das Ausführen der definierten Testfälle, sondern auch die gründliche Dokumentation der Testergebnisse. Diese Dokumentation ist entscheidend für die nachfolgende Analyse der Testergebnisse und für die Entscheidungsfindung bezüglich der Systemfreigabe. Sie hilft dabei, die Transparenz des Testprozesses zu gewährleisten und bietet eine solide Grundlage für die Abnahmeentscheidung durch die Fachbereiche.

Unter einen Negativtest versteht man einen funktionalen Testfall mit Eingabewerten, die laut Spezifikation des Testobjekts unzulässig sind. Das Testobjekt sollte robust reagieren, in dem es die Werte abweist und eine geeignete Ausnahmebehandlung durchführt.

Der Funktionstest ist eine zentrale Phase im Testprozess von Software, die nach den Komponenten- und Integrationstests stattfindet. In dieser Phase wird die Gesamtfunktionalität des Systems unter Betrachtung aller relevanten Bankprozesse überprüft. Der Test basiert auf den funktionalen Designs oder Fachkonzepten, die spezifische Anforderungen und erwartete Funktionalitäten der Anwendung beschreiben. Diese Dokumente dienen als Grundlage für die Erstellung der Testfälle.

1. Testfalldefinition
   Vor dem Beginn der Tests werden spezifische Testfälle definiert, die sich aus den funktionalen Spezifikationen ableiten. Diese Testfälle bilden die erwarteten Szenarien ab, die das System unterstützen sollte.
   
   
2. End-to-End-Tests
   Der Funktionstest umfasst die Durchführung von End-to-End-Tests, bei denen alle Komponenten und ihre Schnittstellen innerhalb einer kompletten Prozesskette geprüft werden. Dabei wird besonders darauf geachtet, dass die Anwendungen und Systeme über verschiedene Fachbereiche hinweg korrekt zusammenarbeiten.
   
   
3. Evaluierung
   Überprüft wird nicht nur, ob das System die erwarteten Funktionen ausführt, sondern auch, ob es auf fehlerhafte Eingaben angemessen reagiert und keine unerwünschten Funktionen ausführt.

Die Ergebnisse des Funktionstests werden detailliert dokumentiert, um eine gründliche Analyse und Bewertung der Systemfunktionalität zu ermöglichen. Diese Dokumentation unterstützt die Entscheidung über die Freigabe des Systems und die Vorbereitung auf den UAT.

Der Funktionstest, oft auch als User Acceptance Test (UAT) bezeichnet, überprüft das System als Ganzes – sowohl aus technischer als auch aus fachlicher Sicht. Die Zielsetzung ist, zu bestätigen, dass die entwickelte Software oder Anwendung die definierten Anforderungen erfüllt und für die Inbetriebnahme bereit ist. Der Fokus liegt auf der Verifizierung der End-to-End-Prozesse und der Gewährleistung, dass die Software für den tatsächlichen Einsatz geeignet ist.

• Realitätsnahe Testumgebung
  Der Test sollte in einer Umgebung durchgeführt werden, die der Produktionsumgebung ähnelt.
  
  
• Umfassende Testfälle
  Sie decken alle möglichen Szenarien ab, einschließlich Randbedingungen und Ausnahmefälle.
  
  
• Nutzereinbindung
  Der Test wird oft von den tatsächlichen Nutzern oder Vertretern der Fachabteilungen durchgeführt.
  
  
• Regressionstests
  Nach jeder Änderung wird überprüft, ob die Funktionalität erhalten bleibt oder ob neue Fehler eingeführt wurden.
  
  
• Dokumentation der Ergebnisse
  Alle Testergebnisse müssen genau dokumentiert werden, um eine nachvollziehbare Entscheidung für die Abnahme zu ermöglichen.

Der Funktionstest soll den Nachweis erbringen, dass die fachlichen Anforderungen

an die Anwendung korrekt umgesetzt wurden. Der Funktionstest beinhaltet das

Testen einzelner Funktionen. Eine Funktion ist eine fachlich abgeschlossene Aufgabe, die selbständig durch den Fachbereich (Online) bzw. automatisch (Batch) ausgeführt werden kann. Dabei ist es unerheblich wie die Funktionen DV-technisch realisiert sind.

• Fachliche Korrektheit
  Überprüfen, ob die Software alle fachlichen Anforderungen und Spezifikationen erfüllt.
  
  
• Benutzerakzeptanz
  Sicherstellen, dass die Software aus Benutzersicht akzeptabel und nutzbar ist.
  
  
• Vollständige Abdeckung
  Testfälle müssen alle Funktionen und Prozesse abdecken, um sicherzustellen, dass nichts übersehen wird.
  
  
• End-to-End-Validierung
  Das Zusammenspiel zwischen allen Komponenten und Schnittstellen muss reibungslos funktionieren.
  
  
• Benutzerfreundlichkeit
  Bewertung der Benutzerführung und der Benutzeroberfläche, um eine intuitive Bedienung sicherzustellen.
  
  
• Datenintegrität
  Korrekte Verarbeitung und Sicherheit der Daten über verschiedene Systemteile hinweg.

Stufen 3 bis 6: hier werden die Testfälle auf Feldebene mit den Methoden der Äquivalenzklassenanalyse gebildet, jedoch wird das Verfahren eingeschränkt, so dass in Stufe 3 so viele Testfälle gebildet werden, dass zumindest jedes Pflichtfeld aus dem zulässigen Wertebereich abgedeckt wird. In Stufe 4 wird der Umfang der zu betrachtenden Felder um die Kannfelder ergänzt, d.h. über die Testfälle wird sicher gestellt, dass die Positivverarbeitung der Funktionalität zumindest über jedes Feld mindestens einmal mit einem positiven Wert ausgeführt wurde.

Stufen 5 und 6 erweitern den Abdeckungsumfang der Äquivalenzklassenanalyse um Fehlertestfälle, d.h. es wird sichergestellt, dass Pflichtfeld- und Kannfeldprüfungen auf Wertebereichsebene korrekt funktionieren.

Bei der Dokumentation der Testfälle muss die eindeutige Nachvollziehbarkeit und Wiederholbarkeit der Testfälle gewährleistet sein.

Es gibt 5 Methoden in der Testdatendefinition. Die unterste Stufe der Ad-hoc Testdatendefinition bildet die einfachste Form ab und folgt keiner Systematik. Willkürlich werden Werte entsprechend den vorgegebenen Testfällen belegt.

Jede höhere Stufe der Skalierung ist eine Form der systematischen Testdatendefinition. Auch hier gilt wieder, dass entsprechend der Skalierungsstufen die Methoden aufeinander aufbauen, sodass die Sicherheit im Test auch während der Testdurchführung erhöht (oder verringert) werden kann.

Minimalanforderung ist die Abdeckung von Standardwerten (jede weitere Stufe ist als Ergänzung zu sehen). Nächsthöhere Sicherheit bietet die zusätzliche Abdeckung von Grenzwerten, also den Ober- und Untergrenzen eines Feldes, bzw. einer Äquivalenzklasse. Ergänzend dazu kann der Testfall zusätzlich mit Mittelwerten und in der obersten Methode mit sog. Critical Dates belegt werden.

Es gilt: Je höher die Skalierungsstufe, umso elaborierter die Methode und damit die Sicherheit. Bei der Bildung von Ad-hoc- Testdaten ist der Sicherheitsfaktor nicht bewertbar, da er abhängig ist vom Fachwissen und Einfallsreichtum des Testers.

Es wird empfohlen für Teilprojekte mit der Kritikalität hoch die Methode 2, für Testobjekte mit geringer Kritikalität, für Testobjekte mit mittlerer Kritikalität die Methode 3 und für Testobjekte mit hoher Kritikalität die Methode 5 zu wählen.

Für Teilprojekte mit der Kritikalität mittel wird für gering bis mittel-kritische Testobjekte die Abdeckung von Standardwerten empfohlen, für kritische Testobjekte die Abdeckung von Mittelwerten.

In Teilprojekten mit geringer Kritikalität gilt als Empfehlung für Testobjekte mit hoher Kritikalität die Abdeckung von Grenzwerten, für gering bis mittel-kritische Testobjekte ist die ad-hoc Testdatendefinition normalerweise ausreichend.

Für die Testausführung müssen Techniken angewandt werden, die die Testausführung nachvollziehbar, was eine gesetzliche Grundanforderung ist, Re-Test fähig (Bestands- und Bewegungsdaten müssen reproduzierbar sein) und wenn möglich automatisiert ablaufen lassen.

Für die Testausführung gibt es Hilfsmittel für die Testablaufsteuerung, d.h. der gesamte Testablauf kann durch ein Tool unterstützt in einem Schritt ablaufen (z.B. Laden der Datenbank, Ausführung einer Batch-Kette, Sichern der Ergebnisse und Durchführen von Vergleichen). Bei der Ausführung von Online-Funktionalitäten können Capture-/Replay-Tools unterstützen.

Die Effizienz der Testausführung kann durch verschiedene Schritte in Richtung Automatisierung erhöht werden. Das beginnt mit der automatisierten Bereitstellung von Testdaten für die manuelle Testausführung und geht bis zu einer Vollautomatisierung aller Aktivitäten in der Testdurchführung.

Für die Kontrolle und den Vergleich der Testergebnisse ist eine Technik anzuwenden, die bei der manuellen Auswertung bzw. der automatisierten Auswertung unterstützen.

Die Testfallermittlung kann begonnen werden, sobald abgenommene Fachkonzepte vorliegen. Für die Testdatendefinition sollten die DV-Konzepte erstellt und abgenommen sein.

Für den Beginn der Testdurchführung müssen die Testobjekte erfolgreich durch den Schnittstellentest gelaufen sein, d.h. die definierten Testende Kriterien wurden nachgewiesen.

Die Testende Kriterien ergeben sich im Wesentlichen durch die Risikoanalyse und die daraus folgend gewählten Testmethoden.

Es sollte noch festgelegt werden, was mit erfolgreich gemeint ist. Bei größeren Projekten kann es schwer werden, wenn erfolgreich = keine offenen Fehler bedeutet. Daher sollte, unter Berücksichtigung der Fehlergewichtung, ein Schwellwert festgelegt werden, wann ein Test erfolgreich absolviert wurde.

Diese Festlegung ist jedoch auch von der jeweiligen Kritikalität des Projektes und den Qualitätsanforderungen abhängig