With TestBench CS, all data related to a product are always up to date, clearly linked to each other, and always available for any user.
As user you will work with TestBench CS via a browser, on your PC or on mobile devices. In addition, TestBench CS offers an extensive and comfortable REST-API. This API enables TestBench CS to be integrated into an existing tool chain and to individually adjust the functionality or to supplement it.
The API is structured in a profession-oriented way or according to use case and displays the visible elements in the user interface. Even for programmers with little experience it is therefore easy to learn and to handle. The following example illustrates that. Represented below is a user story within an epic as well as the test cases assigned to this user story:
With the following GET call you can request the user story from the example above:
In order to activate this call, you will need the ID of the client, of the product and of the user story. The system takes care to collect all information related to this user story. It returns the basic data of the user story, the related product to be tested and the superordinate epic. Moreover, you will receive lists of test cases related to the user story and of existing activities for test cases. For fetching these data, the TestBench API only needs a single call and returns them in a JSON structure.
This clearly facilitates the access via API and leads to a more compact program code. For example, it is very easy for a programmer (e. g. in Python) to implement his own “data pumps” for data reading in and out of TestBench CS.
In contrast, this access in a classically structured API, whose calls are oriented towards the internal data model of the application, would require several successive API calls per entity: At first, fetching the user story, then a further call for fetching the test case list of this user story, followed by fetching data for the subordinate epic and finally fetching the product data.
For creating the user story and for populating with data, only two calls are necessary:
A POST call that creates and initializes a new user story:
And then a PATCH call that sets the data as requested:
Even in the documentation, the order of the API blocks reflects their usual professional order of use. The basic fundamental block that concerns the authentication is followed by blocks necessary for the system operation. Blocks that are on an equivalent technical level have several different branches if required. Therefore, the API documentation helps the developer making the usage of the API as easy as possible.
The Angular JS Single Page Application of the TestBench web client uses this API, as well. Therefore, the API is not “flange-mounted” to the TestBench system, but it is precisely the API itself that also the web client uses. Thus, the API always has the same version release as the application and supports all functions the user knows from the user interface.
You can find the complete documentation of the API at https://cloud01-eu.testbench.com/doc/api/index.html