KIG Workflow & Roles

TA Studio process and object structure with associated role concepts

Roles & KIG Workflow

Overview of Roles in TA Studio

Mapping Workflow in TA Studio

Object Structure in TA Studio

Projects in TA Studio allow tests to be structured organizationally in line with the company structure and according to responsibilities or subject areas, thus providing a clear overview. Project-related configuration parameters can also be used to adapt projects to different technical environments.

The scenario is a central configuration element in TA Studio and defines the type and scope of a test execution. In addition to the modules to be tested, the parameter sets to be used and the target systems (SUTs) on which the tests are executed are defined here.

A "run" is the test execution of a scenario, whereby a scenario can be executed more than once in a run. Execution is triggered manually or defined using a schedule. Each run generates an independent test result that remains traceable in the history.

In the analysis, the test results are evaluated by the analyst, if necessary using the evaluation functions contained in TA Studio. The results can be exported as reports.

Automatic forwarding of the test or analysis results to the ticket and monitoring system (e.g. Icinga) is also possible. Jenkins or similar tools can be used to integrate scenarios for regression tests directly into the software development process.

Tests are structured hierarchically in TA Studio. Business assignment to a "test subject" takes place at the highest level. In application development or workplace management, this is usually a specific version of an application. A test subject can also be a cross-application test of a business process. Statistics and reports can be structured, filtered, and aggregted based on the test subject.

Test modules are independently executable tests and define the logical sequence of the test cases contained in them.

Module parameters hold the associated elements in such a way that the test modules can run in different test environments, for example, without further adaptation, or can be easily adapted to new versions of the associated test subject.

Test cases contain the detailed test description and correspond to the individual test steps in the test scripts. These control the actual test execution on the target system, the SUT.

The parameterization of test cases and scripts considerably improves their maintainability and reusability. By using several test case parameter sets, several test cases can be processed with the same script.

KIG Analyst and Engineer

Workflow of a KIG Analyst

The Analyst creates a test scenario in the project, defining the modules, the parameter sets and the SUTs. He can then select whether to start the test run immediately or run it overnight or on weekends, for example. He can then view the results in detail at the end of each test run.

Workflow of a KIG Engineer (Development)

Implementing a test

A project is either created or edited. The Engineer creates the subject test, creates the module and the module parameters, describes the script name, develops the module script, creates the test case, then describes the script name, develops the test case script and creates the parameter sets and the parameters.

Jump to top