As a test professional I am often asked about how we can shift testing left. What this essentially means is that we are wanting to start testing earlier. As any good IT professional will tell you, the earlier you find an issue, the cheaper it is to fix it — and this is something test is asked to champion, both as a delivery of the test function and as the quality gatekeeper.
So how early is early? Well, if we want to start at inception, then we move into the realms of test-driven development, or TDD as it is often known. This is where you write a test, run it, see where it fails, and then write new code so that the test passes.
I appreciate that is a very simplistic definition, but it is important to recognise this as a valid approach to test, as it encourages developers to write to the requirements. And that nicely segues into what I want to talk about, which is requirements.
Requirements are the foundations from which software projects are built. A requirement, in its simplest form, is a description of a software system to be developed.
Anyone who has worked on a project that quietly ran off the rails will recognise the pattern. A lack of communication or governance are usually the two most common causes for a project to lose its way. However, another way a project can be delayed is down to poorly written requirements — where the instructions are unclear and mistakes can be made. There can also be gaps in the requirements where the author hasn't considered the consequences of some of their design decisions.
Four characteristics of a good requirement
For me, requirements should have four clear characteristics. They should be:
- Unambiguous — there should be a clear instruction.
- Testable — a requirement should have an expected outcome which can be validated.
- Logical — the requirement should make sense.
- No solutioning — a requirement is a set of instructions; you shouldn't be trying to fix things as you go along.
From a test perspective, we encounter requirements at the static stage of testing. At its most simplistic level, it is a case of reading a requirement and validating that there is a testable outcome from it.
Why would we want to do this? Well, it ensures that the requirements meet the four criteria I mentioned earlier. It shows the software solution under construction has a clear set of criteria it is building against, which removes ambiguity. It can also reveal gaps in the requirements, where additional requirements may need to be written or existing requirements updated.