TestBench CS is a cloud-based solution that can be quickly and easily used for an agile organization of software tests. The tool offers agile teams a cross-functional working environment. It collects and maintains test tasks, test cases, and defects but also epics and user stories. 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.

Integrate TestBench in Your Toolchain

The TestBench-API is structured in a profession-oriented way or according to the use case and displays the user interface’s visible elements. 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:

 

Epic with attached user story and test cases.

 

With the following GET call, you can request the user story from the example above.

GET ​/api​/tenants​/{tenantId}​/products​/{productId}​/requirements​/userStories​/{userStoryId}

To activate this call, you will need the ID of the client of the product and the user story. The system takes care to collect all information related to this user story. It returns the user story’s basic data, 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.

{
  "product": {
    "description": "string",
    "id": 0,
    "recentDailyQualities": [
      0
    ],
    "name": "string",
    "recentDailyOpenDefectCount": [
      0
    ],
    "qualityGoal": 0
  },
  "epic": {
    "name": "string",
    "id": 0,
    "imported": false,
    "specificationProgress": 0,
    "preconditionProgress": 0,
    "activityCountBySeverity": {
      "fire": 0,
      "flash": 0,
      "info": 0
    },
    "userStoryCount": 0,
    "testCaseCount": 0,
    "testCaseCountByStatus": {
      "ready": 0,
      "inProgress": 0,
      "passed": 0,
      "failed": 0
    }
  },
  "id": 0,
  "tbid": "string",
  "name": "string",
  "creation": {
    "time": "string",
    "userId": 0
  },
  "description": "string",
  "specificationProgress": 0,
  "preconditionProgress": 0,
  "responsibleUserIds": [
    0
  ],
  "lastUpdate": "string",
  "preconditions": [
    {
      "id": 0,
      "name": "string",
      "fulfilled": false
    }
  ],
  "activityCountBySeverity": {
    "fire": 0,
    "flash": 0,
    "info": 0
  },
  "testCaseCount": 0,
  "testCaseCountByStatus": {
    "ready": 0,
    "inProgress": 0,
    "passed": 0,
    "failed": 0
  },
  "testCases": [
    {
      "name": "string",
      "id": 0,
      "userStoryId": 0,
      "specificationProgress": 0,
      "preconditionProgress": 0,
      "activityCountBySeverity": {
        "fire": 0,
        "flash": 0,
        "info": 0
      },
      "status": "string",
      "defectCount": 0
    }
  ],
  "customFields": [
    {
      "customFieldId": 0,
      "value": "string",
      "attachments": [
        {
          "fileId": 0,
          "name": "string",
          "size": 0,
          "description": "string",
          "uploadUUID": "string"
        }
      ]
    }
  ],
  "externalId": "string",
  "externalLink": "string",
  "imported": false,
  "isTemplate": false,
  "attachments": [
    {
      "fileId": 0,
      "name": "string",
      "size": 0,
      "description": "string",
      "uploadUUID": "string"
    }
  ]
}

That facilitates 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 from 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:

POST ​/api​/tenants​/{tenantId}​/products​/{productId}​/requirements​/userStories

And then a PATCH call that sets the data as requested.

PATCH ​/api​/tenants​/{tenantId}​/products​/{productId}​/requirements​/userStories​/{userStoryId}

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 here:

API-Documentation

 

Written by Thomas Schulte

Thomas Schulte started developing software more than 30 years ago. He has a degree in business informatics and is working for imbus as Head of Development since 2017, being responsible for persons, delivery, and technics used. Before that, he was building systems for Project Management, Archiving, Helpdesk, Customer Relationship Management, and Content Management. In his opinion, software always needs to be developed with having a business value in mind.