What’s the difference between a QA, SDET, Quality Engineer etc.?
the 4 types of QAs and what it means for your organization
If you’re looking to hire new “QAs”, this short piece will hopefully help you improve your, er, KYQA (Know Your QAs), and make more informed choices.
Cheatsheet (in case you’re in a hurry)
Manual QA
Usual skillset
- functional testing
- clicking around
- catching weird bugs
- good product knowledge
Usefulness ⭐️⭐️⭐️⭐️
Look for: good interpersonal skills and enthusiasm (really!).
Automation tester
Usual skillset
- 1 language
- 1 or 2 test frameworks
- narrow software engineering knowledge
- canned testing knowledge (like ISTQB)
- decent product knowledge
Usefulness ⭐️⭐️
Look for: willingness to grow, evidence of programming work (GitHub projects etc); otherwise approach with extreme caution.
SDET
Usual skillset
- comfortable with 2 or more languages
- variety of tools used to solve diverse problems
- aware of how to test microservices, cloud…
- broad software engineering knowledge outside of E2E testing (Docker, cloud, refactoring, unit testing…)
Usefulness ⭐️⭐️⭐️⭐️
Look for: evidence of engagement with the newest tools (Cypress, Espresso, Pact); be cautious when you hear words like “Selenium”, “Appium”, “Capybara”.
Developer who cares about tests
Usual skillset
- comfortable with 2 or more languages
- their specialty (frontend, backend, data engineering etc.)
- TDD (Test Driven Development) knowledge
- expert knowledge of a unit testing framework in their favourite language
- integration testing, E2E testing
- refactoring and writing software for testability
Usefulness ⭐️⭐️⭐️⭐️⭐️
Look for: a serious attitude toward testing. I’ve known developers who would simply say: “I don’t care about tests. I just wanna create features.” 🤦♂
End of cheatsheet.
Why care about QA people?
Software Quality can often be the “make or break” of your organization. It often has a knock-on effect on pretty much everything else. The general trend seems to be, roughly speaking, as follows:
💢Low Quality:
unhappy customers, frequent firefighting, frustrated developers, frustrated business side, large staff turnover.
💵 High Quality:
fast output of new features, fast iteration and learning, productive developers, sales people who actually have something to sell, higher general morale.
❗️Whoa!
That definitely looks like something to pay attention to. It follows logically that many companies will consider hiring “QA people” at some point.
But what are QA people exactly?
So what types of QAs are there?
You might want to ask: “Why are they called QAs in the first place? It sounds like a pretty vague term.”
Yep, and there’s a reason for that. The big secret of the industry is that no one really knows what “QAs” are supposed to be, or do, exactly.
“Catch bugs.” say some.
“Ensure code quality” say others.
“Ensure product quality.”
“Make sure best practices are followed.”
“Have a quality-oriented mindset.”
“Be responsible for automation.”
“Write tests.”
“Prevent problems.”
“Quality Assurance” is actually an umbrella term for a variety of related, but quite distinct functions.
Below are the different roles that QA people broadly fall into, with respect to how technically engaged they are:
1. Manual QAs ⚙️
2. Automation testers ⚙️⚙️
3. SDETs (Quality Engineers) ⚙️⚙️⚙️⚙️
4. Developers who care about tests ⚙️⚙️⚙️⚙️⚙️
Manual QAs ⚙️
This is where many “Quality” people start out. Some then move on to more automated roles, while some decide to stay on as Manual Testers. Others still capitalise on their knowledge of the product and become more “planny-businessy” people, like Product Managers or Product Analysts.
Do I need them?
Opinions vary here and it’s really down to the gut feeling of your CTO/Head of Engineering. Some people say Manual QAs can provide brilliant insights into the problems in your software. Others will argue that the role is just a fig leaf that obscures deeper issues with your quality processes and engineering culture.
Give it a try.
My suggestion
Give it a try. Hire one or two Manual QAs and let them grow. But also make sure you address the more nuanced aspects of your test culture, such as automation, knowledge sharing and your developers’ testing skills. Manual Testers are often awesome additions to the team, but shouldn’t have to function as your last line of defence.
Manual Testers shouldn’t have to function as your last line of defence.
Automation Testers
A lot of “Quality Engineers” out there are Automation Testers. They know a bit of coding, just enough to write automated tests, usually limited to just one framework and one programming language. Theoretically, they can catch bugs faster than Manual QAs, due to the use of test automation, i.e. “code that tests code.”
Do I need them?
You DO need test automation. After all, it’s the very thing that allows developers to work faster, rely less on manual testers and push out new features with more confidence. But there’s a catch:
Automation Testers are not necessarily good for improving your automation.
There’s much more that comes into creating good tests than just writing test code. You have to write good, maintainable test code. You have to keep up with the newest trends in testing, and stay sharp in the language you write your tests in. You have to understand what the developers actually need, as your “customers” — and for that, you need to be a bit of a developer yourself.
Writing tests is writing software.
My suggestion
Don’t. Many self-proclaimed Automation Testers will lack the necessary enthusiasm for technical growth. They will also shy away from manual testing since they are “Automated”.
In the end, they won’t be really useful for anything. More often than not, you’ll end up with poorly written scripts which tend to break and often cause everyone more headache than they’re worth.
If you have an Automation Tester applying for a job with you, give them a chance, but make sure they actually want to grow and learn new stuff. (A LOT of new stuff). Hire for junior SDETs, and make sure you have someone who’ll teach them.
SDETs
Stands for “Software Development Engineer in Test”. These guys will be either Automation Testers who’ve acquired a ton of other tech skills or (in rare cases) developers who switched to a Quality Engineering role.
Do I need them?
Yes and No.
Yes, because good SDETs can often make your developers very happy. They research, provide and educate people on the optimal testing tools. They work with DevOps to build testing into your Continuous Integration process. And they’ll quickly figure out how your software works and where the biggest technical pains are.
But. Some SDETs will still tend to limit their skillset and silo themselves away from the developers (a common plague among QAs in general). Which brings us back to the Automation Tester problem.
Also, having skilled Quality Engineers will not directly fix your engineering culture. Their presence may still result in a culture of “Ah, we have QA, there’s a safety net. Let’s just throw the code over the wall to them”.
Finally, it takes skill and seniority (something Sebastian Marshall calls auctoritas) for SDETs to make their ideas heard. And that’s often not the case, since most SDETs come from a rather “junior” technical background (former manual testers, product analysts, data scientists rather than pure-blooded engineers). Without a charismatic Team Lead to sell them, your SDETs’ ideas will most likely fail to make an impact on your broader engineering team.
Some SDETs will still tend to limit their skillset
My recommendation
Good SDETs are certainly worth the investment. Just don’t forget they are essentially programmers and have to be able to grow their skills. Programming, Docker, Cloud, Serverless – effective Developers in Test need to constantly educate themselves. In a world of AWS, Machine Learning and microservices,
“Oh, I’ll just whip you up an end-to-end test framework.”
simply won’t cut it.
Which brings us to:
Developers who are good at testing
This is essentially the Holy Grail of Quality Assurance. If your developers are dedicated to and comfortable using various testing technologies, you’re golden.
They will write great code at a micro level, thanks to unit tests.
And, by skilfully applying testing at the service or system level, they will be able to create robust applications and systems, massively decreasing confusion, development time and software maintenance cost.
Do I need them?
Ideally, yes. Especially one or two senior ones. No one can write great test software like good, seasoned developers.
No one can write great test software like good, seasoned developers.
After all, it’s not like all the great test frameworks out there were created by testers. The folks who wrote them simply needed something that would complement their day-to-day work and make writing good code easier.
Conclusion
Testers can be great. But be careful with your money.
When investing in a test team, be like a good tester – ask a lot of detailed, inconvenient questions. You owe it to yourself.
This was my (rather biased) overview of the the various flavours of Test Engineers, as a former SDET-turned-Software Engineer.
If you disagree with this article, or have questions about building your test team, feel free to drop a comment below.
