This website uses cookies. By using our website, you agree to the use of cookies.

banner blog



Insight: How testers develop an agile testing tool

Who could test a testing tool better than a software tester? That's exactly what we thought. For this reason, during the development of TestBench Cloud Services, we had people with a lot of experience in the field of testing work with a pre-release version of the tool.

The result was on the one hand excellent feedback from the workshop with our future users, which was directly included in our roadmap. On the other hand, a first field report about working with TestBench Cloud Services was written by Alon Linetzki who has been a professional developer, system analyst, system architect, test engineer, test manager, quality assurance manager and an agile coach for the last 30 years.

We hope you enjoy reading it and look forward to your feedback on TestBench Cloud Services!


Test Automation Tool Designed For Testers, By Testers...

By Alon Linetzki, QualityWize™


Many times we have a feeling that testing tools, either stand alone or integrated with other tools, were written by development experienced professionals or product managers with technical development background, and not necessarily by someone with a testing background. The features and ideas implemented are supporting testing in a way that developers are using it, not necessarily the way system test engineers would like to use that tool.

Recently (few months ago), I was invited, together with some customers and imbus personnel, to take part in a pre-launch workshop, where imbus professionals presented the tool and platform, together with some insight into the future goals they have for the tool. I figured out what the tool is trying to do (and I like it…) – a test tool, written by test experts, with lots of testing experience in many fields, starting in test process and management, into test design specifications, execution, reporting and connecting those to automated tests as a platform, all fitting an agile environment should some choose to. The tool is TestBench Cloud Services, and it is developed by imbus, a German based company, working internationally (Canada, China, Tunisia, Cosovo).

At first glance

After having ‘played’ with the tool for a while, I have found out that the process is presented in a natural and an intuitive way, for doing things (‘waring the hat’ of a test engineer). You start with creating your project, going to defining your Epics (requirements), which typically at companies are defining features of the next product increment. Each Epic will have User Stories defined for it, each having a list of defined test cases to cover it.

For each test case, one can define preconditions, which are aggregated to the user story level, and then to the Epic level, so on the Epic level one can see all the preconditions of all the test cases of all User Stories drilled down to all its test cases. This preconditions feature is a good idea, as one can see immediately what is needed to run those test cases.

The test case template is well designed, both visually and process wise. The tool reminds the tester which activities have not been done yet, from specification definition perspective, and those are flashed out in % of the template of the test case done. Test case includes the following steps for specification definition: preconditions, preparations, navigation, perform test, check result and Reset environment. In the near future, the tester will be able to change those steps, add new, remove some (as not relevant for this project), etc.

Special icons represent urgency to finish up activities (like defining preconditions or test steps or result check) with a flame (Red, urgent) and flash (Orange, critical). Also specific icons represent number of test case available, and number of stories attached to an Epic – which is helpful in a one glance view.

Epics, User Stories, and Test Cases are represented as square blocks, from left to right, suggesting a complete process of work, which is intuitive for the testers to work in this way.

Test execution starts when you push a button ‘Start Execution’, which I find nice symbolizing the start of execution and the same goes for Stop Execution. During the execution of the test, one has a high level view of the topics prepared – preconditions, preparations, etc., and a detailed view of the steps inside. That dual view of high level and detailed level helps a lot for testers to get around, and it is very intuitive to start working like that.

Defects can be opened during execution linked to a specific step of a test case, but can also be opened as General defects, on a test case level for example.

What to expect next

While on the workshop, I was speaking to Product Manager, Mr. Dierk Engelhardt, and Product Owner, Mr. Manfred Hannebauer, to find out on the future plans to grow this tool and platform, and found them to be very ambitious. Integration to major common agile tools (like JIRA and others), will happen in the near future. Also, the ability to define one own customized fields. Looking at those two together, will enable test professionals to show agile tool fields, enter data into them seeing it back on the agile tool (two-way integration), and use the whole TestBench work seamlessly with an agile tool, arranging the Epics and User Stories the same as in their agile tool, adding test information for sprints into the TestBench tool (coming from the agile tool). That is indeed very intuitive way of working, and will present an effective way of using the TestBench as a natural extension of the agile tool, using it for testing.

Another feature due implementation in the near future would be an integration to CI tools like Jenkins (at first) and others later on. CI (or CD) is an important capability for any new platform which comes out inside a test automation tool, and this strong connection to CI tools in the future will enable users to work with the platform from beginning of development, during the iterations, and into production, enabling the team to continuously monitor the quality, and deploy safely.

On top of that, the first release (29th March, 2018) was with a simple methodology and process framework, while in the near future, test automation features will be added, enabling the team to perform the whole process, including implementing TDD in an enhanced environment of the TestBench platform, and integration with other related tools in the market. This roadmap release of the platform is important message imbus is sending out, which might put it in the first row of test automation tools which provide a comprehensive feature set to meet any team’s demand and need.

On the list of ‘coming soon’ are also extensive reports and dashboards, for the test professional, project manager and product owner to measure and control the process, which include graphs to be used by managers overlooking the project progress, and trying to make decisions based on the statistics coming out of the TestBench platform.

I shall revisit the platform in a few months, to give you an update…until then – good luck with your test automation!