Everyone must own quality, for the same reasons everyone must own security.
I agree with that reasoning to an extent, but I come to the same conclusion as in my article by following that line of thinking. Everyone must own security, yes. So developers should be aware of basic security risks, have a working knowledge of things like the OWASP top ten, know how to prevent XSS attacks, know how to prevent SQL injection, etc.
There is still a ton of value in having dedicated Security Engineers on top of that. They act as subject matter experts, have deep expertise in the area, can audit various areas of the app for security issues that developers have missed, and help train and level up other engineers to be better at handling security properly. Effective QA engineers do the same thing.
QA does a lot of manual testing, ineffective.
Agreed, QA should not rely primarily on manual testing. I think we may have had different experiences with QA in our various companies we've worked at.
The most effective QA engineers (and organization setup in general) I've seen have been embedded in each engineering team, aren't required to review every MR before an MR is merged, are technical (think SDET) rather than just manual testers, have deep expertise in writing and maintaining end-to-end test suites, and are great at occasional exploratory testing. Those are the kinds of QA engineers I love to have around.
I agree with that reasoning to an extent, but I come to the same conclusion as in my article by following that line of thinking. Everyone must own security, yes. So developers should be aware of basic security risks, have a working knowledge of things like the OWASP top ten, know how to prevent XSS attacks, know how to prevent SQL injection, etc.
There is still a ton of value in having dedicated Security Engineers on top of that. They act as subject matter experts, have deep expertise in the area, can audit various areas of the app for security issues that developers have missed, and help train and level up other engineers to be better at handling security properly. Effective QA engineers do the same thing.
Agreed, QA should not rely primarily on manual testing. I think we may have had different experiences with QA in our various companies we've worked at.
The most effective QA engineers (and organization setup in general) I've seen have been embedded in each engineering team, aren't required to review every MR before an MR is merged, are technical (think SDET) rather than just manual testers, have deep expertise in writing and maintaining end-to-end test suites, and are great at occasional exploratory testing. Those are the kinds of QA engineers I love to have around.
What is MR?
Merge request. For those us of who use GitLab instead of GitHub that calls them pull requests. 😉