我自己一開始聽到Beta版本，是小時候在玩遊戲的時候（透露年齡）

遊戲公司會先出封測(Close-Beta)，邀請少量玩家先進去體驗遊戲

經過可能幾個月的時間，就會開放公測(Open-beta)，讓玩家註冊進來玩

公開測試一段時間後，可能就會出一個正式改版，接著就是活動主題的改版等等。

而我發現，現在的遊戲或是軟體服務，明明已經上線很久了，

看起來就是正式版，為什麼還說自己是Beta版本？

這篇就來聊聊軟體開發週期中比較常聽到的幾個詞

軟體版本週期 (Software Release Life Cycle)

上面的黃色區域是測試與開發期間(Testing and development period)

下面的藍色區域是發布期間(Release period)

我們由上到下每個階段慢慢看起：

Pre-alpha：

這個階段通常還是在內部開發人員製作出的開發版本

可能會聽到像是PoC(Proof of Concept，概念性驗證)這樣的詞

意思是單一新功能正常，但還沒做過回歸測試，跟其他功能的交叉測試

屬於非常前期且不會釋出的軟體開發版本

這個時候RD可能都在做Design Review，QA也在準備Test plan Review

Alpha：

Alpha階段，QA就會開始參與進行主要的新功能測試與回歸測試

這個時候團隊的目標會放在把新功能與舊功能的回歸測試都完整測試過一輪

目的想要在Alpha階段找到一些設計與功能上需要修正的嚴重缺陷

希望能在開發前期就大事化小、小事化無。

Beta：

到了Beta階段，一般就會把完整功能的軟體上到一個Beta/Stage環境來實際運作與測試

有時候為了驗證，會請業務單位邀請真實客戶來參與測試軟體，並獲取Feedback

剛進公司的時候，團隊產品剛好就是開發到Beta階段，上工兩週就跟老外Remote

看客戶試用我們產品之後有什麼反饋，我們就可以去做紀錄跟修正。

針對Beta測試中遇到的問題回報，QA就可以敲JIRA Case來紀錄客戶回報的問題

有時候也可以從客戶回報的內容中，了解一些業務邏輯跟產品怎麼實際被應用的場景

藉由參與這類客戶的Beta測試，也會對設計測試計畫的深度與廣度有很大的幫助。

Release Candidate (RC)：

進入RC階段前，RD團隊通常會有個程式凍結(Code Freeze)的動作

意思是在某個時間點之後，不能再修改任何的程式，必須固定出一個品質穩定的版本

讓QA團隊做一個完整的回歸測試與確保目前版本的產品品質。

在RC階段，軟體開發階段就接近尾聲，最後會決定出一個版本稱為(RC build)。

RTM / GA：

我自己的產品經驗比較多都在純軟體，不過在台灣很多軟硬體整合的公司

會用到RTM(Release to manufacturing/Release to marketing)這個詞

來代表軟體的部分已經開發得差不多了，可以進入製成或開始市場行銷的階段

以純軟體來說，可能上個階段RC過後，就會進入GA(General Availability)階段

這時QA會以回歸測試為主，抓出漏網之蟲，若有就需評估影響風險與討論是否需要修改

白話一點就是，開發與測試都進行得差不多，可以準備吃新版本上線慶功宴了（誤）

Production / GM (Golden Master)

到這邊，軟體就正式上線Release啦！

還有個有趣的詞叫做GM (Golden Master)，是老闆跟我說的史實（？）

意思是以前軟體在正式發行的時候，會把軟體燒進實體的CD裡面販賣

一開始的CD背面都是金色的，因此有了Golden的稱號

Master我忘記緣由，但應該是一種代表原始初版的意思吧。

如果知道的資深大大，歡迎在底下留言補充～

而由於以上說的這個軟體開發版本週期跟瀑布式開發一樣行之有年

近年流行的Agile與DevOps把重點放在持續迭代與修正

上述的階段分界也漸漸模糊，甚至是不太採用這樣階層式的開發階段

但我覺得在整個軟體開發過程中，還是可以在不同流程架構中穿插相同的思維

只要知道QA的目的是要確保優良的產品品質，剩下的就是做法差異而已。

另外呼應標題的問題，為什麼遊戲軟體甚至是很多線上產品都說自己是Beta版呢

我覺得某個程度上，是想要規避掉一些期待跟觀感問題：

如果說是正式版，出了很多bug，那就是品質管理做得不夠好

但是如果說是Beta版本，出了很多bug，那只是我們還在上圖早期的開發階段

之後我們會再持續修正與改進XD

下一篇來聊聊軟體開發過程中常使用的RD開發與QA測試環境