In een IT omgeving kun je soms heel erg merken dat er stuwende krachten aan het werk zijn.
Een deel van de mensen wil ad-hoc en ongestructureerd werken, nauwelijks aan planning doen.
Anderen willen graag systematiek en structuur.

Wat je merkt is dat beide kampen (soms sterk) voor hun voorkeur opkomen. Soms groeperen mensen ook met de voorkeursstijl is wat je dan merkt.

Met een grote groep van ontwikkelaars die niet van structuur houden -of een lead-ontwikkelaar in het midden die de toon zet-, kan het dan knap lastig zijn om daar als 1 persoon als software tester tegenover te staan.
De software tester krijgt dan weinig voor elkaar omdat de tegenwerking te groot is.

Het is in zulke of soortgelijke situaties heel belangrijk om te beseffen dat een onbalans grote gevolgen kan hebben op verschillende vlakken (Bedrijfsbreed, IT of testproces)
Het is dan wijs om "de grootste schreeuwers" niet al te veel hun zin te laten krijgen.

Wanneer teams aan weerszijden een evengrote kans krijgen, zal de rust en synergie snel wederkeren.

Helaas geldt het omgekeerde ook. Bij een aanhoudende onbalans zullen bepaalde krachten binnen de organisatie geen schijn van kans maken en kunnen mega-chaos veroorzaken.
Dan is het een kwestie van zachte heelmeesters maken diepe wonden en moet je kordaat optreden. Het ad-hoc en ongestructureerd werken zal wellicht voor wat voordeeltjes op de korte termijn zorgen. De vraag is dan nog maar hoe lang van deze voordeeltjes zal worden genoten.

Er zijn tal van voorbeelden waaruit dat blijkt:
https://nos.nl/artikel/2323426-ict-project-defensie-stevent-af-op-mislukking.html

Structurele, gefundeerde, en goed uitgedachte oplossingen en manieren van werken, planning, systematiek en structuur zullen uiteindelijk dan de uitkomsten kunnen bieden.

Sterker nog, in een omgeving waar jarenlang een onbalans van +4 was in aantal ontwikkelaars vs aantal testers... zou wel eens een -4 periode nodig kunnen zijn om weer terug te kunnen komen in het midden.

Dat kan gelden voor Belastingdiensten, dat kan gelden voor het voorkomen van losgelden in BitCoin$ aan criminelen, maar ook voor het van de grond krijgen van een ICT project bij defensie.

Dus merk je de stuwende krachten van de andere groep?
Besef je dan dat je wel eens -4 zou moeten terug geven om alleen nog maar in het midden uit te komen. Wil je zelfs vooruitgang? Bedenk dan hoe groot je tegenkracht moet zijn.

'Dus iemand zegt: '4 software testers tegenover 1 ontwikkelaar is belachelijk?

Denk aan deze blog en zeg:

You can't stack another deck...

...when your pillars are not okay.

To my opinion, and I admit it's a bit of my vision, there are a couple of pillars in software testing. One of the pillars is unit testing, the other one is test automation, another one is what I call UAT and the last one is "the process".

All (at least) 4 have to be in place to proceed to another level of software testing within a company. You don't want a wobbly deck, right?

Okay so let's zoom into those 4 pillars.
Many times the question arises are those test techniques that TMap, ISTQB, ISEB and others school really needed?
Well yes and no.
To understand this we'll have to take a closer look on where they can be applied.
Let's just say -for the convenience- , that there are 9 test techniques and one of them is the decision table
-
The technique the decision table can be applied on the pillar unit testing so for instance you build a piece of software code and the verify if all the correct behavior represents as desired you test all the cases.

So at this point you're testing a flow and use a test technique to verify if the results on screen match te requirements. In one of those flows the code that you tested in the pillar unit testing is also "touched".  (So in the flow of screens and input fields you're implicitly testing something that was tested, (@Michael and the other one: sorry I meant...implicitly checking something that was checked on another level) make sure that you understand this before you continue reading. It's important). (I warned for cryptical explanations and otherwise out-of-the-box references)
-
Okay let's just assume so far you understand my cryptic way of explaining things somehow.

