KIG Workflow & Rollen

Die Ablauf- und Objektstruktur im TA Studio mit dazugehörigem Rollenkonzept

Die Rollen & das KIG-Ablaufschema

Übersicht der Rollen im TA Studio

Abbildung Workflow im TA Studio

Objekt-Struktur im TA Studio

Die Projekte im TA Studio erlauben die organisatorische Gliederung der Tests entlang der Unternehmensstruktur, nach Zuständigkeiten oder Themengebieten und dienen damit der Übersichtlichkeit. Durch projektbezogene Konfigurationsparameter lassen sich zudem Projekte in unterschiedliche technische Umgebungen einpassen.

Das Szenario ist ein zentrales Konfigurationselement im TA Studio und definiert Art und Umfang einer Testdurchführung. Hier werden neben den zu testenden Modulen auch die zu verwendenden Parametersets und die Zielsysteme (SUTs) festgelegt, auf denen die Tests ausgeführt werden.

Ein „Run“ ist die Testdurchführung eines Szenarios, wobei in einem Run ein Szenario durchaus mehrfach ausgeführt werden kann. Die Durchführung wird manuell angestoßen oder über ein Schedule festgelegt. Jeder Run erzeugt ein eigenständiges Testergebnis das in der Historie nachvollziehbar bleibt.

In der Analyse werden die Testergebnisse vom Analysten bewertet, ggf. unter Zuhilfenahme der im TA Studio enthaltenen Bewertungsfunktionen. Die Ergebnisse können als Reports exportiert werden.

Eine automatische Weiterleitung der Test- bzw. Analyseergebnisse an Ticket- und Monitoring-System (z.B. Icinga) ist ebenfalls möglich. Über Jenkins u.ä. Tools können Szenarios für Regressionstests unmittelbar in den Softwareentwicklungsprozess eingebunden werden.

Tests sind in TA Studio hierarchisch gegliedert. Auf oberster Ebene erfolgt die fachliche Zuordnung zu einem „Test Subjekt“. Dahinter verbirgt sich in der Anwendungsentwicklung oder dem Workplace-Management i.d.R. eine bestimmte Version einer Applikation. Ein Test Subjekt kann aber auch ein applikationsübergreifender Test eines Business-Prozesses sein. Statistiken und Reports können anhand des Test Subjektes gegliedert, gefiltert und kumuliert werden.

Test Module sind eigenständig ausführbare Tests und definieren den logischen Ablauf der darin enthaltenen Testcases.

Durch Modul Parameter sind die zugehörigen Elemente so gehalten, dass die Test Module ohne weitere Anpassung z.B. in verschiedenen Testumgebungen lauffähig sind, bzw. auf neue Versionen des zugeh. Test Subjekts leicht angepasst werden können.

Die Testcases beinhalten die detaillierte Testbeschreibung und korrespondieren zu den einzelnen Testschritten in den Test Skripten. Diese steuern die eigentliche Testdurchführung auf dem Zielsystem, der SUT.

Durch die Parametrisierung der Testcases bzw. –Skripte wird deren Wartbarkeit und Wiederverwendbarkeit erheblich verbessert. Durch Verwendung mehrere Testcase Parametersets können mehrere Testfälle mit dem gleichen Skript abgearbeitet werden.

KIG-Analyst und -Engineer

Workflow eines KIG-Analysten

Der Analyst legt ein Test Scenario im Projekt an. Hierbei legt er die Module fest, die Parameter Sets und die SUTs. Im Anschluss kann er auswählen ober er den Testrun sofort starten lässt oder in z.B. über Nacht oder am Wochenende durchlaufen lässt. Am Ende jedes Testruns kann er sich dann die Ergebnisse bis ins Detail anschauen.

Workflow eines KIG-Engineer (Development)

Implementieren eines Tests

Ein Projekt wird erstellt oder bearbeitet. Der Engineer erstellt den Subject Test, erstellt das Modul und die Modul Parameter, beschreibt nun den Script Namen, entwickelt das Modul Script, erstellt den Testcase, beschreibt den Script Namen, entwickelt das Testcase Script, erstellt die Parametersets und die Parameter.

Zum Seitenanfang