開發者與發行商QA相關流程探討

開發者與發行商 QA 相關流程探討 

本文除擷取至獨立遊戲發行商 AnotherIndie 的 QA 經理青蛙在 TGDF 所做的演講外，也增加了大量的內容以補 足原來半小時演講沒有提及的部分。 

 

演講原連結如下 

>> TGDF2020 連結

 

1. 發行端與開發端 QA 的差異 

其實兩端 QA90%的流程都是一樣的，但剩下的 10%就造成關鍵的差異。以下 

或許我們兩個都用非技術的案例可以更明確看到差別 

 

● 開發者要測的是「遊戲」： 

作為一個遊戲，開發者更多時候著重在遊戲本身的機制 玩家能否理解並且造成如開發者預期的「體驗」。 >> 範例：譬如說開發者可能在展場測試發現某些遊戲的 流程點並無法如預期引起某些強烈情緒，這當然不是 BUG，但它影響了「體驗」所以必須修正。

 

● 發行商更像在測試「產品」： 

發行方測試在乎的是產品本身在數據上的表現，比如說 發行方可能測試到一些問題，明顯可見，也就是清楚是影

響「體驗」的，但是他不至於讓玩家產生負評。 >>範例：譬如說發行商發現送過來的版本完全不支援某種控制器而這是該產品 TA 大量使用的，因此極可能導致負評。這並不是 BUG 但他影響了「市場數據」所以會建議修正。 

 

了解最終目標 

就減少了一半的溝通成本 

 

更深入地說，今天理解雙方在意的點，不只是為了雙方 溝通順暢。而是經過解釋以後，開發者現在也可以切換成 發行商的視角去檢視遊戲的各種問題，這能更加增強開發 者對產品的認知，因為畢竟開發者才是擁有產品的人。

 

2. 不同階段的 QA 需求 

遊戲開發期間的生命週期 

每個周期訴求事實上都會有很大的差異，所以其實前述 的發行與開發端差異是不斷穿插在這些週期之間的。但兩 邊在每個階段要達到的最終目標卻是相同的。 

 

● 提案階段(未公開情況下向對方寄送版本)： 雖然這裡比較接近開發者單方面向發行商或投資人提 案，但對方也需要開發者提出符合一樣需求的版本，並且 也會努力幫助開發者達成這個目標(如果對該版本印象不到 太差的話大部分都是會持續給建議)。此階段版本被提案方 較可以忍受一些特定的控制問題、畫面或技術上有些影響 表現品質但不到惱人程度的各類問題。提案的最終目標在 於運用版本建立一個關於遊戲賣點的論述，這個論述可以 是基於遊戲性或是故事，不少 BUG 會讓這些論述有小扣分 到將近不及格的水平，但只有會直接中斷體驗或造成體驗極大斷點的 BUG 才會讓提案產品直接被拋棄。因此雙方 QA 都建立在這點上。另外友善的小提醒是對被提案方而言，開發者們事先能 找出並提醒的 BUG 數量越多，相對在心理層面上越不會造成體驗的斷點。

 

● 展示階段(在線上線下場合公開展示)： 

此階段雙方最終目標也是相同的，可展示的 BUILD 在訴 求上相對還是接近提案階段，只是在這裡時間限制，畫面 及運行效能，穩定度上都會有更嚴格的要求。這裡會更偏 向在極短的運行時間裡面面俱到，而且發行方在一些操控 上會注意的細節會被更嚴格要求達標。 

 

● BETA 階段(姑且解釋為遊戲的初步穩定版本)： 這裡開始就是雙方的訴求會更明確產生差異的階段。遊 戲在這裡完成一個穩定的雛形，內容也幾乎都填進去了， 所以在前面的版本都是極小型閹割版的內容，到這裡開始 測試的工作量和溝通成本會急速的膨脹，並且版本的控制 會更為重要，因為很快多平台版本也會從這裡延伸，而且這個週期裡偶而還是可能要出展會的版本。 

 

● 送審階段： 

這部分各版本的不同需求會更加分歧。假設今天是除了 STEAM 以外三大主機平台都要出版本的話，基本上這階段 有可能除了應付每個平台的 QA 規格就已經占掉大部分時 間了，很難分出心神再堅持剩下的問題是發行方還是開發 方想修正的。但事實上今天會解釋兩種 QA 觀點就是因為 他們對於遊戲最終成形都是相當重要的，所以之後有餘力 的話應該要再持續的討論如何從兩邊的出發點繼續打磨遊 戲並決定每個 BUG 的優先順序。 

