Testobjekt - Fachanwendung

Testobjekt - die zu testende Anwendung

Bei Unternehmensanwendungen befindet sich zu testende Anwendung meistens in einem System von verschiedenen Fach-Anwendungen.

Ein grundlegendes technisches und fachliches Verständnis der zu testenden Anwendung ist für alle Tester erforderlich. Die technischen Tester müssen ihre Programme und Automatisierung an der Anwendung technisch anbinden und gegenüber Entwicklern und Betrieblern sollten sie darlegen können, warum (fachlich) sie die jeweiligen Zugriffe, Konfigurationen und Datenbestände benötigen. Die fachlichen Tester müssen die Fachanforderung verstehen, um daraus Testfälle zu erstellen und gegenüber fachlichen Anforderern sollten sie darstellen können, welche Auswirkungen die jeweilige Anforderung im Anwendungssystem an den unterschiedlichen Stellen haben.

Die Beispielanwendung zeigt eine typische Bestandsverwaltung mit einer eigenständigen Buchhaltungsanwendung und einer eigenständigen Kundenverwaltung. Die Anträge werden über eine eigenständige Internetportal vom Kunden erhoben, die hieraus erstellten Verträge gehen über eine "Druckstrasse" raus.

Testabgrenzung

Jede Anwendung besitzt eine eigene fachliche Relevanz - oft verkörpert durch eine verantwortliche Fachabteilung - und eine eigene fachliche Anforderung und Komplexität. So wird in der Regel jeder dieser dargestellten Anwendungen für sich getestet. Der Testauftrag bezieht sich im Beispiel auf die Bestandsverwaltung.

Testpunkte

Die zu testende Anwendung hat als wesentlichen Einstiegspunkt den Webshop, über den die Kundenanträge reinkommen. Ein dadurch zu Stande gekommene Vertragsabschluss hat Auswirkungen auf die Buchhaltung, den Kundenbestand und den Kunden selbst, erkennbar an den ausgehenden Verbindungen. Jede Kommunikation zwischen Anwendungen ist ein Datenaustausch, der sich inhaltlich kontrollieren lässt - diese Auswirkung lässt sich testen! Im Test sollte jeder dieser Datenaustausche kontrolliert werden, um die Auswirkung einer Aktion komplett zu erfassen.

Weiterhin hat jede Anwendung in der Regel eine eigene Datenbank, in der Steuerungsinformationen hinterlegt sind (in Vorbereitung zu berücksichtigen) so wie Ablaufdaten festgehalten und Ergebnisse dokumentiert werden (nach dem Test zu prüfen).

Alle diese Daten beinhalten neben den fachlichen Daten auch technische Schlüssel auch betriebliche Kennzeichen - z.B. für automatische Verlängerungen und Bereinigungen. Diese betrieblichen Felder haben somit eine Fernwikung inne, die fachlich nicht auf den ersten Blick zu erkennen ist. Daher sollte man sich beim funktionalen Test nicht nur auf die fachlichen Felder beschränken, sondern die sonstigen Felder "unbekannter Weise" generell in die Auswertung einbeziehen. Hierzu bietet sich ein diversifizierender Vergleich an.

Eine Analogie: Berechtigungsmanager gehen mit den Berechtigungen zu Soft- und Hardware optimalerweise restriktiv um: sie verbieten jedem alles - wohl wissend, dass jeder Benutzer sich schnell über fehlende Berechtigungen beschwert. Wenn jemand einen Zugriff benötigt und beantragt, wird derjenige zügig freigeschaltet. Dadurch werden unberechtigte Zugriffe auf Daten und Ressourcen effektiv unterbunden. Beim Test sollte man nicht lascher sein. Wenn man alle Daten kontrolliert, kann man beim diversifizierenden Vergleich jede Auswirkung feststellen. Erklärbare und begründete regelmäßige Abweichungen kann man anschließend aus dem Vergleich herausnehmen oder zumindest entschärfen (z.B. für technische ID-Felder). So kann jede unbeabsichtigte Auswirkung im Test feststellen und entsprechend aufzeigen.

Test in verschiedenen Teststufen

Generell gilt: Man sollte den erforderlichen Test möglich leichtgewichtig halten, um so möglichst umfänglich testen zu können.

Deshalb sollten kleinteilige Abhängigkeiten möglichst in der entsprechenden Funktion getestet werden. Beispielsweise wird eine Prämienberechnung einer KFZ-Versicherung u.a. aus den Faktoren KFZ, Region und SF-Klasse berechnet, die sich auf entsprechende Risikotabellen stützen. Wenn man direkt die entsprechende Funktion nutzt (in neuerer Software-Architektur werden derartige Funktionen ggf. als Mikroservice zu Verfügung gestellt), dann kann man in akzeptabler Durchlaufzeit alle Kombinationen durchtesten und so eine umfangreiche Abdeckung erzielen. Wenn es möglich ist, können über einen Servicetest große Testreihen getestet werden. Dies kann für die verantwortlichen Fachbereiche obendrein ein hilfreiches Instrument sein. So kann man als Tester eine zusätzliche Serviceleistung anbieten, was sich bei Mittelbewilligungen einmal günstig auszahlen könnte - auch hierbei ruhig die Fernwirkung beachten;-)

Um die zu testende Bestandsanwendung für sich zu testen, reicht es, dass bis zu den Schnittstellen zu den Partnersystem getestet wird. Hierbei können Mocks die oft schwergewichtigen Partnersystem ersetzen. Das hat nebenbei den Vorteil, dass bei erforderlichen Reaktionen der Partnersysteme über einen Mocktest stabil vorbestimmt werden - z.B. Stammdaten des angefragten Kunden aus dem CRM-System.

Vor dem Abnahmetest sollte das Anwendungssystem auch einmal als Ganzes getestet werden, also mit echten Anwendungen anstelle von Mocks. Hierzu kann man die Smoketestfälle oder die wesentlichen Abnahmetestfälle durchführen. Durch die Wiederverwendung von Testfällen kaum ein Aufwand an und Projektleiter sind glücklich, wenn sie wissen, dass die Generalprobe funktioniert hat.

Nav Ansichtssuche

Navigation

Suchen

Testobjekt - die zu testende Anwendung

Testabgrenzung

Testpunkte

Test in verschiedenen Teststufen