上篇簡單帶過軟體開發與發佈的週期，這篇來講RD與QA合作的相關實務。

主要包含開發環境與測試環境的配合，以及產品推出前怎麼配置不同測試環境。

開發與測試環境 (Test, Beta, Staging, Production)

一般來說，開發團隊會在不同軟體版本階段，把開發中的產品放到不同測試環境上等待測試

如果測試結果是通過的話，就會照著專案的推行，進入到下一個開發階段。

像是如果產品還在Pre-Alpha或是Alpha階段，RD可能就會在自己本機環境

或是放到Test環境，請QA去做基本功能驗證，又稱冒煙測試(Smoke test)。

進到Beta階段之後，開發中的產品就會上到Beta環境

像是之前提到請真實客戶做驗證，或是內部人員做一個Private Beta都可以

Staging/Stage 環境是什麼？

Beta好理解，就是一個開發完整但測試還沒完全確定潛在風險與軟體缺陷的環境

Production也容易，就是一個開發測試週期都結束的正式上線環境

一開始覺得比較疑惑是一個被稱為Staging的開發測試環境

簡單來說，Staging環境就是品質比Beta環境更好，上Production前的中繼站。

上篇提到版本週期時有提到Release Candidate(RC)這個階段

而RC版本的軟體就會發布到Staging環境，讓QA做一個較完整的回歸測試。

測試完成之後就可以進到Production準備上線。

而這個時候就會出現一個常見的實務問題：

「同時會有很多不同的功能在開發與驗證」

開發中途遇到一個比較大的問題，導致整個開發中的產品處於一個不可測試的狀態

整個測試工作可能會因為比較嚴重的bug而無法繼續測試，怎麼辦？

所以QA team會需要提前「喬」出一些測試環境是針對不同面向的驗證

常見的分法跟實際溝通的切分方法有：

「Staging環境只能用來上通過完整功能測試的build，主要以回歸測試為主。」

「Beta環境主要以功能測試為主，但一定要通過CI/CD的Unit test，不能上local build。」

(關於CI/CD跟BVT(Build verification test)之後會專文說明)

以上這些溝通方式，都是為了要確保每個環境都能使用，如果真的有問題，

也會以不要影響到每個階段的開發與驗證為前提來去「喬」測試環境。

開發與測試環境的設置，會跟每個公司做基礎建設(Infra)的團隊有關

有些公司有時候會用內部自己架設的伺服器，但由於維護人力成本高昂

近年也很流行使用Cloud Service，像是AWS, Azure, GCP等等，

管理雲端伺服器不僅簡單好用也比起自架伺服器，能做到更多不同有效的功能。

有些團隊可能直接用開發階段去切分 Beta / Staging / Production 環境

有些還有Int環境，主要用於整合測試(Integration testing)

有些是以開發團隊切分 Test / Staging / Production

甚至更簡單就只有 Staging 跟 Production 都很常見

但一個簡單的核心概念就是：

越接近Production的開發階段，對品質要求就會越高越嚴格，

通過每個階段出來的產品品質才會如預期般的好。

這篇提到不少關於Build這個字

下篇我們來聊QA溝通上常會出現的俚語（？）