Software testing terminologies explained

Publish date:

Why do we need new terms for “tests to be performed?” Are these testing terms necessary? The term “test variety” helps stakeholders distinguish them.

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:

Test variety Risk level


Who Remarks
Building block test +++ Agile developer
User story test +++ Agile tester
Interface testing ++++ Agile tester
Regression testing ++ Agile developer Part of build process
System integration ++ Test team EPIC/feature level
Acceptance team +++ Product owner
Acceptance users ++ Key users
Performance unit + Agile developer
Overall performance ++ Performance team
Maintainability code + Senior developer
Security +++ External hacker Hired every 3 months


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.

Related Posts


Unit testing: the hidden part of the test automation iceberg

Anaïs van Asselt
Date icon September 26, 2017

Unit tests verify the smallest pieces of software in isolation by simulating dependencies....