这是一个由在微软中国工作的测试人员组成的群组。该组成员有资深的测试经理，有工作过一段时间的很牛的技术人员，也有刚刚步入测试行业的新秀。事业阶段不同，所有的经历也不同。
作为在微软已经工作了1年半的一个小小的Vendor（SDET）,之间也面试了不少Candidates，一直想说说我的想法，只是一直不知道该怎么说。今天，我觉得应该把我对测试的理解和微软面试的理解拿出来给大家分享。
这次说的是开发与测试的关系。
我们项目组是以SDET(开发测试工程师)为主的。所以我们招人的条件就是精通测试，熟悉开发。但是，我遇见很多有1、2年的开发经验的Candidates，当我们给他们介绍我们是做测试的时，他们马上说，我只想做开发。为什么，因为觉得做测试会让自己的开发技能减退。
我一直认为测试跟开发是相辅相成的（看得眼熟吧？马哲里的原话：），开发是锻炼一个人的能力，而测试则是锻炼一个人的思路。做过单元测试，会让你以后写代码时更加注意代码的可读性、简洁性、高效性；做过集成测试，会让你以后写代码时更加注重各个方法、类之间的联系；做过系统测试，会让你以用户的角度去思考你的代码和界面设计。我觉得一个开发人员，想向更高的层次走，去做测试是一个不错的捷径。
作为1、2年的开发工程师，正适合来做测试，哪怕最简单的页面测试（说白了就是随便点点）。可是他们却看不上测试的工作，认为那个是任何一个人都可以做的。真的吗？既然测试那么简单，为什么一个简单的login登陆界面的测试用例你们都设计不好呢？
测试不是任何人可以替代的，哪怕是简单的UI测试。测试和开发就像修汽车的和开汽车的。修汽车的人不见得都会开汽车，开汽车的人也不见得都会修汽车。但是，一个真正优秀的司机，应该是开车开得好，修车也修得好。测试是需要经验的。如果你用心作一年UI测试，一个新的UI来了，你会知道哪最容易出错，哪是用户最喜欢用的功能，这种经验是任何新人都取代不了的。这只是最简单的UI测试。而我个人认为的测试的巅峰---性能测试，它要求测试人员需要有完整甚至近乎完美的计算机知识。操作系统、编译原理、数据库、数据机构、算法、网络、计算机硬件等等，这些知识不是任何一个做开发1、2年的人都具有的！
开发工程师们呀，请放下你们的架子，可以适当的选择测试工程师或者开发测试工程师来做做。这是丰富你们职业经历，提升你们职业技能很不错的捷径。而且，即精通测试，又懂开发的人真的好少。。。。。
2007-09-05 08:42:04 被【xx1986】修改
说实话，没有做过测试的开发大牛多了。
很多SDET都是应聘不成SDE才转过来的。很多SDE确实不屑于做SDET。
2楼的大哥，您有没有看过《代码大全》？世界上最牛的程序员都看过这本书。但是这本书里至少有2章是在讲测试的吧？还有2章是在讲代码优化的吧？既然这么权威的一本书，都会涉及到测试，可见，很多牛的程序员其实都在做（或做过）测试。
而且，我说的是一种捷径，你的明白？不是必然的路。
SDET怎么了？至少做过2年以上的开发人员来我们这应聘的，没有一个适合我们的。原因很简单，基本的测试知识都不懂。连一个基本测试知识都不懂得开发人员，您认为微软会让他当SDE吗？
测试对开发来说也是一个基本功，不懂测试的开发人员当然不是什么优秀的开发人员。
测试和开发本来就关系非常紧密，没有人说过开发人员就不用懂测试。可是，开发人员的绝大多数的时间还是在开发上，而测试人员绝大多数是在测试或者测试开发上。显然，开发人员的技术难度要大于测试人员的技术难度。当然了，你硬要拿一些普通的开发人员跟微软的SDET来比，没什么意义。我承认，微软的SDET比一般的开发人员水平要高，可是你不能因为这个就满足呀？在微软里，开发人员明显还是比测试人员的能力要强一块。所以，很多测试人员到达一定水平之后转开发了，很少有开发去转测试的。你看看SDET和SDE的级别就清楚了。SDE的高级人员人数明显要多很多，SDET就比较少。
其实对于很多开发的来说，能在微软做好SDET就很不简单了。并且，SDET本质上还是开发工程师。我明白你的意思了。我的意思是，开发工程师的水平也参差不齐，牛的人没必要一定要转到测试做来提升自己。当然了牛的人还是不多的，因此对大部分开发工程师来讲，确实需要好好看看你的文章，思考一下。
有一点不太理解，你是Vendor派去微软做SDET的吗？还是你选派人去微软工作呢？你做了一年半就参与面试了？那很牛呀。
我没在微软不知道STE和SDET都做些什么，但是前后在国内2家公司做了5年多的黑盒测试后，发现，测试工程师还是要对开发多了解一些，才能对自己的工作有所帮助。现在国内大大小小的公司在软件开发流程上都及其不规范，开发没有相应的前期需求分析、可行性分析、概要设计、详细设计这些就更不用说了，没有，研发工程师们根据自己的想法，想做成什么样子就做成什么样子。最后扔出来个东西，给测试工程师说，好了，你拿去测吧。没有任何文档，怎么测？
所以现在对我来说也就只有尽自己的能力和经验来尽量维持产品的稳定。
老板的意思，我们是要赶进度，有的东西能省就省了，不需要。只要产品能出来能卖钱就行，公司以后做大了会一步步完善开发流程的。
对，比起开发需要懂测试，测试更需要懂开发才行。
明白了。谢谢。有时间多交流。
对了，你做SDET以前做过开发吗？如果做过，做过多久呢？如果没做过，都是自己学的吗？
看到搂主的帖子，很开心。这才是微软中国研发部门最生动的例子。可以很自豪的说，在微软总部或其它地区，不可能像这里一样，有那么多编程水平很好的测试工程师。他们用自己的聪明和努力搭建了许多自动化测试工具。记得我在参加一个培训的时候，培训师来自于美国总部，当他得知某一个组仅需要10个小时就可以做一遍完整的功能测试，不包括压力测试。他很是惊讶，因为在他看来，那至少应该需要三天的时间。而就在同时，另一个组的测试工程师却很不以为然地说，我们组只需要5个小时...
这只是一个小小的比喻，这些测试时间当然取决于你的资源，测试规模等等。我只是想例证，在这里，100%自动化是我们追求的目标。而这些，在别的地方是见不到的。虽然，大家都在努力做到这一点，因为中国研发集团需要面对的“历史遗留问题”很少，可以轻装上阵。所以，这里的SDET可以算是最幸福的测试工程师了，他们在做的都是具有挑战性的工作。
另外，很想在这里反驳peking2toronto：
你说：“你看看SDET和SDE的级别就清楚了。SDE的高级人员人数明显要多很多，SDET就比较少。”那只能说，当年的level设置的就不对，一个tester为了从ste变成sdet要花好久好久的时间。真的是大部分的时间都消耗在了进阶level的路上。另外，很少有人真正知道如何从一个test manager变成一个group manager，也成了一个使很多希望“升职无障碍”的员工离开测试职位的原因。可是，这些都是过去了。office 的一个CVP，来自于test discipline。Windows SI的一个VP也同样来自于test discipline。公司在努力改变现状，所以，STE变成了外包。tester也一样要强调engineer excellence... 所以，以后更高level的tester会有很多的。
不知道你到底反驳我什么？如果你反驳我说的这句话，“你看看SDET和SDE的级别就清楚了。SDE的高级人员人数明显要多很多，SDET就比较少。”你下边的论据整个都是支持我这句话的。你这里说了一个自己理解的未来的情况，还不知道什么时候能得到证实呢。用一个没有经过证实的预测来反驳目前的现实情况，逻辑不通吧？
你要是想反驳我的这句话，就应该证明SDET的高级别人数等于或者大于SDE的高级人数才对。如果想预测未来的SDET的情况，我们应该单独讨论。
还有就是你举的这些例子都是以偏概全，不能代表整体，我很容易就拿出反例来反驳，不过我觉得没什么意思。
汗一下。accat ，peking2toronto ，不要争了，从你们的言论中我感觉可能你们都在微软（或者正在微软）干过。既然这样，大家都是同事了。我感觉每个组的情况是不同的，我们这里有的组就是SDE和STE，而有的组全是SDET(我们组是这样的)。工作不同，职责不同：）
不过我还是觉得做开发应该去尝试着做做测试。而做测试也应该去学学开发。软件工程是一个复杂的系统工程，各阶段各科目都是相互渗透的，不能单独孤立出来任何一项来。：）
"很多SDET都是应聘不成SDE才转过来的。很多SDE确实不屑于做SDET"
这是不是事实。微软的面试流程是这样的，一般一整天面试，上午三轮下午一轮AA.在上午面试的过程中基本上不区分SDET和SDE。
面的内容差不了多少。下午的时候AA更多根据需要问一写SDET或者SDE相关的问题。有的时候下午AA的面试 SDE和SDET也没什么差别。
所以SDET不是应聘不成SDE才转过来的。
其实当初我投的职位有SDE和SDET，最后我自己选择了SDET。并不是我自己面SDE没过，因为我平时的比较喜欢hacking and cracking所以我自己最后选了SDET.
在公司内部也有SDE转SDET的。
另外 SDET和SDE其实没有谁牛谁不牛的问题。革命工作没有高低贵贱，只是分工不同罢了。
SDE比较喜欢创造， SDET比较挑剔，比较喜欢破坏。
另外广告一下：
如果有路过的网友平有对hacking 比较熟的（not script kiddie ），对操作系统原理理解比较深入的。其实SDET这样的职位很适合你。
想想不用反汇编，不需要挂softice就能研究一些底层原理，说不定还有一些文档，如果找出产品的漏洞还发工资这样的好事。多爽阿~~
2007-09-12 08:08:23 被【goldcattle】修改
peking2toronto 兄弟，你17楼的说法我很不赞同。拿前天我写的一个调用com接口返回windows的schedule task里的所有task信息的小程序来举例子把。比如是你开发好了，你不能编译一遍没有报错就没有问题提交代码了吧？总得走通几遍吧？schedule task里有task的情况，有一个task的情况，有多个task的情况，没有task的情况，至少这3种你得debug一下吧？其实这就是测试了。我绝对不相信开发人员写好代码编译没问题就说代码没有问题。何况，按照软件工程的理念来说，单元测试应该是由开发人员做的。而且，不知道别的项目组怎么样，起码微软我这边接触到的，你提交代码时一定要证明你写的代码是正确的。怎么证明？一般开发人员在提交代码的同时会附带提交Unit test的代码。
由此看见，开发人员是离不开测试的。既然这样，何不花些时间做做测试呢？做web开发的我认为可以去尝试做做web测试，到时候你会发现当初自己开发几个晚上觉得很玄的功能在客户（用户）眼里就是鸡肋。做底层开发的我认为可以去尝试做做单元测试或性能测试，这绝对对你以后的代码质量有很大的提高。
呵呵，干活了：）
回19楼，我从来没说过开发人员不进行测试的工作。我只是说开发人员没有太大的必要一定要转到测试这个职位来提高。你的例子也说了，开发人员的日常工作里就包含了测试，这与你文章里的话“开发工程师们呀，请放下你们的架子，可以适当的选择测试工程师或者开发测试工程师来做做。”是相矛盾的。我的意思是，开发工程师完全没有必要一定要转成测试工程师来提高职业技能，因为他们的工作已经包含了测试的内容。相反，测试工程师倒是很有必要再开发的职位上做做来提高自己的开发技能。你也说过了，很多人干了2，3年测试还不会编程。
再强调一下，我的意思是开发工程师没什么必要一定要转成测试工程师，而测试工程师很有必要去开发的职位做做。你举的例子都完全符合我的这个观点。你自己的观点是有些自相矛盾的。一方面让开发人员转到测试提高技能，另一方面又强调开发的工作离不开测试。既然离不开，干嘛偏得转到测试呢？
回18楼，你是以偏概全了。用你自己的例子来当作一个通常的情况。我有大量的例子说明，很多人想做SDE可是由于达不到要求而做了SDET，也有大量的例子SDET转到SDE。我还没见过有人放弃SDE而转向SDET的，可能你是我见得唯一一个。可是比例太小了。从我的观察与经历，目前没有根据来推翻我的那个观点。另外，在微软，开发比测试的地位高也是不争的事实。不但在微软，在任何公司都是这样。当然这是一个普遍的现象，不代表100%，有的测试人员水平牛，地位比很多开发还高，是有的，可是毕竟是个例。如果论牛的话，开发大牛比测试多多了。
从DEV转TEST,还是从Test转DEV，还是Test 转PM在公司内部都是有的。这三个基本职位直接转来转去本身是个很正常的事情，不存在地位谁高谁低的问题。可能你对你org外的人不是太熟悉。ATC内部就有SDE转SDET的，还有从DEV lead转成 test lead, 然后再转成PM lead的都有。
至于技术，起码在hire人的时候，在技术面试的时候是不区分test还是Dev的。
技术牛不牛看个人修为，junior的DEV在code review时被Test 批得抬不起头也是常有的事情。另外在一些incubation的项目中，test和dev都不怎么区分。
另外在大型的项目开发中，谁牛不牛是个伪命题。因为首先是team，然后才是个人。
我想还想纠正楼上的一个误区，认为test 不重视开发技能。Test 和DEV一样都会在项目比较松的时候不停地学习新的开发技术。
在国内确实有很多公司包括有一些外企，对测试的重视程度不够，无论在薪资上还是在机会上都不如DEV，但微软不是。
这一点你可以问一问你认识的SDET FTE。
好像你对你的org外的人不是太熟悉吧？ATC不能代表微软吧？微软几万员工，ATC才多少？
我没说test不重视开发技能，我是说楼主举的例子，很多人做了几年测试还不会编程。楼主提到的那些开发的也不是微软的人呀。
如果放在微软内部，我想没什么意见。可是如果作为一个general的论题来讨论的话。搞测试的更应该去开发职位学习一下，而不是搞开发的应该来测试的职位学习一下。你也说过了，“Test 和DEV一样都会在项目比较松的时候不停地学习新的开发技术”。可见，你的例子又是完全支持我的观点的。除非你说，DEV会在项目比较轻松的时候不停的学习新的测试技术。呵呵。从你的例子来看，也验证了，测试应该学习开发，而不是开发应该学习测试。
理想状况下，dev和test是矛和盾的关系，所以应该不分高低。
现实当中，许多公司不重视test，哪怕是MS，也会因为工作内容、发展前景等原因，造成统计上dev比test牛人多的情况。
理想状况下，既然dev和test一样牛，应该可以在discipline之间自由转化；转职体现的是工作兴趣和学习愿望。
现实当中，转职不仅仅是兴趣和学习，还有许多其它因素在里面，无论dev转test人多还是反之，数量都不能说明什么。
所以问题的关键是如何缩小理想和现实的差距，而不是dev和test谁更牛……
说的很好，跟我的观点一致。理想是靠自己努力去实现的，而不是靠举例子说出来的。
我觉得测试和开发是相通的，如果做不好开发，可以肯定的是测试也没戏。所以我们面试开发转测试的candidate的时候首先问得是赚得原因，诸如“开发比测试累”，“开发比测试难”，“做不好开发”之类的解答我们一般都是直接cancel掉了。
如果一个人可以把测试做的很好，那么他熟悉熟悉开发语言的话，我敢肯定他也会成为一个优秀的开发工程师。毫无疑问！
我个人认为
开发的人一般对测试的知识了解的不够，开发的人如果经过系统的学习的话，会发现，
测试中有许多知识，是开发的时候所用不到的新东西。
我的专业是软件测试，但是是专科的，所以我很犹豫今后要不要向测试行业发展，所以想问问各位前辈们，能不能给我点建议啊。。。小弟我感激不尽啊。
学历不是最重要的，关键要看自己的兴趣和能力适不适合。关于测试人员应具有的能力在别的帖子有很多讨论，就不在这说了~
我认为不出色的测试工程师和研发工程师也同样值得尊重
第一，出色的工程师都是从不出色过来的
第二，这个社会需要分工，出色的工程师有他的工作职责，不出色的工程师也有他的用武之地
第三，大家都是同类，是人不都得尊重吗？
声明：在这里我不主张区分什么出色的和不出色的，只是接上楼兄弟的话。
不过得承认，所有工程师里是有能力差别，能力强的不自傲，能力差点的（知道且正在奋斗的）不自卑，大家都是好样的。
大家好我是个新手，呵呵，可能提的问题会比较幼稚，希望大家见谅！
我是一名计算机学院的研究生，本科学的是数学，一直就想做软件开发方面的工作，但是每天就是这么想毕业要去做开发，真正为这方面准备的可能不是很充分，最近开始找工作了，连连受挫，前几天华为来招聘我应聘的是软件研发工程师，可是由于没有项目开发经验，被调到测试那面去了，可是我觉得自己不是很适合做测试，我缺乏耐心和上面高手们说的责任心，我想问一个弱弱的问题，有人了解华为的测试吗，如果一开始就做测试以后还能转回研发吗，大家也都知道华为是很累的，所以我怕没时间自己看一些开发方面的知识，怕以后就转不回来了，希望得到高手的指点，这个问题困扰了我好久了。
测试的一定要会开发的，这样才能在测试的道路上走的更远。
呵呵，挖坟也。
先自我介绍工作经历，2年STE(其中包括1年STE Leader), 后转为SDE至今。
在我看来一个优秀的STE其对软件项目的debug，乃至整个项目的成败所发挥的作用绝对超过一个普通的SDE，甚至可以起到引领SDE团队以最高的效率完成软件稳定工作。
但有一些SDE的东西恐怕也是STE永远也无法接触到，没有机会学习和掌握的。STE所作的只能是外围的辅助性的工作（当然做的好也可以起到决定性作用），只有SDE才能接触到软件项目真正的内核，掌握根本的工作原理。
模仿LS的最后说一句，测试的只有转到开发，才能在软件这条路上走得更远。
理论上懂的开发 会协助测试发现更多疑难问题
对于传统项目而言 代码复用是承接性项目的通病
N个产品基线以后 最可能发生的问题的就是复用后的代码
能知晓开发 对于测试而言 不仅仅把目光局限在黑盒逻辑上
更深层次的是为项目组提供产品风险参考与风险预警评估
比如对一些流程的预演进行推断等等
此举 可以为项目组乃至整个产品提供更好的数据流程及人机交互意见
当然无论是测试开发 白盒测试 还是自动化 都有局限性
最大瓶颈来自于项目架构 数据模型
如果从开发经理转测试经理 此块可能有很大的优势
项目后期 特别是临近上线 产品最大的风险来自于前期架构以及异常场景的考虑
毕竟为了修改问题单 而重构或部分框架 其成本是巨大的 风险是无法估量的
个人拙见 仅供参考