※ 引述《viceversa56 (viceversa)》之铭言： : 以薪资来排行 : 程式>美术>企划>测试 : 以工作替代性来排行，同样是 : 程式>美术>企划>测试 [Susan] : 至於测试？只要会玩游戏的人都可以出任测试工作，资深和资浅之间的差异，并没有太大 : 的距离，前三者正因为他们有更重要的事情要做，才会聘请其他人来帮忙测试，这样的思 : 维反应在薪资上，测试人员永远是最低的，这条路是我曾经走过了，正因为我发现当初出 : 发时决定错了，才希望别人不要再步我的後尘，也不要说从测试工读生转企划，这样转的 : 过程，难道你们不会觉得如此企划很低廉吗？专业要求并不高，跟测试工作的距离并没有 : 太远啊！万贯家产不如一技在身，程式和美术就很得这「技」的精随，可是企划和测试又 : 如何呢？ 其实“测试”这个职位没那麽凄惨 :D 很简单的道理, 我们不会说: “科科，鲸鱼在陆地上逊毙了，一下就死翘翘了” 因为鲸鱼不能待在陆地上，也不能住在小水塘里, 只能住大海里 而测试就很像是鲸鱼: 难以养成的爽缺 XD 游戏测试算是 software testing 的一个分支 http://en.wikipedia.org/wiki/Software_testing 而测试的价值，就是降低出包的成本: http://stackoverflow.com/questions/4130051/software-development-costs-pyramid 有兴趣可以参考我的旧文，在供得起大佛的大庙里, “测试”是与程式 & PM 平起平坐的地位, 享有相等的待遇与福利，背负相等的责任 #1Fm-XgM_ (Soft_Job) http://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1338239082.A.5BF.html 有种说法叫“能力愈强，责任愈重”，反过来想: 要能扛起责任前，得先有那个能力 今天在游戏里碰到一个 bug, 有多少人能真的写出一份 bug report? How to Report Bugs Effectively http://www.chiark.greenend.org.uk/~sgtatham/bugs.html 有多少人能在纸上的 spec. 的阶段就能看出潜在的 bug? 有多少人能画出 threat model? http://en.wikipedia.org/wiki/Threat_model 讲最基本的，有多少人听过 test case / test plan / test automation 的这几个词? XD 所以说，“测试”这个职位没这麽凄惨 有那个能力就能扛起那个责任，能扛起那个责任就能争取那个待遇 小庙给不起那个待遇就跳到大庙去 且，因为有资源以战练兵练“测试”的大庙少，练出来的“测试”兵很抢手 这个是难以养成的爽缺; 当程式在爆肝，PM 在爆嘴时， 测试的工作就是鸡蛋里挑骨头, 挑出骨头人家还感谢你，超爽der XD --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 98.26.14.35 大庙有大庙的玩法，小庙有小庙的玩法，以下节录自我另一篇旧文 #1CkoWKzM (Soft_Job) http://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1287333908.A.F56.html 又，其实在我当助教前，抓抄袭也只是尽人事听天命， 因为一门课开六堂加起来快三百个学生， 就算人在美国也没有那个美国时间去慢慢抓 六个助教光改作业就改到爆炸了 後来我与教授们商量，把作业的 spec. 定严谨一点， 开个最基本的 interface 出来，就可以改作业的部分直接 JUnit 化 再写一些 script，把 「从作业上传系统取出原始码喂给MOSS先抓抄袭再自动编译 跑事先定义好的JUnitTestCase再依JUnit执行结果自动算 分数後编成表格一份全班分数给教授一份个人分数给学生 过程公平公正公开LOL」自动化 整个过程自动化後，那几个有抄袭的就被抓包了 XD ====================================================================== 原本改三百个学生的程式作业要 6 助教 * US$8 / 助教 / hr * 20 hr / week * 1 week = US$960 且手动改出来的分数有高有低、标准不一, 且该周的 office hours 没人顾 我花了约 40 hr 把自动化搞定，接下来每次作业只需要花个 2 hr 写 新的 JUnit test case, 大家就可以爽爽发呆了 这 40 hr * US$8 / hr = US$320 算是这一生最值得的投资之一… 接下来申请别的工作、正式求职，都靠了这玩意在推荐信、resume 上推了很大一把 ====================================================================== 这个例子与“游戏”测试没有直接的关系, 只是想说明，就“测试”而言，其实“测试”与“程式”同出一脉, 并无高下之分 只需要在适当的时机适当的地点做适当的事即可 ※ 编辑: AmosYang 来自: 98.26.14.35 (12/09 02:22) 拜 orz 我能了解这所谓“不划算”的观感, 许多游戏软体的规模很小，或着，code reuse率极低 把资源拿来作进阶测试的确会“不划算” 我有两位同事在初代 XBOX 的团队里待过，一位是搞硬体测试的， 另一位就是做游戏测试的, 年薪约 US$85k (税前, 福利什麽的另外算) 之所以有人愿意付他这种薪水，是因为 XBOX 游戏第一个 patch 免费 第二个 patch 开始，一次要 US$40k... 以小app来看，Windows Phone 的 app 从上传到出现在市集里 快则两三天，慢则一周以上, 且就算新版本上传了，也无法强制用户昇级... 一旦有 critical bug 被释出，善後极为困难 是该有专属的专业测试人员? 还是赌不会出包? 这没有一个绝对正确的答案 :D 只需要在适当的时机适当的地点做适当的事即可 :D ※ 编辑: AmosYang 来自: 98.26.14.35 (12/09 09:55) 测试(testing)一词在不同的背景(context)下有不同的意义 我习惯从软体测试(software testing)的角度去想；以微软(注一)来说，有视为正规部队 的 SDET (Software Development Engineer in Test), 也有外包给大陆团队的 STE (Software Test Engineer) 佣兵部队 : debug和测试好像不是同一个调 就 SDET 来说, 以下这些是很平常的事 * 找到 bug, 开 debugger 催上去，直接找到问题中心, fix it! 打 SDE 的脸，科科 * PM 开好了 spec. 後被 SDET 打脸(perf/security/integration...etc)後拿回去重做 * 但若一旦有 critical bug 跑进 production code, 不管是 perf, security, i18n... 有的没的, SDET 就要自备十字架去被钉在墙上 STE 就比较偏向於一令一动, 做的多是手动测试，拿的钱少，但责任也轻 是故，从我的角度看来，“测试”是通通都包的, 从 spec. 到 production 只要出包了就是钉 SDET, 超爽der :D 注一: “微软”是一个十万人以上的集合体，这里谈的是我看过的冰山一角 ※ 编辑: AmosYang 来自: 98.26.14.35 (12/09 10:51) ↖ [citation needed] :D ※ 编辑: AmosYang 来自: 98.26.14.35 (12/09 18:37)