[dmw_ng]

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

[convalescindrey]

> 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.

[throwway120385]

> 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.