'Modern Testing' is the loss of testing as we know it?

Questions
#21

Honestly, I really like the idea of the Modern Testing Principles, even though if you take a shallow look at them, it might seem like they are aimed against testers - but I don’t think they are, at all.

From personal experience, having a QA department that is solely responsible for doing all the testing can lead to tensions, cost a lot of time, and many times bugs escape to production and then you have some C-level big wig yelling at testers: “HOW THE HELL DID QA MISS THIS?!” A lot of time is saved if the developers are also doing some testing, not just the unit test (they do mean a lot, especially useful where TDD is practiced) but also doing the functional testing - because that’s the earliest tangible testing that can be done.

I don’t feel that MTP makes testers redundant, there is plenty of value a person with dedication can bring to a team that is moving in this direction. I’d rather be teaching other roles in the company how to test better than spend all my time doing 90% of the testing myself. Maybe that’s just me but it seems more meaningful and efficient in the long run - and besides the role of a quality/test coach seem like a dream job to me! :heart_eyes:

4 Likes
#22

All of this ignores the fact that our customers are our biggest test resource. Most builds get about 2 man-hours of testing before the next build comes along. And I’m reminded by Stuart C, that when you do release, the build can go out to 100 000 users, who, will completely dwarf your tiny team’s 100 hours of release testing effort. So you have to have someone who cares, and maybe that means dogfooding, maybe that means something else, but ultimately it’s about communications skills.

  • I am sure some C level types also realize that when they yell @mirza
    “HOW THE HELL DID QA MISS THIS?!”
    , that the test resources actually are already kicking themselves hard enough, no need to lump it on.

As someone in a “test team”, I’m not happy with the situation of team separation, but anyone who thinks the developers do “all” the testing has not worked on the more mature end of the cycle, where operations (keeping the lights on in the house) is far more work for the higher returns than the coding is. So I’m happy to see more nuanced approaches being taken.

5 Likes
#23

Honestly, it’s an archaic thought that a C-suite is going to yell at the test team for not finding a bug. These days, everyone understands that quality is a team responsibility. So, that thought should not be the basis for not having testers.

Also, irrespective of whether you do post-code testing with humans or automate it, if someone thinks of blaming, they will - and this is irrespective or whether it’s a developer or tester! So, it’s a very weak argument towards not having testers.

Post-code testing is a must. You can’t predict all the ways a software will behave upfront. It will make itself visible in its behavior only after the whole product is available for test - not during requirements, not during TDD, not during developer-driven integration tests. Don’t believe stories circulating about #zerobugs claiming that they prevented all the bugs before coding. That is like saying that their software has no bugs, which no one will agree.

2 Likes
#24

That CEO yelling at the QA team happened to me in my first company - one of the reasons I bailed out of there. :sweat_smile:

I do agree that in practice eliminating testers just doesn’t work for most environments, maybe for less complex products it could work, but strictly from my experience the only cases where I noticed that they don’t have testers were on smaller projects where developers were practicing XP with TDD and the POs or BAs were doing the e2e tests - so they had functional testers they just had other roles doing it, in a nutshell.

But I like the idea, dunno maybe:

image
image600×600 47.1 KB

2 Likes
#25

“That CEO yelling at the QA team happened to me in my first company - one of the reasons I bailed out of there”

In my first company, the CEO (who basically ran everything) smashed a keyboard down on his desk so hard all the keytops flew off when he found an error in the early cut of an accountancy product we’d been programming, and which he’d insisted on being allowed super early access to.

1 Like
#26

I don’t think it’s a dream, but it’s similar to BDD. It’s not just a matter of doing the one thing (i.e. adopting BDD/GWT language, getting rid of dedicated test, etc), it’s a whole culture shift.

You need to shift left, leverage automation, get everyone to own quality/create a truly blameless org, etc, and that’s when you can finally get to the point of no longer having dedicated testers.

4 Likes
#27

Hi @conrad.connected This might be a late read by me for this topic but still its never too late to know :slight_smile: You wrote that your role has moved towards Release and OPS side. Would you mind sharing your thoughts on working on Release side? Also can you please explain a bit about the duties you perform as a Release person. I searched on the internet but it looks more like Technical side (Like developers / Creating Pipelines etc) . thanks

