Has anyone struggled with being an SDET and figuring out how to add value to a business?
Most of the other dev/engineering roles seemed to be much more clearly defined, for example at my company…
Platform - Kubernetes, Terraform, Azure
Backend - C#/.NET, Azure
Frontend - React, Material UI, React Query, Next.js
Fullstack - All the above
BA - Write stories for a particular functional area
UI/UX - Create figma designs for new/updated functionality
Manual QA - Test stories and bugs
Where an SDET slots in is not obvious. We already have unit tests, in memory integration tests, PACT tests and Cypress tests setup by the developers. We are missing a small but broad set of UI tests but I don’t like this perception that SDET’s are just essentially black box UI test creators. We push out to production frequently so most UI tests are redundant because someone in the business will notice any high priority bugs that are introduced faster than it takes a UI test to run (e.g. an issue with login). Because of our PACT and integration test coverage we don’t feel we need a seperate set of black box api tests.
The other devs can understand the code you write as an SDET but as it’s often a departure from their day to day work there is rarely any interest. Those on the manual QA side are often interested in the outcome of automated testing but often don’t have the coding experience to understand what you are doing. As a result you end up stuck in this sort of purgatory where no-one truely is invested in the work you are doing.
I feel like just being a developer is better for getting a more clearly defined set of day to day tasks, that may or may not include some testing activities.
Those that feel comfortable in an SDET role what sorts of tasks have you done to add value to the business?
I sometimes can’t tell if companies are differentiating between an Automation Tester and an SDET, formally an Automation QA adds new automated checks, debuggers the failing ones and maybe works on the automation frameworks.
For the SDET part, my impression that SDETs are usually making test frameworks from scratch, adding utility and helper methods (abstracting away stuff to make it more convenient for others to use the framework) making custom tools for testing, such as test harnesses, mocking stuff, etc.
That’s the impressing I get from checking the local job postings, I don’t know many people with the SDET title to have more insight into the reality of the job, unfortunately.
Software DEv in Test
That’s how I have always seen it, it’s an automation role, but focuses on “creating” tooling as well as execution (writing tests and running them.) Which @mirza just said. Hence the “Dev” component to the naming, as being skilled at coding in more than just the testing “language”, and someone who participates in code reviews.
My experience of being “labeled” as SDET (I hate labels) was probably a lot like yours @konzy262 , a bit loose at times. I found I had to create my responsibility niche and hold myself accountable because my job was never going to be agile. Always felt waterfall/KanBan . Maybe because the SDET role (in my mind at least) sits in a more mature point in the product lifecycle, where any regression costs the dev teams more?
I suspect however that I’m chewing the wrong end of the plank, because job specs with the word SDET might not really be an accurate title. But it’s my first job-hunting search keyword
Hey!
Basically, there are a few different names for those who do automation testing.
It all depends on the company.
In some companies there is only a QA Engineer role: here you are responsible for all sets of testing activities, like testing, test design, automation, and others.
In some companies, there is a difference between “manual” and “automation” testers. Automation testers are responsible only for creating and maintaining UI / API set of tests.
Lately, the SDET title in Google was re-invented and now they are called more precise (IMO) - SETI (Software Engineer Tools and Infrastructure). It defines the skillset and activities of the engineers.
So these SETI engineers are not working inside a particular team. It is a set of engineers who is responsible for writing testing frameworks and tools, setting up CICD pipelines, educating developers and testers on how to get information and feedback from the tools. They can extend current feature code with additional monitoring capabilities - so it will be possible to see if something goes wrong almost instantly.
From the skills point of view - it is the same developers as feature developers (plus a bit of testing knowledge). The only difference is the audience. SETI engineers have other internal engineers as their users. So the impact is mostly internal, not external.
And of course - there is no need to have a lot of such engineers. Their number is much smaller than the number of other engineers.
In my opinion, writing/creating automation or automation frameworks is just 30% to 50% of SDET work. Even creating frameworks is a questionable part of the work.
If an SDET has experience in testing, then they should also advocate on behalf of the testing team for participation in requirements/design meetings, advocate for shifting testing left, and advocate for improving testability.