以上部分著重在即使已經決定要自己發行的開發者們也 可以參考的部分，以下我們就以已簽約的開發及發行雙方 間溝通流程以及心得來作探討。

 

3. 結果 QA 看板就變成了這樣 

上圖中講者解釋為一開始的 TRELLO 任務控制出現了一些問題導致溝通成本出現了。一開始的思維單純是針對每個特定版本去開一個 PIPELINE 或是清單， 這樣乍看之下合理，開發者只要針對現在的版本清單就好，但久而久之版本低 多就開始產生問題。 

 

● 重複議題 

雙方都會出現重複討論某些特定問題的情況。 >>個別議題追蹤強度不足。

 

● 認知落差 

雙方對個別問題是否修正或是否重大有歧異。 >>問題的優先級定義不足。

 

● 不易閱讀 

任務看板或在其他體系下 BUG 敘述的可讀性差導致上述問題。 

 

● 做人失敗(?! 

由於上述部分累積了不少溝通上的問題，但開發者始終 才是最後拍板的人，所以最後就變成這些累積的問題過了一 個臨界點以後開發者拒絕發行商方面修正的機率變高，雙方 就開始進入惡性循環。

 

4. 怎麼優化流程?  

 

● 默契建立 >> 宣告且共享資訊 

首先就是要向開發者明確的解釋發行商 QA 的原因，目 標與發行商立場。接者就是確保雙方都明確理解 QA 流程。 版本出來要透過那裡送給開發者，要透過哪個平台的群組告 知，一般來說幾個工作天算 DELAY，有沒有遊戲流程的詳盡 文件等等，這些細節都在事前解釋的越周全，留下雙方共識 的文件紀錄越多，之後的問題就越少。

 

 

● 看板設計 >> 以明確優先層級為基礎的看板設計 這裡講者解釋了經歷初期看版造成的問題以後，最後從 以版本為主改成以優先層級為訴求的看板設計。較特別的是 為應對一些突發狀況所以多了一個「事件」的層級，更能解釋一些因應實際情況或不同版本需求而會產生優先層級劇烈變動的問題 。

 

最後任務看板就變成了這樣。額外的好處是沒有以版本為主的看板會大量減少 

重複顯示的問題資訊，也間接減輕開發者的壓力。

 

以下也是其他一些在多個專案漫長 QA 流程中所得到的 Know-How 。

 

● 減低疑慮 >> 議題卡片應該永久存在 

• 確定議題穩定，不會突然出現突然消失。 

• 留下議題解決歷史，了解當初的處理方式。

• 減少重複議題，才能釐清同一個問題是否重複出現。 (所以也許沒有真正解決問題本身)  

 

● 問題分類 >> 問題依照重要程度，以優先序分類 • 不是每個 BUG 都要修，不是所有問題都有足夠工時可 以消化，在獨立遊戲來說理解此點尤其重要。

      • 影響開發端決定解決的方案。(例如:重要度低的可以只 治標不治本)  

• 降低開發端心理壓力。 

• 減低溝通成本不等於可以降低溝通頻率，保持開放的 討論環境通常都可以防止更多問題。

 

● 預測例外 >> 譬如說有時需要用舊版本展示，這時就 有以下問題 

• 針對舊版本的 QA 議題需要留下嗎?  

• 他算是在哪個優先序?  

 

● 心理建設 >> 不斷確保雙方認知相通以維持較輕溝通成本 

回想目標與立場 

• 開發者才能決定修正內容。 

• 不做最大就完蛋了。 

 

良好的溝通架構 

• 給予討論空間。 

• 說明任務理由。 

• 降低流程壓力。 

 

給予動機與希望 

• 為什麼要合作?為什麼要 QA? 

• 最終目的與期待的未來。

• 給予評價並對肯定成果。 

 

最後為經歷各種專案及例外情況打磨/荼毒後，講者所下的結論是：只要冷靜安排，事情就能越做越少。講者也提供目前所使用的 TRELLO 任務看板敘述格式，謹供各位參考。 

 

 

雖然以上這部分內容是來自開發和發行方就 QA 的溝通 總結，但類似的原則在較大團隊的內部溝通或是團隊跟外包協調的場合也是通用的。並且必須說明的是，以上是講者個人經驗的總結，雖然講者經歷了相當多專案的 QA 並且仍在該職位上，但這些萃取出的有用資訊也不會百分百適用在各種情況。團隊仍應該就各自特性去嘗試協調出屬於自身最佳的 QA 環境。QA 也是遊戲開發中相當重要的一個流程但至今也沒有很多關於此方面的討論，希望本篇也能起到拋磚引玉的作用，讓更多大大能加入分享討論並一起優化相關流程的行列！