I've noticed a growing trend in software companies over the last few years in which upper management declares that quality assurance roles will no ...
For further actions, you may consider blocking this person and/or reporting abuse
I totally agree. The point of adding lots of unit tests and some integration tests should not be to remove QA engineers but to empower them to focus better on where their skills are most helpful.
I've definitely _not _noticed this trend in the places I've worked. Some places will choose to cut down on QA first, if they're running into financial troubles, but it usually comes back to bite them and hastens their demise.
I can’t say the trend reflects any of my observations with the industry, but I wouldn’t be surprised if certain leaders took this action. You’ve done a good job detailing why dedicated QA roles are beneficial, thanks for sharing!
Thank you for reading!
I also agree with you @thawkin3 and let me explain why. After 2 decades of working as a developer I decided to build and lead a SDET team. The only reason I jumped to this role was that the company's testing strategy included the following release exit criteria:
Implemented by Dev teams:
Implemented by SDET team:
In general the philosophy is to have fully automated all the tests so that everything is executed through CI/CD pipelines ensuring that no regressions have broken builds from MR to MR. I know, there are a lot of challenges to implement everything from scratch in a greenfield project and also bring the DevOps and Automation mentality to all teams. At the end though, the quality of the product will be outstanding.
Absolutely! I love having a good QA engineer around that can poke holes in my feature even after I've written a bunch of tests and done my own due diligence.
Having a second pair of eyes is usually helpful, and someone could argue that the second pair of eyes could be another software engineer, but even then that second software engineer is still under the same pressure to not spend too much time on this or be as thorough as they could be if this were their only responsibility.
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. 😉
This really isn't true at all. A good engineer should have a combination of both mindsets. If you don't, you will produce sloppy work. I have always tried to break the stuff I build if it is intended for the consumption of others, and I cannot stand it when I'm asked to review stuff that has obvious defects that take 2 minutes to find - it speaks to a total lack of care about what you are doing, or a lack of knowledge of how things should work. TBH, most QA teams I've worked with don't find half the stuff I find and I sometimes wonder why they're there.
Nobody trained me to work this way, it just seems the obvious way to work. There's no context-switching involved.
Thanks for your thoughtful comment! I'm agreed with most of what you've said.
Just to be clear, I'm not advocating for sloppy work, lack of testing by developers, or "throwing things over the wall" for QA to go test. That kind of working strategy is inefficient and leads to re-work. So we're 100% agreed that developers need to have a quality mindset, test their own code, look for bugs, look for edge cases, and shouldn't submit sloppy MRs with obvious errors.
It sounds like maybe you've had some poor experiences with bad developers and bad QA teams in the past, which is unfortunate. These comments are interesting, because we're all speaking from our own experiences, which I'm sure vary greatly from person to person. I think it's important though to differentiate between the two ideas of "the QA engineers I've worked with have not been very useful" vs. "QA engineering roles in general are not very useful."
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.
There's nothing wrong with manual testing. I rarely use automated testing at all. If you're editing code, you shouldn't be - unless you understand that code and the ramifications of changing it. The building of that understanding should not be skimped on by relying on test suites that may or may not be correct or up to date.
Automated testing encourages the siloisation of knowledge and understanding, which - to my mind - can never be a good thing. The more deeply a developer knows and understands a project, the better they'll be at working on it. Also, they'll gain a better sense of involvement and attachment to the project as a whole.
Seems likely that we won't agree here. 🙂
I tend to favor the opposite viewpoint, which is that as a company's codebase grows, a single developer cannot and should not be expected to have a deep understanding of everything in the codebase. Yes, do your due diligence. Yes, develop a solid mental model of what you're working on. But when working on code written by thousands of developers over decades of time, it's often hard to know if there's a "gotcha" lurking in the shadows waiting to break when you change something that you swore was unrelated.
I'm always grateful when an automated test catches something that I didn't.
Short term benefit, long term huge mistake!
Oh my goodness, I thought it was just me, QA testers are getting rarer, you can't trust me to mark my own homework!
Coming from a python back end web development background, I wonder why QAs should have expertise in
Pytest. I always thought of it as a framework to build unit tests, and that should be left to the developers, rather than taken over by QA.QA and software development are distinct skill sets, and these are not easily transferable in either direction.
That's a good callout. You're right, Pytest isn't really in the same category as Selenium, Cypress, or Playwright.
Pytest is just a testing framework, so technically you could use it for tests at any level (unit, integration, or e2e). In one of my engineering organizations we used Pytest for a Python e2e test suite, but maybe we were the odd ones out!