I have pretty different opinions on this I guess.
I think QA/Testing is definitely fading away. It'll never be gone, but its not going to grow anything at all like general software development. And its going to be less and less compensated relative to development except for rare circumstances.
The move to SaaS (or even just things like web apps - anything that doesn't require sending code to clients to install themselves), better deployment practices (red/green, feature flags, canary systems, etc) and better "observability" tools (infrastructure and code) are all working against the traditional QA role.
The cost of finding a bug in Production is a lot lower than it use to be (don't need bug reports or user submitted stack traces, can be found before affecting the majority of users, etc.) and the time to fix the bug is way lower (if you're doing multiple releases/day then a targeted fix is just one more release among many).
Other trends like developers actually owning, releasing, and supporting their code in production also work against traditional QA roles since developers have much higher incentives to release good/stable code.
There will always be companies/applications/industries where the cost of having a failure (or fixing a failure) is really high - and it makes a lot of sense in those cases to have a strong test/QA team. But I don't think this is going to be a growing proportionately to the rest of the software industry.
There may also be roles/spots for sort of "internal support engineers" that build tooling/automation around things like user creation / test data / etc. But I think the value here will be a lot lower than in historical QA roles where knowing requirements/edge cases/etc was super important. It's basically useful where you can find less skilled people to do work that makes your more skilled people more efficient.
Quote:
Originally Posted by suzzer99
In our case they often knew the requirements better than the developers. We leaned on them to find all our weird edge cases so we didn't have to think about everything. We could develop fast and loose knowing they'd catch anything that slipped through the cracks.
This seems like a really good reason NOT to have testers. Developers not understanding requirements is not a recipe for good code (or a good product), imo.
Quote:
Originally Posted by Wolfram
Then you have the power-QAs, which is now fashonable to call software reliability engineers. Those are the people that could be devs but chose a different path.
Like any job title, I'm sure this has ended up with a wide range of meanings/responsibilities, but the fashionable SRE role is very different from QA. It's like a dev/ops mix and has a pretty strong future (imo).