※ 引述《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/m.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/m.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)