1 Like
#28

Always keen to share @sah .
Since I was a coder for a long time, things like toolchain and deployment are not really scary for me. I have always thought that this entire “quality” job description is really not only about verifying that the software we ship is good, but also that the way we create it and ship it is good also.

A bit like testing hammers in a hammer factory is not about checking that the handle does not break, but also that the wood it was made from, was consistently dried and compressed first so that it does not fall apart later. There are lots of things you cannot test on the shipping day. So, yes I believe that testers should know how all the parts get collected up, compiled and all, before we get to start the system testing. And by definition, have also found that I get involved in helping to deploy to live, but I don’t get deeply involved in the OPS infrastructure. Production OPS is a weird place, and the dev-ops term bandied about makes it sound as if you can just switch from one to the other, that’s simply not true. It’s about scale. I really hope we kill off the term dev-ops, they are not a one single thing, what most of us do is really all “pipeline”.

OPS is like the electricity company, they keep the lights on and the fuses replaced, DEV are like the gas-generators and wind farms. Even nuclear plants is OPS, they are the 20-year plan people, and are relatively more boring.

I, see “generalist” testers as being people who can walk into all of these places and help make improvements though. A thing I consistently noticed when you are doing a release for example, is that if you find a defect, you have to be able to properly decide if it’s a showstopper, and how long it will take to rebuild. For example if a large batch of “small” defect fixes you might need as a result for a fresh release candidate will be able to be built and tested individually or as one big batch. So having good visibility of the health of the toolchains and build pipeline stability is key to how you release. And visibility of process and people and resources. If build stability is flakey, or slow, doing a fresh rebuild for a small fix can sometimes cause you more pain for example. Developers will always drift towards expertise in an area of not just the tech stack, but also the area of the pipeline or SDLC that give them the most reward. Testers in smaller companies do not get to choose, we need to be over the whole thing.

Release, is another topic altogether relying more on communication (which I rubbish at,) but also on planning detail level. I’ll have to find a person who has written a good blog about release.

3 Likes
#29

Thank you so very much. I would love to read the blog / Article on release also ( If you could find any) Thanks again for this detailed explanation :slight_smile:

1 Like
#30

As testers we probably don’t often share about our interactions with the release manager, or about the times when we do take on that role.

It’s not a dark art, but releasing is an art.

3 Likes
#31

I’m absolutely with you on this one, Venkat. All these plans seem to be the usual cycle of “saving production costs”. Everything has to be shifted to the left, downsized or streamlined. Developers will have 100% testing coverage on unit level or quickly test their work themselves. But after a while there are not just bugs but catastrophes: OSs delivered with storage-deleting bugs or some part of an airplane not working properly (usually with deadly consequences). And after much damage control there is the insight that, no matter how much testing you did on the code pre-compilation, you need a knowledgeable guy or gal who wasn’t directly involved in the coding process to look at the UI and the program in general. That’s us testers. After that of course, the cycle will start again…

2 Likes
#32

1 - What kind of roles can such testers (realistically) get?
2 - Do most companies have such roles? If not, then should they?

PS - I suspect that most of such testers will understandably be let go. A few good ones might be lucky to get into some test coaching role, but I wonder if that happens only in Microsoft/Google and a few small companies. There is nothing wrong in roles becoming obsolete if there is no need for them. There are almost zero elevator operators and gas jockeys now in many parts of the world.

1 Like
#33

Is your approach to testing sustainable in the long term (say 5-10 years)? Have you followed the progress of the teams you coached/made and the product over, say 5 years? I guess this is not possible because people including you, have more important responsibilities at work and might also have change employers or teams. So you lose the visibility into changes in their quality culture.

PS - In medicine, researchers follow up with test patients over several years to see how they do with an experimental medicine or medical device. What seems to be a great cure now, can turn out to cause major health problems a few years later. TBH, I am not sure if its fair to compare medical experiments to your experimental/new approach to testing.

2 Likes