Recently I read a very interesting message on Twitter about software testing. In it, was a picture of how you should look at software testing and how formal or informal the tests could be executed.

But when I see such pictures, sometimes I inherently think:

'Am I the only one who thinks this is a bit "shortsighted?"
This is not the complete picture. This is only a certain % of the total view of how it should be looked at.'

#1: One of the most important things to understand is: that this overview is very dynamic. It's not a solid state. 
So keep in mind you should see the picture more like this:

#2: is that: you're not testing just 1 requirement or functionality of the software.

It's important realize that requirements are connected.

It's important to realize that: requirements have hierarchical connections. Some have high priority, some have low priority. Some are connected to a small amount of others, some are connected to everything.
But they are all connected to eachother in some way.

So this is more in line with how you should see it in overall.

Example: You're testing software: It has requirements. You start with play and test the most important requirement there is. Then you start to machine check the damn thing. You discover a bug. A new requirement is written, that requirement becomes the new top priority. Could be connected to almost nothing, could be the new most important requirement...

#3: Realize that more formal or more informal testing is something very dynamic regarding to the test object!

Realize that, now we've underlined that fact. That we have left out all other aspects that determine how you should test.

So for example: is a requirement more 'security testing' related?
or
is it more 'performance testing' related?

None of that is yet mentioned in my extension (personal view) on the image 'formal - informal'.

#4: I'm not even mentioning the fact that insights in time regarding a requirement many times change... (what looks like a bug becomes a feature) (which makes it (the pyramid of connections, and how to test it) even more complicated)

In essence!!:

....
Somtimes you need to adjust the strategy of the project. (for example: more A.I.)(or, add other types of software testers for example testers with knowledge of A.I.)

Sometimes you need to adjust the strategy of the tets object.

Sometimes you need to adjust the strategy on some requirements (or bugs, I will get back to that later (in English)!).

Sometimes you need to adjust the strategy on 1 single requirement. (Realize that testing 1 requirement can cause a change of strategy for the.... [ (project, test object, etc...yes it's that complicated! ) ] 

and so forth, and so on....

So if you have a picture in your head of a test object (software code) that matches something that is static!?

It is NOT! 

A testobject is something very DYNAMIC!

(so in the future, when your "manager" asks: 'why is testing taking so long?' you show him this picture and say: 'because THIS! is what we are testing!'):

Ohw by the way, once you see a test object as something very dynamic, it also is immediately clear why it can be so difficult (time consuming) to automate everything, right?

So don't look at software testing which looks something like this:

DO look at software testing which remsembles something that looks more like this!:

When I see the applications for software testers nowadays ("doctor needed!"). And I look at what the companies are asking for the kind of skills a software tester should have. I'm sorry to say but it is not in line with what I would like to see in a software tester. Not even for 60%...

(So if you would like to scout for the real good software testers in the field, and you'd like to hear my vision about what a real software tester should have in the backpack as skills?

Send me a message and I gladly tell you all about it!)

or,
You'd like your recruuters to just have a cup of coffee (a talk) with me!? I can elucidate my vision regarding software testers and help them find the more suitable persons for the concerning applications more easily (faster and better).

Yours sincerely,
Ing. Valentijn Peters

Werk en privé zou je altijd goed gescheiden moeten houden.


Maar wie kent het gevoel niet dat je op de meest vreemde momenten de ingevingen krijgt voor een hele goede test case?

Ik bestel al jaren bij Ali-Express en ik overdrijf niet als ik zeg dat ik wel 100 producten gedurende de jaren bij de website heb besteld.

99,99% van de keren gaat dit goed. Mensen maken zich soms druk of de producten wel overkomen, maar ik heb nog niet meegemaakt dat het niet goed gaat.
Altijd wordt het wel netjes afgegeven bij de buren, of in een uitzonderlijk geval afgeleverd bij een postkantoor waar je het later kunt ophalen.

Toch was er iets bijzonders aan de bestellingen. Namelijk dat de bestelling die voor mij het meest belangrijk was, of anders gezegd -waar ik het meest op zat te wachten-. Dat was een keer een product wat kapot afgeleverd werd.

Van alle 100 producten die ik besteld had was het product waar ik juist het meeste behoefte aan had kapot.

Wat heeft dit nu met software testen te maken?

Ali-express doet eigenlijk niets fout. Zij kunnen het niet helpen dat een kapot product wordt afgeleverd. Ook kunnen zij niet weten dat dit het product is waar jij nou net het meest op zat te wachten.

En dit is nou precies waar het raakt met het ontwikkelen van software en met het opduiken van bugs. Bij de ontwikkeling van software weet je namelijk ook soms niet waar:

• De klant (eigenlijk) het meeste behoefte aan heeft. (want eigenlijk willen ze dat niet eens vermelden, soms is het niet goed nagevraagd, of weten ze het niet zelf, maar een lang verhaal kort: het is een feit dat het best wel eens niet duidelijk is).
• Je kunt van te voren nooit weten waar, in welke mate of in welke vorm de bugs zullen opduiken.
• of waar de concurrentie zich naartoe beweegt.

Er zijn veel beroepen waarbij je op vrijdagmiddag de deur achter je dicht kunt trekken en je gemakkelijk al het werk kunt loslaten...

Mijn ervaring is echter dat, als je software tester bent, je toch altijd nog wel voor een bepaald gedeelte van de (vrije)tijd met de ontwikkeling/progressie van testcases bezig bent.
Een televisieprogramma, een boek, een film of een gesprek, zelfs een blog, allemaal kunnen ze een invloed hebben op een idee voor een super goed testgeval.

Mijn advies hierin na alle jaren: zorg dat je zulke dingen vastlegt. E-mail jezelf desnoods (maar heb een eigen manier om deze ingevingen te documenteren) want zulke momenten zijn vaak het begin van een grote verbetering van de software!