|
|
关于微软SDET职位，是一个很有争议的话题。
我不想说SDET多么多么好，也不想说它多么糟，这里我以一个微软（总部）SDET的身份来讲一下，给大家最真实第一手的资料。
国内的SDET，似乎大多是外包的vendor，比如中软什么的。就算美国这边，vendor公司来的SDET也很多，做的工作的确比较枯燥无聊，我个人是在windows，以前team里面除了我们这些正式sdet，还配了一个vendor的sdet，对方的职责就是每天把我们的测试工具（已经完全自动化了）跑那么几遍，比如在x86上跑一次，amd64机器上跑一次，windows client跑一次，windows server跑一次，然后如果有问题，就给我们正式的发邮件让我们去看怎么回事情-----呃，我有时候觉得他们能坚持这种工作也算是很有耐心了。
有些vendor sdet会稍微有挑战性一点，比如在跑我们的自动测试工具时，发现了问题，有些sdet会自己去debug，把bug找到，然后再给我们很仔细的报告。嗯，从vendor的角度来说，最多就是做到这样了。
vendor sdet开发测试工具？我反正从来没见到过，有的话估计也就是他们自己team里面用。
（说一下vendor sde，核心产品组很少有vendor sde，其它一些不太重要的，比如MSIT（对微软内部服务的IT部门）有不少vendor sde，还有些偏business的也不少,windows/office/包括bing，都很少有vendor sde，xbox那边好像也有一些）
vendor说完了，来说微软正式的SDET。
的确，微软对SDET的说法没错：Software Developing Engineer in Test. 作为一个SDET，你不可以避免开发测试工具，而全自动测试工具的开发更是极大的挑战，要自动控制多台机器？用socket呢还是用.NET remoting？测试底层驱动写底层filter driver，多线程控制／同步，各种底层Win32的调用，包括一些SDE也不会用到的算法和framework的设计，这些都是一个SDET日常工作的一部分。微软的SDET，的确可以说跟其它公司的QA/SDET有本质差别，我有几个朋友跳槽去了加州硅谷那边，他们就是说那边的所谓ＱＡ／SDET都基本上是不写代码的，不想微软这边的SDET，写代码是重要工作之一。
我看到有篇文章说微软的senior SDET很少，Principle SDET更少，呃．．．那篇帖子大概比较早了，现在微软里面的Senior SDET是很多了，Principle SDET．．．这个还是少，本来priciple的sdet也好／ＰＭ也好／ＳＤＥ也好，本来就不多。
上面说的主要是微软SDET在开发方面的工作内容，和SDE不同的一点是SDET在很多时候需要更广泛的技能，比SDE更广的技能。最简单的例子，一个做底层驱动的team，SDE就是纯粹用C开发，而SDET除了需要用C来测试API之外，还要开发自己的自动化testing tool，这个就由SDET自己设计，用C\C++\COM\C#\...随便你用什么方式都可以。所以有种说法是：SDE是Depth first,SDET是Breath First.
此外，对SDET来说，很重要一点是对Scenario的设计和测试。对SDE来说，只要实现特定功能就行了，说穿了就是我这几个function或者我这个component保证是正确的就可以，而对SDET来说，要测试的不单是某个具体function，一般来说要用程序模拟（自动模拟）用户行为，而这个模拟通常会涉及到很多不同的component，不单单是你自己team的部分。在这方面，往往是那些做过多年开发转过来的sdet比较好，他们比较清楚通常用户会有那些需求会容易在哪些环节出问题，也就能设计比较好的测试案例。
从设计开发上，对于每个新功能，微软的SDET是有责任并必须跟SDE一开始就进行讨论分析的，这个讨论分析并不是简单的讨论如何测试，而是会讨论如何实现这个功能，用什么数据结构，API如何设计，算法是否合理。作为SDET，这是份内的工作，SDE只有在跟SDET完全讨论过之后，双方达成共识，才能开始写代码（关于这个我后面还要说说），所以说在技能上，微软的SDET跟SDE的要求是一样的，不然根本无法一起开会讨论分析。实际上，在这方面做得好的SDET，都是那些曾经有过多年开发经验，对难点、解决方法、容易出现的问题都很熟悉的人才能轻松指出SDE设计中的问题所在，一般新手SDET还是比较难以在一开始就达到这一点，这个就是看经验了。
另外软件测试在学术研究中也有一席之地，近几年有变热的趋势，如何优化测试数据，用尽可能少的测试数据来覆盖尽可能大的范围，这也是data mining和相关算法的研究方向之一。
上面说了SDET对开发和技能的要求，想来大家应该清楚了SDET的确在技能上的要求很高，从总体要求来说，并不低于SDE。
但是，我实话实说，从我自己角度来说，我想离开SDET这个职位的原因如下：
1. 虽然SDET也写大量代码，一般来说SDET的编程开发工作和测试案例设计(test case design)大概平均是50%:50%，如果你在开发上愿意多花点时间，你的工作用70%时间都在开发也是可以的。问题在于，无论如何，开发不是你的工作重点，你的工作是测试别人的程序，你开发的工具再怎么好，再怎么复杂，再怎么高效，其目的总是帮助你测试其它产品，你老板不会关心你用了什么算法来提高运行速度。当然，你也可以努力让你的工具具有通用性，让其他人或者其它组也能用（这种例子在微软里面很多），但是，again，你能做到这一点，是你的bonus，但是除非你真的非常有时间，或者愿意耗出非工作时间熬更守夜去完善你的工具，一般来说很难做到这一点，因为这不是你老板要求你的工作重点，你老板对你的要求是把那些测试案例设计完并能自动运行。
2. 作为SDET，会跟很多部门打交道。有说法说微软里面SDE的“地位”高，这有点偏颇。更准确地说，微软，至少是windows里面，对某个具体功能，如果其它组遇到问题或者需要帮忙，比如说怎么我的程序按照msdn的做法却跑不起啊什么的，第一选择是找SDET，而SDE作为“尽量不要去打扰”的对象，在迫不得已的时候才去问。虽然我现在不是SDE，但是平时的了解就是SDE大部分时间只需要埋头写代码，拿自己办公室里面的机器调试，然后check in 代码就好了，其他基本不管。而SDET除了写自己的代码，还要很多其它组交涉（微软分工很细），比如什么自动化测试lab，什么build lab,还有其它杂七杂八的组，因为你的测试工具要交给其他组去自动化运行，而其它组的自动运行方式又各不一样．．．总之麻烦事情很多。当然，这也不是什么坏处，作为一个SDET，如果你帮很多其它组解决了问题，这可以成为升职的一个有利因素，对于那种比较积极，热衷于跟多个部门打交道的，这其实很不错。
3. 某些公司，或者某些SDET的工作，需要做大量的工具设计和开发，难度相当高。但是，如我前面所说，SDET尽管需要比较多样化的技能，作为SDET，你也许需要同时熟悉C\C++\C#\Powershell\SQL\etc.，而且这都是你在某个项目中需要大量使用的技术，但是，对于某个特定方面（比如你在测试的那个功能），毕竟你没有实现代码，这方面还是有差距。我前面说了，SDET会跟SDE一起分析功能的实现，但是那仅限于“纸上谈兵”，你可以跟SDE讨论整个架构实现的问题，可以去讨论数据结构如何设计，但是SDET的职责仅限于“讨论”，最终的实现仍然要SDE去做（分工如此），而很多实现中的细节和难题，不可能一开始就讨论到，仍然需要SDE自己去解决。打个简单的比方，假设某个功能需要用一个hash table，SDET知道会用hash table并也许会对其设计test case，但是这个hash table的实现，仍然是SDE去做。这就造成一个问题，虽然SDET可能开发了很好的工具来测试某个功能，但是对于这个功能本身（打个比方说DirectX或者TCP/IP协议）的实现，他并不如SDE了解得透彻，这是很容易发现的，因为很多细节问题，只有亲手去实现才会碰到。这会有什么问题呢？这个问题就是在你跳槽的时候，如果想转developer会很不利，拿前面的例子，你去面试，你说我们什么什么东西里面用hash table怎么怎么样，别人说好啊，那你来写一下代码实现这个hash table吧，如果是SDE，这是已经做过得工作（并反复修改过各种bug），如果不是太久远的project，马上就可以轻车熟路写出来，还可以大谈我当时做得时候遇到过什么什么问题并怎么怎么解决了。而对SDET，你毕竟没有亲手去做过，所以能力强的也许能当场实现，弱一点的就歇菜了...好，假设你说我就是对测试工具开发感兴趣，我不喜欢开发，我仍然去应聘SDET，问题是绝大部分公司并没有微软这样重点开发自动测试工具的SDET职位，大部分就是简单完全手工测试的QA，基本无须写代码。如果你仍然对programming感兴趣，那些QA的职位你是不想要的。
当然，如果你就是喜欢纯粹的QA,那么微软SDET的经验会是很好的背景。
写了这么多，我有点担心是不是泄露内幕太多了，在我停笔之前，我总结一下：
SDE: fix bugs, design/develop new features in products
SDET: find bugs, design/develop testing tools(if necessary)
还有种说法，我听过有人说：在xx组里面，其实SDET干的活也跟SDE差不多了。
我对这种说法就不发表评论了，反正我从来没听过有SDE说：我们干的活跟SDET差不多。
[ 本帖最后由 ffonline 于 2010-5-23 10:50 编辑 ] |
|
/1 
关于我们
发表于 2010-5-23 10:40:45
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
微信
收藏
置顶服务
换色服务
楼主
