基本上差不多啊
就是编程不行靠忽悠

引用:

原帖由 cleverman 于 2007-11-27 14:01 发表
从目前的情况来看，对很多人来说能够外包到微软就已经算是一份很好的工作了。比如楼主，还有很多羡慕他的人。可是转成FTE的机会又微乎其微。请问，从长期来看，这些外包人员应该如何发展呢？还是可以安于现状就满足了 ...

很多OnShore归来的Vendor都会选择跳出外包去做Dev，而OnSite的Vendor一般也会选择去做Dev，很多国内公司对这些人很感兴趣。

如果想赚钱，那在外包呆着，如果日语不错，强烈建议赴日外包，月薪不比微软的FTE差，如果想做点成绩，那就跳出外包。

引用:

原帖由 barcelona 于 2007-11-27 15:50 发表
基本上差不多啊
就是编程不行靠忽悠

混过面试就可以了，平常用不到怎么编码，就算要写自动化测试代码，也有前人的例子，改改就出来了。

引用:

原帖由 lotuis 于 2007-11-27 16:09 发表

混过面试就可以了，平常用不到怎么编码，就算要写自动化测试代码，也有前人的例子，改改就出来了。

修改前人的脚本，这个是公司流程完善的一种做法，能够尽可能的减少开发工作量。

当然，这也从一方面限制了个人的创造性。

我个人对这种方法不置可否，如果前人是一个很牛的人，那么确实能够减少很多工作量；如果前人的脚本逻辑不清晰，而且技术平平，那简直比让我重新开发还要难受。
因为更新脚本所计算的工时，与开发新脚本的工时是不一样的。一个很烂的脚本让你更新，你所花费的时间绝对要和重新开发这个脚本的时间不相上下，而计划安排的时间却可能只是6-8小时。
从一些印度人写的脚本来看，我感觉也都是技术平平。可悲的是，这些测试工作，竟然都是由印度人和中国人来担任的。

引用:

原帖由 seifer1754 于 2007-11-27 17:15 发表



修改前人的脚本，这个是公司流程完善的一种做法，能够尽可能的减少开发工作量。

当然，这也从一方面限制了个人的创造性。

我个人对这种方法不置可否，如果前人是一个很牛的人，那么确实能够减少很多工作 ...

我不知道你是否是给微软打工的，对微软的Vendor来说，所有Test Code在Check-in之前必须要给专门的Code Reviewer评估，评估通过了，你才能Check-in。同时，那些Test Code都是按照专门的模板编写的，注释之类的信息十分完整，一般不会出现晦涩甚至恶心的代码。而且微软的test code有个潜宗旨就是“功能第一，性能无究”，只要能达到测试的效果，性能并不需要太过考虑。

引用:

原帖由 lotuis 于 2007-11-27 18:00 发表

我不知道你是否是给微软打工的，对微软的Vendor来说，所有Test Code在Check-in之前必须要给专门的Code Reviewer评估，评估通过了，你才能Check-in。同时，那些Test Code都是按照专门的模板编写的，注释之类的信息十 ...

你说的流程，我所在的公司也同样使用。
不过为 Test Code 作 Review 的人就一定是高水平的人么？
基本上都是同事之间相互进行Review吧，当项目工时紧张的时候，每个人都要分配Code Dev 和 Code Rev 的工作，
我想，在Review的过程中也不会太认真吧。
况且有可能同一个项目，印度方面做前期Build 的测试开发，中国地区作后期Build的测试，那么你要针对别人的脚本作更新，
由牵扯到设计风格的问题，不适应自然是难免的。

引用:

原帖由 seifer1754 于 2007-11-27 18:35 发表


你说的流程，我所在的公司也同样使用。
不过为 Test Code 作 Review 的人就一定是高水平的人么？
基本上都是同事之间相互进行Review吧，当项目工时紧张的时候，每个人都要分配Code Dev 和 Code Rev 的工作，
...

Vendor从来就没有权利Review，何来的同事之间Review呢？一般都是总部项目组中资深的Dev做Review。。。。

引用:

原帖由 lotuis 于 2007-11-27 18:44 发表

Vendor从来就没有权利Review，何来的同事之间Review呢？一般都是总部项目组中资深的Dev做Review。。。。

