Whether you want to admit it or not, but in most companies there is some form of hyrarchy.

And we all know, circumstances can cause us to behave/act differently.
​

What I also noticed is that on certain levels in the hyrarchy piramid the movement is more from chaos to order, while on other levels the movements are more from order to chaos.
​

On the great platform Twitter (+8% stocks today) there was a great Tweet about the bug report pipeline.
https://www.satisfice.com/blog/archives/487131
Paul Szymkowiak made this subject even more interesting.
https://www.satisfice.com/blog/archives/487159

Now until this point I agree a bit more with Paul then with James (and Michael).
Paul's list is like so:

• The Bug Exists:
• 1. is producible/ produced
• 2. is observable/ observed
• 3. is comprehensible/ comprehended
• 4. is authenticatable/ authenticated

 

• The Bug Matters:
• a. is reportable/ reported
• b. is receivable/ received
• c. has relevancy/ is relevant
• d. is advocatable/advocated

Now this is the thing,
If only humans where to find bugs, this list was less complex. But we live in a world where unit testing, test automation and a.i. exists.

see also my previous blogs.
http://testenvansoftware.weebly.com/blogs/what-will-ai-testing-look-like

So for the part 'exists',
should we see it like this:

Or more like this way:

In other words. Who should determine the 'exists'?

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: