The Mythical SDET, Unmasked - Q&A
Earlier this week, I presented "The Mythical SDET, Part 1 - Unmasked" at InflectraCon. Find the recording here. I've taken the comments and questions folks had during the session and answered them here.
Q: Test engineers, QA, SDET, and their integration in teams overall
A: I'm not sure if this is a question and what it means. I'll assume this means, "How do we integrate Test Engineers, QA and SDETs into our teams?"
The answer really depends on the context, but the simplified answer is "make them a part of all team activities and include them". Likewise, testers are responsible for asserting themselves as a full members of the team.
With Scrum/Agile, each team member (which includes any type of tester referenced above) is ON THE TEAM. They attend all meetings. If they are in one location, they sit together. If they are remote, they are a part of team chats and other online communities the team uses to communicate.
Anyone doing work related to testing should estimate their tasks and have fair say in learning about and analyzing stories prior to a sprint. Their testing should be done in parallel, if not before development. (See my webinar on syncing up testing and dev for more information on this. TODO - link)
Q: More time would be great!
A: Yeah, I agree. I was under the impression we would do 45 minutes, not sure why it was just 30. I'll talk to Sri.
Q: I left this presentation with no better understanding of what an SDET is than what I came in with. There were some good recommendations of what NOT to do (ex: converting QA, using "failed" software devs), but I'm still not clear what an SDET is actually *doing* in their role.
A: I'm sorry to hear that. Let me try again...
An SDET writes software and solves technical problems in support of software testing and as a service to software development. This includes *doing* things like:
Writing automated tests,
Writing code to support automated tests,
Writing code to allow folks to test parts of the software they don't have access to through the UI,
Working with developers to create solutions to make the software under test more testable,
Supporting, maintaining, and creating Continuous Integration (CI) pipelines and infrastructure needed to support CI. This may include:
Creating pipelines in the CI system,
Building virtual systems for pipeline jobs to run on and against,
Writing code or configuring systems to set state of systems for testing,
Reseting or cleaning up CI-related systems,
Creating solutions with code and software to make software engineers’ and testers’ jobs easier, more efficient, or more reliable.
In short, the SDET works to automate anything that can and should be automated, related to testing.
Q: Using AI for testing. Yes, AI is the new hotness, but if developers are going to be using it to write better code faster, testers will need to keep up.
A: After 25 years in the software industry as software engineer, tester, SDET, manager, vendor, client, etc... I'm completely convinced that no software engineer has ever "gotten ahead of testing". It's a bit like a bicycle's front tire asking the back tire why it won't keep up. AI will not change that.
Maybe I should write about this? If so, I'll link the post here.
Many thanks to InflectraCon for hosting me! Make sure to check out the second talk next week (June 18, 2024)!