View on Prezi itself for FULL view... (better)

After a hiatus of two months not writing any blogs, I thougth it was high time for a fresh entry on this website.
Software testing is a critical (thinking) profession and can sometimes be frustrating. It's challenging to jump in the middle without experiencing the origin and lacking solid background knowledge.
One glaring issue that can arise in the process is the lack of clear requirements for an information system, making testing extremely difficult. In recent months, I coined a new term: ACCREQ management.
In ACCREQ, 'ACC' stands for Acceptance Criteria and 'REQ' for Requirements.
What we often observe in many TEST tools is a lack of proper attention to this aspect.
Take two simple examples: Azure DevOps and Katalon Studio.
Let's consider Azure DevOps, where we see a textbox for entering Acceptance Criteria.
What happens in practice? Acceptance Criteria for the actual software and various other project aspects are haphazardly mixed together. There isn't a quick way to categorize them effectively into sections.
Moreover, they aren't automatically numbered but appear as bullet points.
So, who will manage these Acceptance Criteria? Who will track them in a system? They often remain only within the Product Backlog Item (PBI), intertwined with all other requirements like 'server availability,' 'API connection,' or even unrelated items not pertaining to the software's requirements (programming code section).

I find it very unfortunate that in Azure Devops, there's no capability for creating sections (I'd like to drag and drop them into sections), no option for numbering; if you wish to implement (store and link) these, you'll need to do it manually in a Notepad-like mode.
Now, let's delve more into testing tools:

Katalon is a really great tool, but if you look closely, there is NOT a column labeled 'Requirement(s)' or a column named 'Acceptance Criteria.'
So, even if you have an administrative system (for ACCREQ) set-up in Azure for describing Acceptance Criteria and Requirements, there is still NO link or column for them in Katalon.
This means that when you create an automated test that checks or verifies something, what exactly is that "something"? You're left to decipher it from the testcase title and testcase steps in Katalon.
​There's no "way back"...
If a test fails in the year 2030... you won't be able to see in Katalon which Requirement or Acceptance Criteria it corresponds to. You could manually type it in the Description column, and theoretically, if you had meticulously documented all the Requirements and Acceptance Criteria of the software in a computer system, you could read it there.
However, reality is often much more complex. In practice, what happens is that in Sprint 3, an Acceptance Criteria from Sprint 1 might change, and it's then added to the current PBI. Or worse: it's added in the comments of a Story. Or even worse: it's not described at all but simply adjusted in the code and pushed to the Master.
In short, there is NO "Accreq administrative management".
Based on my practical experience, if a company didn't have good requirement management from the outset, it will never be properly done retroactively. It becomes very difficult to clarify things. Whether something works well or not... that becomes a very tricky situation.

The ACCREQ administration?  ​This is how it should look like!!

To my opinion, in the Azure DevOps stories, you should be able to find all R1 through R5. Updates are made in both the Requirement management tool and in Azure DevOps (not in the Descriptions of a Story, or what I have seen a lot: even in the 'comments' sections... pfffff....).
To my opinion: in the TEST TOOL, you should also be able to find R1 through "R5.3"!! Linked together.
​
Have you arranged it to THAT level of detail!?
If so, I would say: proceed... only then continue software development.

Otherwise: ask yourself:
WHAT is the tool testing, or even better : what is it checking then?

It should look more like this:

And the software tool test is doing the administration between them is the glue that holds everything together!! What tool is that? I think it is a BIG cap in the market.

[  ] Azure and alike have things to do.
[  ] Katalon and alike have things to do.
[  ] The ICT community is in need of a Requirements and Acceptance Criteria administration tool that glue's/links/connects everything together! We are in need of such a tool.
But that's just my humble opinion.

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!