Honestly that sounds like making pilots build aircraft engines.
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.
Then your developer should learn that "done" means more than "works 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.
If this happens to be a reference to Microsoft, their famous laying off of qa people has been regarded as a disaster by everyone outside Ms, with windows update quality dropping off a cliff.
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.
never underestimate the ingenuity of a good QA person. "app freezes while triple-clicking About button while changing wifi network when storage is 89% full and screen reader is enabled"
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
> never underestimate the ingenuity of a good QA person. "app freezes while triple-clicking About button while changing wifi network when storage is 89% full and screen reader is enabled"
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.
> If such feature interactions matter then your application has bigger problems than a QA department.
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.
