源自http://www.51testing.com/?uid-43726-action-viewspace-itemid-218487

不一样的SDET

　　首先，我要强调的是这篇文章讨论的是微软的Software Development Engineer in Test，中文翻译为测试开发工程师，简称SDET。不同于以手工或者脚本帮助测试的软件测试工程师(STE, Software Test Engineer)，SDET是用编程方法结合正确的测试方法学来确保软件符合正确的设计和用户的需求，这里强调的是用编程语言来设计程序并完成自动化的高效测试。下面我就细说一下我们SDET的不同之处。

　　首先，SDET和SDE具有一样的设计和编程能力，这是我们筛选简历的基本条件之一。无论在美国还是中国，我们从大学招来的SDET都要具有Computer Science的背景，不一定是Computer Science系毕业的（虽然有不少人的确如此）。几所美国大学甚至开设了软件测试博士站，我原来的产品组就聘用了一位软件测试博士。SDET的代码和设计要比SDE的代码(产品)还要有更高的稳定性和坚韧性（Robustness）。产品有专人（就是SDET!）来测试，一个版本一个版本地发布。但是SDET的代码没有这种阶段性，只要它要测的功能还在，SDET的测试代码就得执行下去而且得无误！即便测试的一线管理者，就是测试主管，也同样需要有开发、设计能力。

　　第二个不一样是对开发式创造性思维的独特要求。这种独特性体现在SDET设计的测试用例的完整性。SDET需要有开放性的思维，才可能设想到千千万万用户的各种需求，他们来自五湖四海，有不同文化、不同年龄、不同职业等等。同时，SDET又不能迷失在用户的个案中，需要从众多案例之中，选择有代表性的进行重点测试，以点概面，用有限的时间达到较高的测试覆盖率。

　　第三个独特之处是SDET的工作在微软软件开发过程中扮演着确保高品质产品的重要角色。因为SDET在整个过程中始终扮演着用户的角色，对一个产品从开始编写代码到最后发布的整个过程有全盘的了解，更能对用户的体验感同身受。SDET必须与PM、SDE紧密合作确保正确理解用户需求和产品功能设计的正确性，同时还要保证产品的可测试性。比如，一项功能或设计是不可测的或是用户不需要的，SDET可以要求PM或SDE修改设计说明或功能说明甚至提供修改意见。需要特别指出的是，SDET对软件质量的Sign Off也是微软所有产品中期和最终发布的前提条件之一。

　　SDET的职业发展

　　那么微软SDET的职业发展机会又是如何呢？总的来讲，和微软其他专业的同事大同小异，主要有几个方向：

　　·继续做SDET，级别一级一级往上升，责任和影响力也越来越大。有些产品组设有技术主管乃至软件测试架构师，一般不管人，其领导能力体现在技术上，负责整个产品的测试框架工作包括自动化系统的设计、新工具的开发和现有系统的改进等等。他们对这个产品组的贡献和影响力很大，不仅限于测试团队，甚至可以对Dev和PM等专业产生推动作用。

　　·乐于帮助他人成长的SDET可以选择往软件测试主管，软件测试经理等的管理人员道路发展。软件测试主管通常带领3至7位SDET，负责产品一个或几个关键构件的质量；软件测试经理监督一个产品组的测试工作，设计主要测试计划书和时间表，并经常会管理2至4位测试主管。顺便透露一下，服务器与开发工具事业部中国团队的总经理就曾经是一位测试开发工程师，并历经测试主管、测试经理，产品总监，测试总监等多个测试专业的岗位。很明显，这个过程需要具备战略性思维方式、有效沟通、团队协作，决策和执行等诸多能力。

　　当然，如果个人兴趣发生变更，技术带头人也可以通过一定培训转为培养、发展人才的管理人员，管理人员也可以回到技术带头人的轨道。SDET也有转为SDE或PM的，甚至转入技术咨询、支持或市场方向，最终的职业道路不外乎是上述的两个大方向。

SDET的日常工作

　　除了之前提及的在产品设计阶段审核并批准PM的功能说明和SDE的设计说明外，SDET也要制订相关的测试计划书和时间表，比如，为什么产品中必须提供这个功能，而不是其他的；为什么这个版本应该实现这么多功能；设计测试用例去决定什么应该测试，什么可以暂时放在一边，需要什么样的自动化测试系统，需要新的测试工具与否，测试所需要的时间等资源的预计等诸如此类。

　　在测试计划书和时间表审议通过后，每位SDET接下来的主要任务是用合适的编程语言去测试产品，需要考虑是共享他人的工具或代码，还是自己重写；SDET的代码的可维护性要很强，因为没有人给SDET写的代码找Bug，当然代码出错误，SDET得自己分析原因并进行修理。SDET同时不断找Bug，分析Bug产生的原因、跟踪处理Bug的进展。SDET其它的日常工作还包括对现有系统的改进，当前系统的性能报告等等。

　　SDET的乐趣

　　做SDET没有比找到厉害的Bug更高兴的了，这会让SDE折服，让PM对产品更有信心。成功的SDET会到处听到人们在讨论他或她找到的Bug。如果找到产生这个Bug的背后原因，大家更会竖起大拇指！

　　做SDET都想让微软其他人采用自己发明的测试方法或工具来发现新bug！SDET承担着微软公司内部的诸多系统和工具的开发和维护工作。许多工具被内部几万人使用，这些系统和工具的开发涵盖了所有开发产品所必需的流程，技术含量更加不俗。整个微软有数千SDET， 有在操作系统部的，在Office组的，在服务器的，做硬件的（譬如XBOX，ZUNE），更有Services。 他们的产品各不相同，如果能研究出一个通用并且高效的做法，其它组的人必然会欣然接受。我们服务器与开发工具事业部就有一位刚从大学毕业不久的SDET，工作第二年就开发了一个UI Compliance方面的自动化测试工具，已被多个中美产品组的测试团队广泛使用，并正在申请相关专利，这也是一件值得骄傲的事情。

　　最让SDET自豪的是用户喜欢使用自己测试的产品，并让他们的工作更轻松、便捷。

　　我还清楚记得我在微软的第一次发布产品的经历。那时我在MSXML组做SDET, MSXML3.0刚发布时，我总是惶惶不可终日，生怕说自己负责的那个领域有问题，或者是newsgroup上有人报告坏消息。一天过去了，没事，一个周过去了，还是没事，一个月过去了，还是没事，心情渐渐放下，自傲感开始上升。最后，几个季度过去还是没事，我就彻底放心，可以大胆地告诉他人，我们产品质量没问题，我做到了！

　　优秀的SDET

　　不是所有的Computer Science毕业生都适合做SDET，除了上文提到的设计和编程能力、独到的创造性外，一位优秀SDET还需要：

　　·有测试天赋；

　　·细心，什么都逃不过SDET的眼睛；

　　·能建立精确的bug报告，提供简洁和准确地重现步骤和调试信息；

　　·追求高质量的测试代码和测试工具；

　　·有主人翁精神；

　　·不断自我批评，寻找可能的测试遗漏点

　　·对自己的工作负责。

　　卓越的SDET

　　·主动拓展自身工作范围之外的技能和知识；

　　·能平衡产品质量保证与产品发布时限；

　　·是软件测试和软件测试原则的最佳传道者；

　　·愿意做任何能最终使软件发布的努力；

　　·在整个开发过程中始终被视作能解决问题的人物；

　　·不断推动软件质量和跨部门交流与合作。