You can't build quality into products. You must start with a quality product then ensure you don't screw it up as you build it. I help minimize your chances of screwing it up.
Microsoft has never "done QA" This is an interesting article but it's deeply flawed from the start. Microsoft first had a role called a Software Test Engineer or STE. My first role in tech was at Microsoft as an STE "perma-temp" in the late 1990s. Software test engineers (STEs) were expected to know how to code. A decent chunk of my initial interview as a contractor was taken up with coding challenges and medium level dives into coding theory. The role of a tester with little to no engineering skills did not occur until sometime in the 2000s during the dot com bubble. Since everything "hot" was web based and branded, scores of non-technical contractors were hired to focus exclusively on user interface feedback and execution. With that being said, I do not want to imply I spent my usual 60 billable hours a week coding. Instead I used my knowledge and skills to pull open the hatch and explore the guts of the programs under test. Sometimes that meant I needed tools that other people also needed. When that happened we'd ask the developers assigned to our team to build it. These were the Software Development Engineers (SDEs) assigned to the test team. The were the SDETs. In addition to tool maintenance they'd also write code that tested the code being proposed for delivery. In nearly every case I can remember that coding process was deeply collaborative involving the STEs, SDEs, and SDETs. It was very symbiotic and it worked very well, from what nostalgia lets me remember. With the rise of using the external term "QA" to mean "non-technical testers" in the 2000s, the term SDET began to be used more and more for "technical testers." I don't think the term "software test engineer" is currently used outside of hardware or device production contexts (ex: self-driving cars, infrastructure, smart devices, etc). This is how the author (Gergely Orosz) can believably claim MS by the 2010s had teams with X number of SDETs with no STEs or QA. I won't comment here on how the later shift to remove all SDETs and transition to SDEs performing all testing impacted the products and MS brand. That topic has been hotly debated since Satya Nadella decided to go in that direction. I'm simply trying to correct the record as someone who was there using my anecdotal experience as a reference point. #softwaretesting #sdet #microsoft #softwarequalityassurance
Jon Bach
7mo
I was at Microsoft as a software testing contractor in 1995 testing Bookshelf and Encarta installation compatibility. My job was to find riskls and issues with setup from CD/DVD. I converted to a full-time test lead from 1997-2000, left MS and then came back as a contract tester in 2002. For each of my stints there, there were SDETs and non-SDETs as testers. SDETs were known more as toolsmiths at that time -- taking tests that needed to be able to scale or perform quickly or repetitively, but also making tools that aided investigation or discovery. Non-SDETs (like me) were explorers, often aided by test cases we would write, and those tools from SDETs. It was complementary and cooperative, as it should always be. When I was on Systems Management Server as an FTE ('97-'00) we worked in a dedicated test lab in building 24 with banks of computers -- no VMs yet. In that lab was a mix of dedicated feature testers whose job it was to design and write cases (called Test Case Engineers or TCEs) to work with other testers who ran them (called Test Executioners or TEs). I was a TE, and we always talked with our fellow TCEs. We often sat side-by-side and shared ideas in a constant effort to make each other better.
Sergei Sergejev
7mo
The transition succeeded differently and some newly titled "developers" still were dedicated testers in teams (I'm ex-Microsoft) Just recently there was a posting for such Senior Software Engineer for Teams: "Senior Software Engineer (C# or Python) We are building the Intelligent Conversation and Communications Cloud (IC3). Responsibilities - Design and build maintainable end-to-end functional and performance validation for MS Teams and Skype. - Build features to efficiently validate complex scenarios across various platforms and devices." https://jobs.careers.microsoft.com/global/en/job/1580117/Senior-Software-Engineer This is a classical SDET/STE job simply with a different title
James Bach
7mo
My brother Jon Bach was a tester at Microsoft starting in 96. He worked in three different groups. Jon is not a coder. I worked with Microsoft pretty closely from 1995. I was close with Roger Sherman, who was the director of testing. They had a conventional aporoach to testing. None of the people I worked with were coders. The SDET thing didn’t take over at Microsoft until around 2000. Which was after my contract to create the first formalized ET process completed.
Brad Thompson
7mo
I wonder if we will see posts like this when AI becomes more and more apart of development. Company X slowly removed developers over time. They found with only 1 developer it was easy to be more accountable for quality :) Thanks for sharing :)
Stuart Alexander
7mo
I wonder on if this is a localisation issue? QA doesn’t mean non-technical in london. A quick search of London job boards confirms that I’m not out of touch. I worked at Microsoft as a QA engineer as part of yammer, however they did keep changing the job titles to sdet then Swe but the role was the same
🎓 David Craddock
7mo
It's really irritating how the 'anti-test' movement has managed to not just turn people against testing in the present, but eradicate the long and established history of testing in software. Madness.
I was at MS for 12 years from 1999-2011 started at WebTV, then MSNTV, MicrosoftTV, MSN and lastly Bing. Started as an internal tools developer and finished as Senior SDET Manager. In our team we had our server lab with around 90 servers running builds 24-7, manage our code source repository and all the development tools used by the team. Our QA responsibilities were to build smoke tests, integration tests, end-to-end tests, and some unit tests. We also performed manual tests from time to time. Majority of our tests were automated so there was a lot of code writing involved. We worked very close with developers to minimize risk and meet the deadlines. We had a ratio of 3 SDE to 1 SDET. I can see how MS integrated QA into Dev teams requiring everyone to code. Although there were two danger areas as deliverables were always tight… one was that teams used more time to develop rather than test. Catching bugs earlier minimize risk and someone needs to Write tests in a granular form. The other area was that when you write code, in my experience, you are not the best person to test it. You need someone familiar with the functionality but with an outside view to get the most of it. For us to release more often automated tests were key.
Wendy Wen
7mo
I hope there's an in-depth discussion about this topic, because I truly believe where to put testers matters very much to the quality of a product. In short, we need both. However we have gone from one extreme to another. As someone who has about 10 years of roles on both sides, I do have much to say. A post will be on its way. Follow me if you want to listen to what I have to say. :-)
Viktor Kondin
7mo
Industry should simply stop considering e2e tests as something different rather than regular software product. It has own ROI (or does not!), impact, purpose, challenges, roadmap, etc... People who wrote e2e at least once are aware, it's not comparable with unit tests, because more "variables/objects" are involved + reasons mentioned above. As I understand, Microsoft simply changed their attitude towards engineers who are working on products, which simplify testing.
Observations on software engineering at Big Tech and startups. Writing The Pragmatic Engineer, the #1 technology newsletter on Substack. Author of The Software Engineer's Guidebook.
7mo(Update: we figured out the details with Curtis over DMs. I'm leaving this up for context: Curtis did not imply SDETs did not code - I misunderstood - but this was more about STEs) Hey Curtis - I am not sure where I implied that SDETs did not know how to code? All SDETs were software engineers and coded most of the time. They were hired, passing a coding loop or two. Most of them came from behing devs at other companies, and went on to work as devs at other companies. Maybe I was not clear about this: but they were software engineers (in the name!) who focused on writing automated tests + build test infra. Just not prod code (until the role was merged to SE). I wasn’t aware of the STE role though in the 90s on how it started. How is SDET different to STE though?