Gergely Orosz’s Post

Personally, I much prefer the "everybody develops and tests" approach. Gives everyone ownership of the feature delivery and final product and (importantly, IMHO) makes us better, more skilled, hireable engineers that can fit in any team. I have fond memories of working with you on the Skype for Xbox One project and special gratitude goes to our SDETs (who were super capable SEs, after the merge) at the time for how much I learnt about the testing mindset.

You weren’t alone in fact. The Windows Phone team also went through a similar transition. Whilst we weren’t shipping as often, the boundaries between roles became fuzzier. Developers learned to automate and test better, testers to code. The team was so much more effective as a result. The morale was also high. I put it down to a lack of ego and supportive leaders. Best team I’ve ever worked with.

It wasn’t perfect but I learned so much on that Skype for Xbox One team - coming from the games industry where the wall between dev and test was steep and testing was considered low skilled manual work, it inspired a passion for TDD and quality and shifted my own mindset for life

I also worked as an SDET at Microsoft, mostly on Windows Phone, after working in the industry previously as a developer. It was a great job; I worked with smart people, learned a ton, and I was proud of putting out high-quality products. But, yeah, the limits on career growth and feelings of being treated like a second-class citizen in the company were real. It took a lot of effort to transfer back into an SDE role within the company because of that "SDET stigma", which was a shame; I was still doing a lot of coding through automation, and I was very focused on quality, teamwork, careful observation, and debugging; all things you need to ship something worthwhile, regardless of role. Once I did switch, that made future job changes easier, and I felt I was able to write my own ticket to better things. Since then I've made it a point to focus on quality first as both a developer and tech lead. Our work isn't capital-D Done unless it works correctly, and we're all responsible for doing the work to verify that.

I was there when Microsoft started retiring SDETs. I was in Bing when it first started. They did convert most SDETs in Bing to SDEs at that time ~2011, they however left end to end SDET team intact and we continued doing CICD and test automation. Having 20 + years in test automation and focusing on agile transformation and CICD recently I do believe that developers can do majority of the unit test and functional automation, there is however still lots of work left after that for end to end/customer scenario automation. If done well it can speed up your delivery, improve quality/customer experience and decrease amount of time spent on fixing bugs in production. I dont think SDET is ever going out of business honestly. But I do think the ratio of SDETs in the current world doesnt have to be that high. I managed a team of 8 SDETs supporting 100 people organization devs and I think we did a great job at that.

I went through the same transition in Microsoft at the same time, and felt that the company lost a great resource. There had been cases through the company, such as SBS, where newly-minted SDEs promptly left for other teams, leaving legacy SDEs to do both dev and testing work without additional support. Those legacy SDEs promptly left as well. To me, there's just no substitute for a great SDET. The quality of Microsoft products since getting rid of SDETs shows that quite clearly. In my experience, while a good SDET can usually also be a good SDE, the reverse does not apply. SDEs tend to pay lip service to testing, and quality suffers as a result.

Seems like a lot of human clutter. If you know how to write code decently then you know how to test code and automate things. If you don’t then you need to stay a junior developer until you learn. It is such a hassle, and slow down, having to constantly wait for other people to do what you could do for yourself. And we tend to write worse code because of silly pressures to comply with random demands instead of actually trying things and comparing the results.

I'm pretty sure I heard some SDETs' existence, but as contractors. This was some time between 2015-2020. Does that really mean the function of the role was obsolete?

The real mistake was getting rid of STEs in the early 2000s. Except we didn’t actually get rid of them… about half of the SDETs continued willing or unwillingly to be STEs. The value we provided was manual user mode testing done by core members of the feature teams who were involved from ideation onward, who knew how to code, how software worked, and how to break it. Automation produced little value by comparison. When SDET ended so did the huge shadow STE army, and quality tanked.