i********n
发帖数: 251 | 1 有个问题
很多公司的dev/tester比率都是5/1或更高，而MS基本上是1/1
很多公司的pm/the rest比率都是1/15或更高，而MS基本上是1/5
这样MS应该裁掉更多的tester和PM吧？而且很多testing的东西都outsource到中国和印
度了，在testing position的童鞋应该赶快转dev了。
一家之言，欢迎讨论。 |
s********y
发帖数: 3811 | 2 it is happening now...
而且很多testing的东西都outsource到中国和印度了，在testing position的童鞋应该
赶快转dev了。
【在 i********n 的大作中提到】
: 有个问题
: 很多公司的dev/tester比率都是5/1或更高，而MS基本上是1/1
: 很多公司的pm/the rest比率都是1/15或更高，而MS基本上是1/5
: 这样MS应该裁掉更多的tester和PM吧？而且很多testing的东西都outsource到中国和印
: 度了，在testing position的童鞋应该赶快转dev了。
: 一家之言，欢迎讨论。
|
i********n
发帖数: 251 | 3 什么组？
【在 s********y 的大作中提到】
: it is happening now...
:
: 而且很多testing的东西都outsource到中国和印度了，在testing position的童鞋应该
: 赶快转dev了。
|
N********n
发帖数: 8363 | 4
Testing is fine as long as the guy is serious. Too many PMs is certainly
a drag.
【在 i********n 的大作中提到】
: 有个问题
: 很多公司的dev/tester比率都是5/1或更高，而MS基本上是1/1
: 很多公司的pm/the rest比率都是1/15或更高，而MS基本上是1/5
: 这样MS应该裁掉更多的tester和PM吧？而且很多testing的东西都outsource到中国和印
: 度了，在testing position的童鞋应该赶快转dev了。
: 一家之言，欢迎讨论。
|
s********y
发帖数: 3811 | 5 according to mini, it is across STB. most vendors are from china though.
【在 i********n 的大作中提到】
: 什么组？
|
i********n
发帖数: 251 | 6 "Testing is fine as long as the guy is serious"
which guy? the tester?
【在 N********n 的大作中提到】
:
: Testing is fine as long as the guy is serious. Too many PMs is certainly
: a drag.
|
r****9
发帖数: 250 | 7 中国vendor公司的测试人员干活勤快没的说，还特谦虚，水平也还好，但是和微软的测
试相比水平还差一些。据说印度vendor公司的不行，人很懒，不知道是不是真的。
【在 i********n 的大作中提到】
: 有个问题
: 很多公司的dev/tester比率都是5/1或更高，而MS基本上是1/1
: 很多公司的pm/the rest比率都是1/15或更高，而MS基本上是1/5
: 这样MS应该裁掉更多的tester和PM吧？而且很多testing的东西都outsource到中国和印
: 度了，在testing position的童鞋应该赶快转dev了。
: 一家之言，欢迎讨论。
|
N********n
发帖数: 8363 | 8
Yes, I"m talking about the SDET.
【在 i********n 的大作中提到】
: "Testing is fine as long as the guy is serious"
: which guy? the tester?
|
z***e
发帖数: 5393 | 9 我还是我以前的看法，QA就是QA，就是STE，就是无需coding只需跑test pass的人，跟
硅谷那边一样的，每个feature team有一两个tester跑test pass就可以了。
现在的SDET，如果coding能力真的强，而且也需要专门的开发测试工具，很好，那就是
tool developing team，仍然是SDE，而不是莫名其妙的SDET。很多test team都在寻求
该group里面的通用测试framework（因为每个test team自己开发了一堆），那还不如
一开始就是一个统一的tool development team.
还可以把部分SDET分散到dev team里面，主要负责unit test和相关tool的开发，同时
也负责部分feature developing.
我觉得这都是可以采取的方式。Dev+Test tool本来应该是不分家的，偏重dev或者偏重
test tool都可以，但是不该彻底分开。但是微软搞的是dev彻底脱离test（unit test
除外），而Tool+Debug+Test+QA混为一谈，这就是问题所在。
其实这真的不是
【在 i********n 的大作中提到】
: 有个问题
: 很多公司的dev/tester比率都是5/1或更高，而MS基本上是1/1
: 很多公司的pm/the rest比率都是1/15或更高，而MS基本上是1/5
: 这样MS应该裁掉更多的tester和PM吧？而且很多testing的东西都outsource到中国和印
: 度了，在testing position的童鞋应该赶快转dev了。
: 一家之言，欢迎讨论。
|
s***i
发帖数: 10182 | 10 test owner也不一定是简单的ste就能handle了的
况且很多东西并不是跑跑regression 这么简单
不过微软1:1的太nb了 这么多的sdet只能在微软和bank看到
test
【在 z***e 的大作中提到】
: 我还是我以前的看法，QA就是QA，就是STE，就是无需coding只需跑test pass的人，跟
: 硅谷那边一样的，每个feature team有一两个tester跑test pass就可以了。
: 现在的SDET，如果coding能力真的强，而且也需要专门的开发测试工具，很好，那就是
: tool developing team，仍然是SDE，而不是莫名其妙的SDET。很多test team都在寻求
: 该group里面的通用测试framework（因为每个test team自己开发了一堆），那还不如
: 一开始就是一个统一的tool development team.
: 还可以把部分SDET分散到dev team里面，主要负责unit test和相关tool的开发，同时
: 也负责部分feature developing.
: 我觉得这都是可以采取的方式。Dev+Test tool本来应该是不分家的，偏重dev或者偏重
: test tool都可以，但是不该彻底分开。但是微软搞的是dev彻底脱离test（unit test
|
|
|
i********n
发帖数: 251 | 11 想法不错
不过，我觉得得分情况
你有没有考虑过regression的情况？还有QFE？有的product像Windows Mobile，用户会
直接来custumise一个OS，如果有一个统一的test kit，用户可以直接拿来测试自己的
OS？在以上的情况下，etc，我觉得SDET是很必要的。
test
【在 z***e 的大作中提到】
: 我还是我以前的看法，QA就是QA，就是STE，就是无需coding只需跑test pass的人，跟
: 硅谷那边一样的，每个feature team有一两个tester跑test pass就可以了。
: 现在的SDET，如果coding能力真的强，而且也需要专门的开发测试工具，很好，那就是
: tool developing team，仍然是SDE，而不是莫名其妙的SDET。很多test team都在寻求
: 该group里面的通用测试framework（因为每个test team自己开发了一堆），那还不如
: 一开始就是一个统一的tool development team.
: 还可以把部分SDET分散到dev team里面，主要负责unit test和相关tool的开发，同时
: 也负责部分feature developing.
: 我觉得这都是可以采取的方式。Dev+Test tool本来应该是不分家的，偏重dev或者偏重
: test tool都可以，但是不该彻底分开。但是微软搞的是dev彻底脱离test（unit test
|
i********n
发帖数: 251 | 12 “印度vendor公司的不行，人很懒，不知道是不是真的”
我跟老印vendor从来没有什么好相处过
【在 r****9 的大作中提到】
: 中国vendor公司的测试人员干活勤快没的说，还特谦虚，水平也还好，但是和微软的测
: 试相比水平还差一些。据说印度vendor公司的不行，人很懒，不知道是不是真的。
|
b********7
发帖数: 12906 | 13 关键不是名份问题(DEV还是SDET), 重要的是在做什么事情. 这个跟产品也有紧密的联
系. 对于OS的底层来说. 普通的STE是不够的, 不是SDET写好AUTOMATION随便拿给
VENDOR就可以RUN的. 万一BREAK了怎么办. 外面的VENDOR不是那么容易了解KERNAL层的
东西的. 但是对ONLINE的很多东西来说, 比如LIVE SPACE, 我觉得90%让VENDOR来测试
就足够了. |
z***e
发帖数: 5393 | 14 "统一的test kit"---这就需要专门开发tool的team啊，比如WTT就已经算一个了。
关键在于，SDET被招进来的时候，强调的是开发automation tool和testing tool，听
起来不错，问题是实际上no one cares你开发了什么tool，你能够visible的就是fire
了多少bug，帮助dev处理了多少bug（其实就是帮一下repro）。我老板就经常说：我知
道你们都想去给我们的tool做一些fancy feature，但是repro bug这种东西虽然无聊，
但是没办法必须要做。
这些事情是无聊，但是是developing中的必要环节。无聊的事情，做了总得有意义是不
是？从公司的角度来说，这当然有意义，tester repro，然后dev fix，分工明确，看
起来多爽。问题是从engineer自己角度来说，我费半天精神就为了搭建一个repro bug
，然后怎么fix，怎么修改这些“有点意思”的工作和credit，就全部给dev了？dev有
时候还要怪你repro慢了，所以越来越没有motivation。
当然，tester如果很有动力，又是
【在 i********n 的大作中提到】
: 想法不错
: 不过，我觉得得分情况
: 你有没有考虑过regression的情况？还有QFE？有的product像Windows Mobile，用户会
: 直接来custumise一个OS，如果有一个统一的test kit，用户可以直接拿来测试自己的
: OS？在以上的情况下，etc，我觉得SDET是很必要的。
:
: test
|
y*******d
发帖数: 1765 | 15 pm in ms is totally different from other companies.
Dont mess them up.
Regarding testing, the problem is the elimation of STE, sdet has to do both
SDET and STE job, somehow that's not good:) |
z***e
发帖数: 5393 | 16 Exactly.
here is a good explaination:
http://blogs.msdn.com/b/chappell/archive/2004/10/06/239001.aspx
i believe the merge of sdet and ste is from some MBA's brain.
both
【在 y*******d 的大作中提到】
: pm in ms is totally different from other companies.
: Dont mess them up.
: Regarding testing, the problem is the elimation of STE, sdet has to do both
: SDET and STE job, somehow that's not good:)
|
z***e
发帖数: 5393 | 17 "万一BREAK了怎么办"
then it should go back to dev. As the XBOX director said, dev should and
must know his code broke and caused problem, then he could pay more
attention to the quality. If the dev feels the regression or whatever bugs
are so annoying, he should try his best to elliminate the bug at the very
beginning, instead of saying " this is by desing" "this will be fixed in the
next release" blah blah blah....
besides, i think "testing tool" or "simulation tool" should be a feature, not some irr
【在 b********7 的大作中提到】
: 关键不是名份问题(DEV还是SDET), 重要的是在做什么事情. 这个跟产品也有紧密的联
: 系. 对于OS的底层来说. 普通的STE是不够的, 不是SDET写好AUTOMATION随便拿给
: VENDOR就可以RUN的. 万一BREAK了怎么办. 外面的VENDOR不是那么容易了解KERNAL层的
: 东西的. 但是对ONLINE的很多东西来说, 比如LIVE SPACE, 我觉得90%让VENDOR来测试
: 就足够了.
|
z********o
发帖数: 4284 | 18 我老就是被骗进去做SDET的，好端端一个编程好手现在不大会写程序了
test
【在 z***e 的大作中提到】
: 我还是我以前的看法，QA就是QA，就是STE，就是无需coding只需跑test pass的人，跟
: 硅谷那边一样的，每个feature team有一两个tester跑test pass就可以了。
: 现在的SDET，如果coding能力真的强，而且也需要专门的开发测试工具，很好，那就是
: tool developing team，仍然是SDE，而不是莫名其妙的SDET。很多test team都在寻求
: 该group里面的通用测试framework（因为每个test team自己开发了一堆），那还不如
: 一开始就是一个统一的tool development team.
: 还可以把部分SDET分散到dev team里面，主要负责unit test和相关tool的开发，同时
: 也负责部分feature developing.
: 我觉得这都是可以采取的方式。Dev+Test tool本来应该是不分家的，偏重dev或者偏重
: test tool都可以，但是不该彻底分开。但是微软搞的是dev彻底脱离test（unit test
|
z********o
发帖数: 4284 | 19 勤快得不行了，以前我布置点任务过去，总是比我想象得快就搞定了。
【在 r****9 的大作中提到】
: 中国vendor公司的测试人员干活勤快没的说，还特谦虚，水平也还好，但是和微软的测
: 试相比水平还差一些。据说印度vendor公司的不行，人很懒，不知道是不是真的。
|
N********n
发帖数: 8363 | 20 SV's style of testing with that little manpower behind it is close to be
fraud. I've done quite some projects in CA, it's faking everywhere. |
|
|
l****l
发帖数: 3394 | |
i********n
发帖数: 251 | 22 WTT不是test kit。她自己不test任何东西
我说的test kit是指test某个product或feature的
fire
bug
【在 z***e 的大作中提到】
: "统一的test kit"---这就需要专门开发tool的team啊，比如WTT就已经算一个了。
: 关键在于，SDET被招进来的时候，强调的是开发automation tool和testing tool，听
: 起来不错，问题是实际上no one cares你开发了什么tool，你能够visible的就是fire
: 了多少bug，帮助dev处理了多少bug（其实就是帮一下repro）。我老板就经常说：我知
: 道你们都想去给我们的tool做一些fancy feature，但是repro bug这种东西虽然无聊，
: 但是没办法必须要做。
: 这些事情是无聊，但是是developing中的必要环节。无聊的事情，做了总得有意义是不
: 是？从公司的角度来说，这当然有意义，tester repro，然后dev fix，分工明确，看
: 起来多爽。问题是从engineer自己角度来说，我费半天精神就为了搭建一个repro bug
: ，然后怎么fix，怎么修改这些“有点意思”的工作和credit，就全部给dev了？dev有
|
z***e
发帖数: 5393 | 23 前两天的讲话有两个有意思，一个是我说的XBox的dev director，大力抨击PM/SDET的
设定；另一个是一个tech fellow讲他们设计WinFS的时候，就是一开始不要PM/Test，
结果blah blah就失败了，说是因为dev不清楚最终目标和goal什么的云云。
但是在Xbox那位的讲话中说了，这个世界上所有其它公司的Dev，一开始就自己要负责
test和处理customer issue，所以了解customer problem和testability一开始就是其
它公司的dev要考虑的，因为这是他的工作。但是在微软，把这两个重要因素人为的分
开，结果微软的dev自己在这方面就变得很弱，或者说很不care。比如你新建一个team
，打算不要pm/test，找一堆dev自己干，但是那堆dev已经习惯了有pm有tester，你要
他们全部包揽，虽然这在其它公司很正常，但是他们就会不习惯了，project也就会
fail掉。
所以，我认为SDE/SDET就不该分开，如果某个test kit是针对某个特定产品/feature，
那么这个test kit就是一个feature
【在 i********n 的大作中提到】
: WTT不是test kit。她自己不test任何东西
: 我说的test kit是指test某个product或feature的
:
: fire
: bug
|
b********7
发帖数: 12906 | 24 还是名份的问题. 叫SDET没关系, 我同意你说的, SDET主要精力不应该放在RUN TEST
PASS和REPRO BUGS上. SDET应该了解TESTING, 然后用它来DEVELOP TEST TOOLS. SDET
应该真的象TITLE说的一样, 是DEVELOP ENGINEER. 只不过DEVELOP 的是 TEST TOOLS.
现在MSFT基本上都是把SDET当STE来用..这个不合理.
team
【在 z***e 的大作中提到】
: 前两天的讲话有两个有意思，一个是我说的XBox的dev director，大力抨击PM/SDET的
: 设定；另一个是一个tech fellow讲他们设计WinFS的时候，就是一开始不要PM/Test，
: 结果blah blah就失败了，说是因为dev不清楚最终目标和goal什么的云云。
: 但是在Xbox那位的讲话中说了，这个世界上所有其它公司的Dev，一开始就自己要负责
: test和处理customer issue，所以了解customer problem和testability一开始就是其
: 它公司的dev要考虑的，因为这是他的工作。但是在微软，把这两个重要因素人为的分
: 开，结果微软的dev自己在这方面就变得很弱，或者说很不care。比如你新建一个team
: ，打算不要pm/test，找一堆dev自己干，但是那堆dev已经习惯了有pm有tester，你要
: 他们全部包揽，虽然这在其它公司很正常，但是他们就会不习惯了，project也就会
: fail掉。
|
z***e
发帖数: 5393 | 25 "SDET应该了解TESTING, 然后用它来DEVELOP TEST TOOLS" |
b********7
发帖数: 12906 | 26 again this is not the problem of what the title is..i'm talking about the
bunch of people who are supposed to develop test tools.
【在 z***e 的大作中提到】
: "SDET应该了解TESTING, 然后用它来DEVELOP TEST TOOLS"
|
t******e
发帖数: 98 | 27 同意。我们组里的技术最牛的一位senior dev曾静做过test lead,现在可说是test/
product infrastructure通吃。他写程序考虑非常周全很少出错，相比之下很多dev缺
乏测试意识，写出代码一堆bug.
【在 z***e 的大作中提到】
: "SDET应该了解TESTING, 然后用它来DEVELOP TEST TOOLS"
|
