Back in 2016, Sogeti launched a new methodology named TMap HD for software testing which featured test varieties and the approach to testing. This methodology was an attempt to shift from a traditionally fixed formula to an innovative, building-block approach. In this blog, I will take you through the different testing terms and discuss whether test varieties are likely to exist going forward.

Why do we need new terms for ‘tests to be performed’? Are these testing terms necessary? The answer is yes. Non-testers often don’t understand testing terminology.  These terms are useful when testers explain the different test levels and test types to non-testers. A test manager has to structure the testing activities while organizing testing. The term “test variety” helps stakeholders distinguish between testing tasks.

There are four commonly used levels of testing:

• unit or component testing
• integration testing
• system testing
• acceptance testing.

The term “test level” defines who is doing a test. For example, unit testing is done by a developer; system testing is done by the tester, and acceptance testing is done by the client.

“Test types” define what to test or, in simple terms, the objective of a certain level of the system. They focus on a particular objective, for example, a function to be performed by the component or a system, its performance, or its regression.

Test varieties don’t make much difference to agile, DevOps, or traditional practices.  The major focus revolves around what fits within the sprint boundaries and what the agile team is supposed to test. Tests that don’t fit within the sprint boundaries can be performed by specialists. Hence, a tester can use the test varieties and forget about the test levels and test types.

A simple test strategy looks like this:

You can use any term as long as your environment knows what it means. We could call it “tests to be performed,” and there’s no new term needed.