微软的SDE/T（即Software Development Engineer in Test）大致相当于其他很多软件公司里的QA（Quality Assurance），但又有所不同。用比较理论化的语汇来说，SDE/T在微软的工作是负责自动化测试和白盒测试。SDE/T通常需要编写测试计划、测试用例、测试工具和测试代码，需要做debug并尽量在源代码中找到bug发生的位置。SDE/T可以说是测试团队里的dev：从工作职责来说，SDE/T是tester；从日常工作内容和所需要的技能来说，SDE/T是developer。
对SDE/T这么一个特殊的工作存在很多的误解。一个叫David Larson的SDE/T Lead在我们公司内部Blog上写了一篇题为“SDET's wanting to move to SDE”的blog，纠正了一些常见的关于SDE/T的似是而非的认识：
As we continue to emphasize CS skills and our sdets become better developers, the issue of people wanting to move from and SDET to an SDE role will become more and more common.
People considering moving to dev often have a mixture of fact and misconceptions. I try to address the following common points of view:
"I want to move to dev because...
1. "I love to code." Generally SDE's do less coding than SDET's. Many people want to move to dev because they love doing development and want to do more of it. The reality is that there are often more design and process over-head in a dev organization than in test. It's not uncommon for a dev organization to spend several months in design meetings without writing a single line of code. I like to present the case of a guy in my last group that was in test, changed to a dev, worked there for two years and then moved back to test so that he could do more coding. I encourage them to talk with their lead about the type of work they love to do so that they can be given more of that type of work if possible.
2. "They get paid more." This may have been a hard truth before Comp 2000 but not so much today. It's often the case the sdet's are hired at a lower level or with lower expectations. We then work on training them and bring them up to the standards that already exist in many dev organizations. For someone with rock-solid development skills there are huge opportunities to mentor others, lead by example, and demonstrate skills that are in high demand in test. . I tell people that in test they can be super-star (with the corresponding compensation).
3. "I want the satisfaction of shipping something." This is a hard one because it often means they have not had the proper guidance from their peers and/or lead. Many IC's in test are not used to thinking of what they do as a "product". They think what they write is throw-away code. Their working environment does little to change this point of view. This results in tools that can't be used by any other group, tests that lack componentization, lack of documentation, and ignorance of good development practices. When a test organization has the institutionalized view that they produce internal products, then IC's starting thinking of shipping versions of a tool, shipping updates to common libraries they own, shipping test suites to be run by an SE team. The sdet gets to ship far more, far more often than dev. I encourage them to think of their work in this light and to spread the word to their peers.
4. "They are more respected than testers." First off I tell then that they are not just testers. They are developers that work in a test organization. That's what it means by SDET. I then talk to them about ways they can work with PM, DEV, and the rest of their test team to insure that everyone knows what they have to offer in terms of development skills. I give examples of teams I've worked on where the people in dev would often go to an sdet for advice. They did this because the sdet had proven and demonstrated their competence, skill, and professional expertise in CS knowledge and skill.
5. "An SDET is a stepping stone to dev." Sometimes this is the same as the respect issue. Sometimes the person thinks that they weren't "good enough" to be a dev and to move to dev is a mark of success for them. This point of view is usually motivated by something else that's covered in the previous points. Ask more questions, specifically try to find out why they had the goal of being dev, then address those points individually.
However, I want to stress that, for the good of Microsoft, we have happy employees. Regardless of the career direction a person wants to go in, if it's good for the company then we should support it and give as well-round advice as possible.
做一个SDE/T的确是很幸福的事情：可以写更多的代码，写起代码来自由，只要能保证feature/code coverage，怎么写都可以，界面可以ugly一点，功能自己决定，想加什么就加什么，还可以把自己的名字放在About对话框里让用的人都知道是我写的。而dev就不行：不能署名，加了新feature要改code，feature被cut掉了code还要再改，fix bug的时间多于写代码的时间，大部分的日子里都要面对着长长的active bug列表。难怪我身边很多SDE/T都不想转去做SDE。