The bigger problem here is that you have devs, devs make bugs.
if you don't have devs there are no bugs, problem solved.
if you don't have devs there are no bugs, problem solved.
these are different disciplines that deserve to be done well.
Maybe I am biased because I spent the last 10 years in gamedev, or maybe this is another push to make devs do basically everything tech related: but if a developer tells me a feature is done I always look to QA for a nod.
That nod rarely comes, the feature is not done, the developer merely got it to work on their machine.
The difference between devs and dedicated QA people is that devs know the dark corners of the implementation. They know the edge cases and scenarios that they struggled with getting right. That's where most testing focus has to be. QA doesn't know any of that. They can play through some scenarios that are the expected ones from the spec, perhaps have some hunch of what could be the tricky cases, but they don't actually know.
I love seeing all those downvotes for my GP comment. That's all the people working at companies where stuff that devs feel is below them is dumped on QA people, which is the main reason my company is well-known for shipping top quality (without having a QA dept) while our competitors struggle with quality (despite having a QA dept). That's all the evidence I need to back up my claim.
And I believe it's hard to do this kind of thing as an afterthought. If your whole engineering culture is built around having a QA dept then just firing that dept is obviously going to have disastrous consequences.
it's the same with good security folk. sure you can pretend you'll catch 100% of issues, but it's a delusion, good security or quality testing is a totally different mode of thought
If such feature interactions matter then your application has bigger problems than a QA department.
> it's the same with good security folk. sure you can pretend you'll catch 100% of issues, but it's a delusion, good security or quality testing is a totally different mode of thought
Oh I'm not saying that good QA isn't a valuable skill! Of course it is, it doesn't just happen on its own. What I'm claiming is that it's a skill that should be employed as close as possible to the creation of the thing that it's assuring the quality of. So, ideally within the developer themselves.
Same thing with security. You will have a terrible security in your product if you first design and implement it and then put security in there as an afterthought by a dedicated security team. Ideally it's been at the table from day 1. So, a good security team works on educating your devs to do things right from day 1. Just like QA.
QA doesn't exist to check that your crap architecture solves the problem. They're there to be the skeptical person in the chain of custody from developer to production. The old adage "you can't test quality into software" exists for a reason. It's true. And you're right that it's the wrong architecture. But that's dismissing the very real purpose of QA which is to catch these kinds of bad architecture problems by testing for conditions that the dev team possibly didn't consider during development. QA is also there to make sure you're not making any unfounded assumptions about the context the software exists in.
To the extent you actually care about checking all of your assumptions and not just the ones you're cognizant of, QA is very useful.