[‘Modern Testing’ is the loss of testing as we know it?]

Community Discussion Automation Test
#1

Hi All

I have just followed the ‘modern testing’ course and its prompted quite a lot of thoughts but equally disagreement on my part with my own personal experience and the company i work for. I guess im just reaching out to see what peoples thought’s are on the future of dedicated/specialist test individuals and teams. Some high profile companies like yahoo quoted as removing testers altogether. Of course the world we work in and technology within it is always changing but i just cant (rightly or wrongly) foresee a point where a testers role would be diminished and passed off to the business or fully saturated into a developers role and responsibilities. Sure, we want to be LEAN and release change quicker but cutting specialist testers seems a step too far and a risky slope to go down for any business which i dont think defines ‘modern testing’ as a strategy or a whole. Whats peoples own experiences with this across different companies within the industry?

Regards

#2

There are two parts to testing - observing, validating, and verifying WHILE the product is being built, and observing, validating, and verifying AFTER the product is built. Both are important. Unfortunately, the human-led analysis and testing post-development is considered as a time-consuming, costly exercise that should be minimized or even completely eradicated. This was not a serious consideration for the past 20+ years, but only recently after a section of developers started influencing that every testing CAN be automated and it’s enough, which is not true.

While doing unmindful repetition of test cases without due consideration of whether that particular test makes sense for the context is a big problem, stereotyping ALL repetitive testing post-development as a ‘manual regression’ is totally wrong and should be argued against.

So, whoever is trying to do this is splitting the post-development testing into two efforts - (a) manual regression and (b) ‘exploratory’ testing. And they want all the ‘manual regression’ to be automated and ‘exploratory’ testing to be quick so that the CI/CD pipeline speed is not affected.

Those who really know testing though can vouch that ‘exploratory’ testing and regression are intertwined. Regression happens when an area being explored again needs automated checks, and exploration happens when the existing regression tests are not sufficient to cover the context. This split as ‘regression’ and ‘exploration’ should be avoided and testing should be looked at as an wholesome effort led by humans (not machines).

All I mentioned above is in the spirit of upholding best Software Quality, and I am not against any specific method, tool, technique, or philosophy.

#3

If this the Alan Page and Brent Jensen view, I have not taken the course but I am familiar with the principles and also some earlier “no tester” ideas.

That whole “no tester” discussion for me was a bit of a red herring, yep testing is still very much needed, we just shuffled the board a bit and gave our exploratory testers a different name.

The principles though I think are really good and I agree with a lot of it.

For example I am very in favour of developers doing as much testing as appropriate and doing the majority of coding based automation activities even at UI layer, for me I have seen this first hand as much more efficient than any other model many times. I pretty much feel developers are great at the known risk coverage and with coach can also cover unknowns even if I do not see that as their primary focus.

All of the principles in my view have merit and I’ve been in roles/projects where I can actively apply pretty much all of those and they have been better projects than others where my testing contribution was more limited.

The one thing I disagree on in my context is ‘testers do less testing’, well that really depends where you started from and you were doing a lot of low value testing before.

So for me, rather than diminish the value of the tester role it elevates it, I can do more valuable testing, I can do more of the testing I enjoy, the unknown risks, coaching, more customer involvement.

Using data is also an important aspect of this view, getting more involved in user feedback, logs and analytics is still part of testing, its just another risk we investigate.

I particularly like the idea of the testing role to accelerate the whole team forward.

It does impact a lot of testers though, my ratio is normally one tester to around ten developers and I still stick my hand up for extra interesting projects.