As alluded to in “what is software testing”, there are many distinct types of testing. Using the agile testing quadrants diagram, we can visualise where and when these types of tests are applied:
Unit tests cover the smallest ‘unit’ of software – individual methods or functions, and the development team are almost always responsible for these tests of the fundamental behaviours closely coupled with the code.
Test Driven Development (TDD) is a powerful technique to help write robust code, by writing a number of failing unit tests (they fail because there is nothing implemented initially!), and then writing the code to make the tests pass.
Individual components (or groups of components which might then logically be described as an integration test) are tested in isolation with their dependencies simulated by mocks (a piece of test code that behaves like the external component in a predictable manner – for example, an API that always sends a specific response to any request). These technical tests are written by developers or testers and there are many mocking frameworks available to aid in their production.
The tests are designed in conjunction with knowledge of the internal structures of the software – referred to as clear box testing as the implementation is visible.
Functional testing and other types of testing that focus on the behaviour of the software can be designed by the software tester using specification based test analysis techniques. These are often described as a black box testing techniques – how the software is written is not considered (hence it is unseen, like the contents of a black box), it focuses on how the software should behave by reviewing the original specifications.
I consider these techniques to be part of the fundamental skills of the software tester, as they help guide thinking when breaking down a feature into a series of tests that can verify the intended behaviour of a product or service is met.
Examples of usage and user stories can be described using GWT syntax (Given, When, Then) – simple actions and expected outcomes in plain language. This is a useful communication technique to describe complex business behaviours in an accessible format.
These phrases can by refined and built into automated tests using one of a number of test frameworks designed to abstract the tests away from what becomes a domain specific scripting language. This is commonly described as BDD (Behaviour Driven Development) which can be thought of as an extension of TDD in that the behaviours guide development, although the tests are automated afterwards.
It is increasingly common for the whole team to be involved in testing, so once the tests have been defined by the tester, construction and execution can be performed by anyone in the team.
Exploratory testing and other experience based techniques rely on business domain knowledge in conjunction with general testing techniques. Moving away from scripted tests and the specification allows for experimentation and is intended to find defects based on how the software may be used by end users who are notoriously unpredictable. However, it is important to note that this is not ad-hoc unscripted testing – specific constraints are applied to guide the process.
These tests may be performed by the product team or another part of the business not directly involved in engineering, and often forms part of the evaluation and acceptance into service of a new product or feature.
Technology facing tests of the product are the realm of the specialist tester with in depth knowledge of various facets of the technology stack. The disciplines within this broad category offer a challenge to any technically minded tester who is interested in career progression in the aspects of software testing that cross into the architectural, development and operational considerations when designing, building and running a product or service, and utilise a wide range of tooling to generate and simulate traffic, whilst monitoring and capturing the behaviour of the software and associated services.
One thought on “Types of testing”
Thank you so much for this! I’m a tester and it’s this is a great way of explaining what I do to a non-tester, and in turn, refresh my own knowledge.
Thanks once again for this easy-to-read article 🙂
Comments are closed.