Hacker News Reader

Comment by joycey | Hacker News Reader

They are not eliminating testing. This was really bad wording. When I interviewed in Redmond with Microsoft, I was told that Microsoft used to hire SDE's (software development engineers) and SDET's (software development engineers in testing) as two distinct positions. Now, if you are hired as a "software engineer", you are responsible for writing software as well as writing tests. This was done to decrease friction between what used to be the "software development team" and the "QA testing team", and hopefully lead to faster software releases.

View on HN

A developer can test their own code, but they will only test it through the paths that they are aware of and thus coded for. An independent tester needs to be there to explore different avenues and try things that a developer wouldn't have thought of. Developers do think very differently to users.

Yes, but that doesn't mean testers shouldn't also be developers.

Automation tests are as much code as the code they're testing.

But if you're working on software that actually matters, you're supposed to have some friction between the people building it and the people testing it. This is otherwise known by terms such as "independent testing" and "lack of bias".

Moving fast and breaking stuff is OK if you're building a web service that doesn't really matter. If Facebook falls over, the productivity at a significant number of businesses probably goes up.

On the other hand, if yesterday's OS security patch stops everyone's PC from booting this morning, or if a new version of your e-mail server has a glitch that means half your company can't log in to read their mail or even that important messages from customers are actually being lost, that probably comes with a cost measured in large numbers of dollars per minute at a medium-sized business, or if you prefer, in careers per hour within the IT group.

Software engineers should be able to test their own code. The faster they get feedback on their code and its impact to users, the better they understand the various cases and can strive for better quality. Having a separate QA team has a fairly long feedback cycle.

Ideally you'd get both engineers writing tests for their code as well QA teams for products.

Software engineers should be able to test their own code.

Indeed, but there is also a good reason that professional editors have new writing proofread or even technically reviewed by people other than the original author.

Maybe there's some subtlety that I'm not picking up here about Microsoft's previous set-up and/or the model they've been moving to under Nadella's leadership. We seem to have some past and present Microsoft developers around these parts, so perhaps their comments will clarify this. But as reported, this looks to me like a retrograde step, an attempt to be more agile and fast-moving rather than something likely to improve the quality of the finished product.

there is a separate, smaller "quality" team with a separate reporting hierarchy that is supposed to address this - that's where the reference to data scientists, etc. in the article comes from.

basically the idea is to split the SDET role into two - SE testing (closer to the code than SDETs used to be) and "quality" (further from the code than SDETs used to be). SDET testing, though not directly driven by the code structure, tended to be at a pretty low level driven by a detailed functional spec.

Reply on news.ycombinator.com