Disclaimer: I will post this disclaimer at the top of every blog or article that I produce. These are my opinions, developed over my career, they are in no way any kind of gospel and I am more than happy for others to have different opinions. That is what the community is for, to generate debate and discussion.

The quality challenge

Lots of us will know this already, but let’s boil it down to the basic premise of what testing is all about, what quality engineering is all about. It’s all about Validating and Verifying that something does what it is supposed to do.

It’s all about risk mitigation, understanding how a system behaves and reporting on that knowledge of how the system actually behaves. You will notice I didn’t say ‘understanding how a system behaves and assessing that it is correct’ in my opinion that is not the role of the quality function unless that is clearly stated by those responsible for designing the systems behaviour.

So quality can be assessed against well defined criteria. In a traditional waterfall project this would take the form of functional and non-functional requirements written by Business Analysts in conjunction with the end users. And in iterative delivery methods this would take the form of User Stories, Product Backlog Items or Features, developed under the watchful eye of (or ideally directly by) the Product Owner. The quality output can only be as good as its input.....

‍

Rubbish In > Rubbish Out

‍

I am afraid that if the definition of how the system should behave is poorly constructed or ill thought through, the resulting testing will not assess all elements of the system that should be assessed, or will not be able to make a rapid assessment of whether the system is meeting expectations without lengthy discussion. In reality, the end product will be riddled with holes and what is delivered risks being of very poor quality.

Slide to the left

In my experience quality focussed professionals are well placed to mitigate this scenario and in the last few years a ‘buzz’ phrase of ‘Shift Left’ has been adopted by many. A large number of consultants have made a large amount of money from this phrase when in reality it’s a very straightforward premise. All it means is test as early as possible.

In the scenario above this could take the form of getting involved in the development of requirements by asking questions and challenging assumptions to drive out more detail. In the ISTQB syllabus this is referred to as static testing. We’ll explore ‘Shifting Left’ in more detail in subsequent posts within the community.

The test scope sized elephant in the room

We also need to be honest with ourselves and others. Not everything can be tested, if we attempt to test everything the test phase will never end - those that state, "How did this get missed in testing" post deployment have a distinct mis-understanding of the the SDLC. Statements like this suggest that only the test/quality function are responsible for quality. As highlighted above quality runs through all projects like the writing in a stick of rock.

A risky business

Software testing is a risk based activity, which is underpinned by fully understood business needs, either in the form of Requirements, User Stories, Features or backlog items. I often assess risk through a combination of business risk and technical risk in order to prioritise.

We will explore these subjects and more within the community.

Come and join us!

‍

‍