Understanding software testing a bit better, the next chapter.

In the previous chapter I was talking about the 'Test Pyramid'. The Test Pyramid is about the 'HOW' of software testing.

But there is also something to say about the 'WHAT' of software testing.

In order to speak sensible about the what of software testing, you first got to understand that programming language (code) is mostly put in a code base.
Suppose you would see that stream of 0's and 1's as a fluid.

(All programming code basically is a stream of ON/OFF switches to the processor of the computer anyway, right?)

Keeping that as a thought.
You (as a project or company) have got either one of both systems....
namely:

One is like a system where every new code is going through a process where is monitored what is put in the new release. I always see this kind of system as a perfect funnel where not 1 bit (literally) is spilled. Nothing is uncontrolled put into the new release. It is completely clear what is going into the new version.

The other version is a system where some persons have the right(s) (for some reason) to commit and push something into the new version of the build. And if you think 'that never happens', trust me I have seen it too many times! It is untested, still it ended up in production.

You can visualize it something like this:

In the beginning of a Agile Scrum Sprint it is determined what parts of that new code (the 0's and 1's... the... FLUID) is going to be tested.

The "fluid is on the radar" you could say haha.. ;)

A selection of the code that is going through the funnel is within scope, some of that fluid is going to get tested.

And you see, in order to deliver high quality software code and thus a high quality software end product. You and your company, your Agile team is in need of certain rules.

Those rules can also state or write something and clarify  if anyone is able to commit and push something in the Master, any code at all, that was not on the plan board (and part of the test effort) of the current Sprint.


Be honest about it. I have seen it too many times, yeah that can't happen. But in reality... it's things like:
Oh he? He is a really REALLY senior developer and he doesn't make any mistakes, continue with the Sprint please!


It's either a spilling funnel, or it isn't. It's one of both!
(I don't want it to make it any more complex then needed, but just remember for a moment where there also a situation where it is not clear who is developing on the team and maybe who is not. check for that blog but let's not over-complicate.)

Why is it important? Well if you do NOT take it into account, sooner or later bugs will pop-up in production that are related to the code that was spilling alongside the funnel!!

Okay now you know about the importance of that (WHAT (previous blog)). And you also know about the checking (HOW (this blog)), now it's time to indulge yourself in the..... WHEN software testing is complete....

To be more precise: WHEN is software testing done?
(after all we stated, the Sprint is DONE when software testing is DONE.
It is in the Definition Of Done. RIGHT?)

All team members committed to it!
(click here if you want to continue reading about one of the best real life oriented anecdotes regarding committing to Sprint Poker planning).

In case you're interested, gaining knowledge about
(link 1)'QA Sign Off'
(link 2)'documents'
is a very good starting point for your next step in this chain of knowledge blogs about software test processes.
I'd advice you to read until you understand why they exist. Why do people use them?

If you're at that point of understanding, then you are ready for Blog #3, which will be soon ready on one of the days of the up-coming weeks...

credits to Bing a.i. for the possibility to create such wonderful generated images!