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.

Veel mensen weten dat niet eens van zichzelf.

Geef je voorkeur aan een chaos of een gestructureerde omgeving?

Weet je hoe het is op het huidige project waar de tester zit, of waar de tester naartoe gaat?

Het zijn zaken waar sales personen van een detacheerder niet altijd rekening mee houden. (ze zijn allang blij als je soms überhaupt op een project kunt starten, logisch).

Toch heeft het veel effect of iemand het ergens naar de zin kan krijgen (of heeft) of niet.

Ook zijn er vaak bewegingen, als een persoon dat van structuur om zich heen houdt in een organisatie zit dat van Chaos naar meer Structure beweegt... dan zou hij in principe naar de toekomst toe het theoretisch meer naar de zin kunnen krijgen. (andersom geldt ook).

Bekijk eens het Johari venster:
​

Sommige mensen hebben graag structuur om zich heen, sommige mensen brengen graag de structuur aan, of beide... etc... het maakt in elk geval verschil.

​Ik denk dat het geen kwaad kan om het eens bij jezelf te rade te gaan.

"Bij het beschouwen van het gehele proces van softwaretesten zijn er enkele cruciale momenten, waaronder... 't begin en 't end. Je kunt deze momenten op verschillende manieren benaderen: eenvoudig en beknopt, of juist uiterst gedetailleerd. Een gedetailleerde benadering heeft een vergelijkbaar effect zoals geïllustreerd wordt in het volgende TikTok-filmpje:
https://vm.tiktok.com/ZGJK9JXSd/

Laten we eens kijken naar het startpunt: Overweeg je bijvoorbeeld een Preliminary Risk Assessment (PRA)? De keuze om al dan niet een PRA uit te voeren, kan worden beschouwd als een diepgaandere analyse, zoals gedemonstreerd wordt in het TikTok-filmpje.

Hetzelfde geldt voor het 'beëindigen van het testen'. Je kunt het op een eenvoudige manier bekijken, maar je kunt er ook dieper op ingaan."​

"Achter de vraag 'wanneer moeten we stoppen met testen?' schuilt een complexe wereld. Een uitgebreide blog die deze kwestie behandelt, is te vinden op:  
https://developsense.com/blog/2009/09/when-do-we-stop-test

Het begrip wordt duidelijk wanneer je het principe begrijpt: je kunt het oppervlakkig bekijken, maar ook diep inzoomen.

De volgende stap is het toepassen van de schaal waarop je kijkt. Met 'schaal' bedoelen we het niveau waarop je het starten en stoppen van testen kunt overwegen. Dit kan op het overkoepelende 'Project Niveau' zijn, bijvoorbeeld alle apparaten, wet- en regelgeving, of op een zeer holistisch niveau. Je kunt hetzelfde principe toepassen op een module, functie, backlog-item, een enkele vereiste of een individueel testgeval.

De schaal waarop je kijkt kan variëren, net zoals de mate van detail waarmee je kijkt. Je kunt bijvoorbeeld diep inzoomen op een specifiek element of juist oppervlakkig 'het geheel' bekijken.

Een laag is dat je het aanvangen en of stoppen van testen kunt bekijken op overkoepelend hoog  'Project Niveau'
(bijvoorbeeld alle devices, of alle wet- en regelgeving of... enorm holistisch)
Maar ook op een lager niveau
Hetzelfde principe gaat op voor een module. (of feature)
Hetzelfde gaat op voor een backlog item...
Hetzelfde gaat op voor slechts 1 requirement of slechts 1 testgeval.

De laag waarop je kijkt kan dus variëren (bijvoorbeeld een bodemlaag van de grond), de gedetailleerdheid waarmee je kijkt kan dus variëren (bijvoorbeeld dan ver ingezoomd op één specifiek element van die bodemlaag, of juist oppervlakkig 'alles wat daar zit'.).
​
Tot nu toe begrijpelijk?

Laten we het ingewikkelder maken. De wereld van software testen is complexer dan dit.

Neem bijvoorbeeld een backlog-item. We ontwikkelen een feature en testen deze op verschillende lagen, zoals de unit-testlaag, de API-laag, de gebruikersinterface (E2E) en zelfs met het blote oog (functionele test). Stel dat we een bug vinden, laten we zeggen, op de gebruikersinterface-laag.

Dan wordt er een bug gevonden met één van deze manieren van testen (praktijk is natuurlijk meerdere bugs op meerdere testlagen van de piramide, voor het gemak laten we dat even hier nu achterwege) mag je zelf kiezen op welke laag van de piramide, laten we zeggen op de UserInterface laag.

Herinner je je het voorbeeld van de mate van detail bekijken? Je zou deze bug kunnen classificeren als onbelangrijk, met een lage prioriteit, vanwege de lage kans op fouten en lage ernst. Tijd verstrijkt en dan ontdek je dat deze bug toch een groot effect heeft op een hoger niveau, zoals het onvermogen om af te drukken.

Dit opent deuren naar andere processen, want in softwaretesten geldt vaak: 'verander je hier iets, dan heeft dat elders impact'.
Niet alleen dat, één bug kan een specifieke testaanpak vereisen. Daarom zijn er talloze softwaretesttechnieken beschikbaar.
Om softwaretesten goed te begrijpen, is diepgaande theoretische kennis nodig, en moet je verschillende aspecten en niveaus van diepgang kunnen benaderen. Dit vereist de vaardigheid om zowel te simplificeren als een holistische kijk te hanteren en het grotere geheel te overzien.
In- en uitzoomen, dat is de sleutel!"

3-11-2023 aanvulling.

Bij het teruglezen van de blog was ik er in zijn algeheel content mee. Toch wil ik er nog een extra aanvulling op doen bij nader inzien.

Wat je vaak ziet in het testen (en dus het bepalen van starten en stoppen) is dat requirements in een soort van hiërarchische structuur aan elkaar hangen als je ze uittekent of opstelt. 
​Zie onderstaande plaatje:

Echter, dat is geen garantie voor het juist in scope hebben van de (daadwerkelijke) prioriteiten. 
Daarmee bedoel ik dat soms een requirement als zeer onbelangrijk word bestempeld. Naarmate tijd verstrijkt en (al dan niet door testen) meer info wordt ingewonnen, blijkt toch dat dat ene item een heel stuk belangrijker is dan het in eerste instantie leek. 
Niet altijd wordt de prioriteit in het item dan goed bijgehouden, resulterend ook niet goed in scope gehouden in het SCRUM proces. 

Kortom, de begripsvorming dat het starten kan fluctueren ("zie zoom-in text en video's") en het stoppen kan fluctueren ("zie zoom-out tekst en video's") wordt nog eens bemoeilijkt doordat de scope (wat testen we) bemoeilijkt wordt doordat items omhoog en omlaag schieten qua prioriteiten.

Had ik al gezegd dat software testen best moeilijk is? Ik benadruk het nog maar eens opnieuw...
software testen is moeilijk! (of zoom ik nu misschien wat te ver uit? ;) )