首先，要誠摯地感謝網友 Kong-Ming 在今天按下「分享動態回顧」鍵，如果沒有跳出這則通知，我還真的忘了自己在 2013 年的 9 月 27 日曾經翻譯過這篇演講。
身為一個從 QA 工讀生入行，一路在職場上走向經理職的人，當時被 Bioware QA 發展部門總監 Tulay Tetiker McNally 於 Korea Games Conference (KGC) 2013 所發表的這則講演內容給深深地激勵到。
剛好先前也有被年輕朋友問到：「當 QA 真的有出路嗎？人家會不會覺得我什麼都不會所以才當 QA？」
就再分享一次，順便整理成文章。
--
你所待的遊戲公司，注重 QA 部門嗎？
新人以 QA 職缺為跳板加入遊戲產業會是一個好的決定嗎？
QA真的 是一份連貓都會做，只要有手玩遊戲就能幹的工作嗎？
底下謹分享 Bioware QA 發展部門總監 Tulay Tetiker McNally 於Korea Games Conference (KGC) 2013 所發表的講演內容，希望對於各位有所助益。
考慮到文章太長的關係，摘錄重點分享，並且將結論拉到首段來，其於部份的順序未做調整。
◎ 我講的太多了，講一句最重要的話：「所謂的QA，並不是為了確保產品的品質而存在的部門。一款遊戲的品質優劣不會是由單一部門來決定的。在遊戲公司裡，所有職務的人員都必須要關心QA，而身為QA人員，也必須對所有的領域保持高度興趣並學習之。」
◎ 一言以蔽之，事前預防，事後查明問題原因，確保產品項目正確實裝，就是QA團隊的任務。
◎ 在早期，遊戲開發者自己就能進行除錯作業，但隨著平台多樣化，遊戲複雜化，這個產業對於專業測試人員的需求量急劇增加，換句話說，QA人員正是被這個時代所需要而誕生的職業。
◎ Bioware的專業測試部門約有15～20人，當工作量增加時，也會追加人力。
◎ 這個職缺常被誤解為「只要一直玩遊戲就能領薪水」的工作，更常被外界瞧不起。一般認為誰都可以當QA，反正那樣的工作一點技術含量也沒有，在我們的國家，甚至有這麼一句話 - 「連貓都可以幹好QA的工作」。
◎ 不只是外界這麼看待，連來應徵的人也會有這樣的心態，但是老實說，那種每天打遊戲就能領薪水的時代已經結束了。
◎ Bioware在人材聘用方面的標準非常高，從全球各地找來具有才能的人材，QA部門也是以這樣的標準在挑選員工，即使錄取了AAA級人員，後面也還有非常嚴格的流程等待著他。
◎ QA人員必須要有一個認知，他們應該要能與營運團隊、開發團隊妥善溝通，共同建構起完整的開發文化，並協助提升產品的品質。
◎ 但事實上，QA的離職率非常高，在遊戲業界裡也不是什麼令人稱羨的職缺，有許多人從事QA工作只是求一份溫飽，並沒有將提升產品的完成度視為個人志業。
◎ Bioware的QA也會以客戶或顧問的角度提供意見給開發團隊。
◎ Bioware的QA分為技術QA與設計QA，前者偏向於程式設計的部份，後者則是提供產品設計上的協助，是故，在產品開發的時候，QA也能積極參與設計的過程。
◎ 敝公司相當重視「價值」這件事，承前所述，因為制度上讓QA團隊能共同參與產品的開發的過程，因此各部門不再將它們視為用來除錯的部門，而是確實有所貢獻的，進而發現自我的價值所在。
◎ 敝公司稟持著「你如果認為自己做的事情是正確的，那麼就執行下去吧」的原則
◎ 舉例而言，當三個總計投入300名人力的專案在進行的時候，QA部門會投入40人左右。在這個過程中，QA的意見並不會偏頗於某一方，會盡可能地提出公正且中肯的意見，如果有必要的話，也會提交完整的報告書。
◎ 與其他部門相比，QA部門更需注重「組織」這個觀念的重要性。
◎ QA即使不是開發者，也應瞭解開發遊戲所會用到的各種技術與知識。
◎ 面對消費者的時候，應該要能知道如何排除各種預期外所發生的狀況，所以必須掌握豐富且全面的知識與資訊。
◎ 對我來說，QA團隊就像忍者一樣的存在，隱身在看不見的地方，協助他人創造出最棒最棒的產品。
◎ 對於公司來說，QA也像是潤滑油一般的存在，讓全體成員能順利地彼次緊密合作。
◎ Bioware的QA部門有許多人已經工作十年以上了，當然也有許多人轉到研發團隊的職位，因為曾經擔任過QA工作，所以比起其他人都還要能夠快速發現問題，並協助建立部門間的合作關係。
◎ 一般人對於QA的印象還有一點，就是薪水比起其他部門要來的少。但在BioWare來說，QA與其他部門的薪資並不會相差太多，因為在這裡，QA是值得自豪的職業。
◎ 當我們早上起床準備到公司上班的時候會開心地想「今天應該要做什麼呢？」該怎麼樣協助其他同仁好讓開發作業更為順利呢？對我們來說，這份工作不單純只是獲取金錢上的報酬而已。
qa職位 在 Re: [請益] QA轉RD請益- 看板Soft_Job - 批踢踢實業坊 的推薦與評價
看到這文章就想到自己以前也是這樣想
給你我的歷程跟想法做參考
我目前是QA大概加減做了大約十年
歷程： QA -> iOS RD -> QA (目前）
先分析職位的 POC
[RD]
Pros
* Domain Knowledge 深度深：如果你愛某些特定議題，做久了是有機會成為專家
* 專案導向：如果是敏捷開發，通常會有一個週期讓你專心做特定的事情
* Visibility 高：若負責的專案是公司重視的，往往比較容易被看見
* OKR 較容易撰寫：因為是專案導向，固然是做完事情為目標（除主管職外）
* 薪資成長空間：（普遍公司）可能會優於 QA （我知道某公司不一定）
* 有共同目標的戰友：協同開發，學習速度很快
Cons
* 碼農：你寫的Code不是你的，你想做的，不一定在工作上能實現
* 隕石開發：若不幸跟到這種，神明會製造大量隕石，讓你 Context Switch 不完
* Bug 風暴：專案開發期間一定會需要撿一些 Bug 修，還有時程上的壓力
* Spec Changes：才剛寫好的架構，可能一次的 spec change 又要改了
* 協同開發：如果碰到很雷的，不只會破壞程式架構，也可能在協同作業上造成很多困擾
* 同儕壓力大：因為一山還有一山高，容易碰到互相競爭的戰友
（這會影響薪資漲幅、能見度、有些公司還會有惡性競爭）
* 髒Code：不是你能控制的，有時候是商業或時程考量迫使寫出一堆 workaround
[QA]
Pros
* Domain Knowledge 廣：QA 要看的是E2E、Integration固然接觸的技術廣
* 比RD更了解產品架構：呈上所說，因為廣度，所以往往QA較能發現產品弱點
* 自製工具改善效率：QA 做的事情雜，有些沒效率，若有能力自製工具改善效率在QA世界裡，是有很大的空間
* 懂程式的QA不多：這在QA的世界滿吃香的，通常能見度會比其他QA來得高
* 轉TPM轉RD：QA我認為是一個跳板，如果你把它看成是一個優點的話
* 可以選擇自己想要的架構做測試：如上所說，一個系統複雜，
QA使用的架構不可能只有一種，通常QA會需要找到很多工具或架構開發自動化。
這意味著你可以學到很多技術（但能請益的人有限）
Cons
* Domain Knowledge：廣而不精，需要時間、貴人、毅力補齊某些技術
* OKR 難以量化貢獻：要說找到Bug的數量？還是最佳化開發流程什麼呢？要懂說故事
* 溝通技術：有些人覺得是優點，我認為這是缺點，QA需要大量的溝通技巧處理 stakehold
（做QA的人可能懂我在說什麼）
* 重工率高：不只重工、反覆做一樣的事情也很常見
例：1. Bug 就像回力鏢，開出去的Bug回來後還是要測，測不過又要重來
2. 新Feature的多寡決定 Regression 的多寡，每個循環越來越重
* 協作機會不大：通常QA都是少打多的狀態，一個QA負責一甚至多的 Feature or Scenario
所以在寫自動化架構時，若不是同一套，則很可能出現單打獨鬥的狀況
這時候很需要靠自己自發性的殺出一條路，獨立作業。
* 自我實現與成就感不高：除非自己知道在QA能發揮什麼，
否則要得到別人的肯定，在QA是比較難的，通常是找到很有價值的Bug（刻板印象）
剛打的一堆被手機排版婊到...消失了（盡力還原了）
可能還有觀點有缺漏，歡迎大家補上感謝！
總結一下
要先想想，轉RD的目的是因為你對「特定技術有興趣嗎？」
如果不是，那技術這方面不一定要透過轉職才能得到你要的
「把喜歡做的事情變成工作，不一定讓你比較開心」
我自己喜歡在 QA 工作過程中，
學一些技術，覺得有趣
剛好私下找到自己愛的議題，
就用工作上或是自己學到的技能套用在
「自己的專案」
譬如說，自動搶票啊（教壞小朋友...）、
爬蟲啊、APP 之類的
那反而可以找到莫大的樂趣，
有別於把程式當成工作的朋友們。
當然，這是我的方式，
我自認為我若轉到 RD 應該是走了一陣子
我可能就陣亡了，
畢竟我對技術的廣度比較有興趣，
簡單說我比較花心啦...
那QA就比較適合我這種人
反之，問問你自己，
你對某些 Domain 情有獨鍾，
那你可能真的很適合 RD
我大概是在 30 歲那年決定自己未來要走路，
所以我最終還是選擇 QA
我覺得，對我來說沒有感覺後悔，
反而覺得路滿廣的，也不會對程式疲乏
只是每天都要思考怎麼量化QA的價值，
很煩...
但這就是工作的一部分。
隨手寫寫，希望對你有幫助，吃飯去。
※ 引述《kornkorn78 (阿強)》之銘言：
: 請益
: 小弟非本科學士畢業目前在一家小公司擔任QA已經一年多了，發現自己對QA好像不是那麼
: 的喜歡，反而喜歡RD的工作也私底下寫了一些小工具當sideproject例如利用aws api做的
: 自動部署來跑幫朋友寫的批量google登入(目前好像被google鎖了)之類，也有寫個簡單的
: restful api
: 技能：
: Python
: Golang(沒到熟練，寫的出東西而已)
: 碰過簡單的ML
: 簡單的資料庫語法(crud)
: js(沒到熟練)
: 用過：
: docker
: aws
: 串接過api
: git
: 想請問各位大大我需要再補充哪些技能或是做些什麼才能走向RD呢？
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.34.125.120 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1621745230.A.73C.html
※ 編輯: fourplayers (114.34.125.120 臺灣), 05/23/2021 13:10:32
※ 編輯: fourplayers (114.34.125.120 臺灣), 05/23/2021 13:22:53
... <看更多>