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
·主动拓展自身工作范围之外的技能和知识；
·能平衡产品质量保证与产品发布时限；
·是软件测试和软件测试原则的最佳传道者；
·愿意做任何能最终使软件发布的努力；
·在整个开发过程中始终被视作能解决问题的人物；
·不断推动软件质量和跨部门交流与合作。
版权声明：本文出自huoxingyinzi的51Testing软件测试博客：http://www.51testing.com/?43726