看来微软对测试这方面非常重视啊。

我所在的公司，是相互进行Review的，所以在脚本的质量上参差不齐。

引用:

原帖由 lotuis 于 2007-11-27 16:07 发表

很多OnShore归来的Vendor都会选择跳出外包去做Dev，而OnSite的Vendor一般也会选择去做Dev，很多国内公司对这些人很感兴趣。

如果想赚钱，那在外包呆着，如果日语不错，强烈建议赴日外包，月薪不比微软的FTE差， ...

我一直强调的就是搞测试的转向dev是一条出路，可惜很多搞测试的不愿意承认这一点。甚至很多人说微软的测试比dev水平高，工资高。

引用:

原帖由 cleverman 于 2007-11-28 05:11 发表


我一直强调的就是搞测试的转向dev是一条出路，可惜很多搞测试的不愿意承认这一点。甚至很多人说微软的测试比dev水平高，工资高。

很多人不愿意承认是因为他们在测试上走得太远，已经回不了头了，觉得做Dev无法适应。。。。高不成，低不就，就像在国内进了外企圈子，往上难，往下也难。。。

至于微软的测试，我仅仅以我所在的项目为例，基本上是几个大牛Dev+一小堆普通水平的Dev+一堆Tester+一大堆Vendor构成的，论水平，Tester肯定不如大牛Dev，最多和普通Dev差不多，而工资待遇，一般Dev的Leader比较少，行政划分不像Tester那么复杂，动不动就是一个SDET Leader，所以待遇比起来不太公平。。。

测试为什么一定要转dev呢,做测试也可以做出样子来,水平高低也不一定决定一个人在公司里混的好坏程度,况且测试也能提高一个人的技术水平,并不是一定要开发的,而且国内开发这么累,多做对自己身体有什么好处,人活着不光为了工作.

微软的待遇应该是看级别的吧？如果lead的级别比IC低，待遇也应该低才对吧？

不是一定要转dev，只是一条出路。走向管理，做lead也是一条出路。
如果一直做SDET，好像做到senior都特别难，至少我知道都没几个是senior。一般就是SDET或者SDETII。
也就是说SDET到一定程度就很难往上发展了，想发展就要走其他的路了。还有就是senior SDET看上去好像也都作过多年的dev才有水平到这个级别的。
由于管理的路线不是人人都能走的，因此转dev就成了一条比较合理的路线了。当然如果你不想发展了，也就不用考虑那么多了。

看来不管是国内还是国外,要升上去都很难,有时候付出了也不一定有回报

引用:

原帖由 cleverman 于 2007-11-28 13:17 发表
微软的待遇应该是看级别的吧？如果lead的级别比IC低，待遇也应该低才对吧？

是按级别，虽然微软宣称管理和技术不同标准，但是不可否认除非是牛人级别，是PRINCIPAL或者次点的senior，不然Leader级别再低，也会比普通的员工要高，看看Offer时候的薪资标准就知道了。。。

我觉得也应该是这样。我想每年的bonus和股票，lead也会比普通员工要高不少吧？

倒是国内很多做管理的都是从国外回去的。

看来国外的月亮确实比国内圆

引用:

原帖由 cleverman 于 2007-11-28 13:21 发表
不是一定要转dev，只是一条出路。走向管理，做lead也是一条出路。
如果一直做SDET，好像做到senior都特别难，至少我知道都没几个是senior。一般就是SDET或者SDETII。
也就是说SDET到一定程度就很难往上发展了，想发 ...

貌似我从没看见过有Senior SDET。。。。。这不是技术或者实力能决定的，基本上行政划分就是如此。。。。
SDET,SDETII,Test Leader,Test Leader II, Senior Test Leader, Senior Test Manager, Principal Test Manager,
和SDET有关的职位就是这些了，从来就没听说过Senior SDET....到了高级别之后，就直接表明是Test了。。。。

除了SDE到了高级别还有Senior SDE和Principal SDE。。。。。

引用:

原帖由 cleverman 于 2007-11-28 14:04 发表
我觉得也应该是这样。我想每年的bonus和股票，lead也会比普通员工要高不少吧？

不到Manager级别很难有股票的。。。。。。普通Leader的工资外的收益并不比普通员工高很多。。。。。