We discussed 2 pillars and we used test techniques.
-
Did we apply the right test technique? That's hard to tell, hard to predict.

§§ Do you cover (test coverage) everything if you apply a test technique? probably not. It is very hard to explain how this works but will you always win a fight if you apply material art techniques? well no. Sometimes it might even be best not to use a learned technique and improvize. So are certificates in software testing usefull? well yes and no...
They might come in handy, but it's no guarantee that someone without it is a lesser software tester! keep that in mind!
-
Next level...

**The code changes**

because the customer had a desire, dus the code had to be changed. What has to be retested?

Do you have to retest (recheck) the code if it works as desired in all cases?
Well yes, looks like to me you want to search for bugs.
(It would be a bit strange to check for laws and regulations accordance first and with a change of the software code just let it be, right?)
-
Is the same test technique that you used before still the one that is most suitable?
This might not be the case, the code got more complex and changed bigtime, now it's more suitable for another test technique.



Is thi§§ still applicable? Well yes why wouldn't it be?



Does the change-of-code effect the results of the other pillar 'test automation'?
Well yes, just because the results of the input fields and "final page" where okay at one point in time.
It still can easily be the case that the flow that touches that part of the code, now will result in a failure. test nok
-
might it be the case that improvizing is now better then a test technique?
yes might be the case
-
might it be the case that another test technique is now better?
yes, or a combination of both
-
okay, fast forward >> into the future...

All flows (chronological order of input fileds) are test- automated on the gui.
It produces all the desired results.
all unit tests pass as well.
-
**The GUI/website, front-end changes**
Customer sayin':
I'd like to order of the input fields re-arranged, I'd like the input fields 3 6 and 9 to be appeared on website page 1 and the input fields 10 and 11 on website page 4.
-
What is the effect on the pillars you think?
-
Does the test automation of the GUI have to be altered?
yes.
Do the unit tests have to be checked again?
yeah (why build them, to never run them ever again, right? )
-
so far...
We have mentioned only 2 pilars, 1 test technique.
And the fact that improvizing can be better sometimes then a technique at all.
-
Does your company have "all" (at least) 4 pillars I mentioned in this blog in place? (unit tests as wel as... as well as... as well as - at least an attempt to understand test process-
(Most companies don't to my opinion...)
-
Do you have any idea how many scenario's, cases, user story's have to possibly be re-checked (and test cases/techniques reconsidered) when 1 tiny bit is changed? (and that is only the checking part of testing, not even the "creatively search for a bug by means of improvizing or...." etc)
-
all in all...

Grosso modo: when 1 pillar changes, all pillars have to be checked.
-
Take this into account the next time you hear someone say:
'Is testing done yet?'
(sadly, some people just don't have any clue how complex it can get to (in their eyes, and what they call) "test everything".)

Requirements sometimes are like pilars...

If requirements meet the ISO norms, the laws and rules, then the software program wil survive, your project will survive and/or the company will survive. Whatever is at hand. 
The pilars are important. But in software testing manytimes the requirements are interdependent. They are related to eachother.
I've thought about a schematic respresentation.
This is what I've came up with:

In this example it's clear to see that the most upper pilars are the strongest.
But wait. That's probably not the way you'd like to build your software, right?
So, where do you start testing?

Exactly at the foundation, at the base. So you need to think hard on what the most important requirements are. 

Many times I see people work hard, but they are not focused on the most important things. Selling a product 999x is nice, but would you like to sell a product which is wobbly and doesn't meet the requirements?, of course not!

Well, with this in mind you might want to read the great Twitter post of  a highly appreciated expert in the field :
https://twitter.com/michaelbolton/status/1123664036418211840

In essence: of course you want to test the most important requirements, the lowest pilars hypothetical spoken in this case. But in order to be sure all the base requirements are tested well... you must have a sharp eye on a couple of important things.
Remember in software testing,
​paradoxes always lurk!