假設貴公司最重要的軟體突然故障，會發生什麼事？訂單可能會遺失，截止期限可能會錯過，但客戶肯定會抱怨。
您可以避免這種災難情境：只要實施持續且嚴格的測試程序，就能在問題造成混亂之前加以解決。不過，在貴機構中導入這類程序並非易事。
本文將說明在公司開始進行測試時，需要考量的所有事項，以及如何從長期測試中獲益。
產品團隊的測試最佳做法
本文第一部分將說明如何開始在工作流程中實作測試。
在團隊中實施測試文化
如要成功在團隊中導入測試，每個人都必須抱持相同的思維，並將品質視為投資，而非負擔。這項過程需要時間和一致性，就像任何其他文化轉變一樣。
其中一個有助於塑造這種文化的做法，就是定期召開會議來討論缺陷、缺陷造成的影響、缺陷的來源，以及如何修正缺陷。這有助於讓使用者瞭解為何應從一開始就避免這類瑕疵。
團隊中若有專人負責監督及推動這項工作，成功的機會就會大幅提高。負責定義團隊或整個機構的規範，收集並分享最佳做法，並在各層級推動相關工作。
另一個實用的工具是輪替產品的支援角色。產品經理、設計師和開發人員可以從客戶身上獲得第一手、未經過篩選的洞察資料，並瞭解他們在使用產品時遇到的日常問題，這對他們來說是寶貴的經驗。
目標是讓團隊中的每個人都瞭解品質是一項功能，與您為產品打造的任何其他功能同樣重要。一旦大家接受這種想法，自然就會瞭解測試也是一種功能。因為測試可以確保產品的出貨品質。
逐步測試程序
產品開發團隊之間的合作關係一旦建立，您就可以進一步將測試納入正式程序。
將測試納入「完成定義」
將測試設為功能需求，表示功能必須經過適當的自動化測試，才能準備發布
定期執行測試
實作完成後，自動化測試可在開發程序的每個步驟中提供安全防護。這類代理不需人為介入，而且可以在開發管道的每個關鍵步驟中執行。例如：
- 每次提交。
- 在每個提取要求中。
- 每次完整發布或環境變更後。
如果您在實際工作環境中依賴第三方服務，甚至可以針對實際工作環境執行測試，確保第三方 API 的行為符合預期。
定義及收集指標
定義一組指標非常重要，因為這有助於評估測試的成效，以及測試工作流程對業務的影響。以下列舉一些可用的指標範例：
- 每月發布次數：每月發布次數越多，表示開發流程越有效率。自動化測試在這方面扮演關鍵角色，可確保發布作業能順利進行。
- 錯誤報告：錯誤報告的趨勢呈現下降，可能是測試 (和開發程序) 有效的正面跡象。
- 測試涵蓋率：雖然涵蓋率並非精確的指標，但它可以很好地指出您測試關鍵用途的深度。
請注意，這些指標也會受到其他因素影響，因此可能會有所偏差。舉例來說，在節慶檔期，發布次數可能會減少，但錯誤回報數卻會增加。因此，請不要只依賴少數幾個指標，並確實將這些指標與團隊可用的其他資料交叉比對。
當您與團隊成功實施這些步驟時，產品健康狀況一定會從中長期受益。但你還可以做更多事！
系統管理員的測試最佳做法
產品團隊無法獨力作業。這些應用程式依賴系統管理員維護的硬體、工具和基礎架構。雖然系統管理員通常不會直接參與產品開發，但仍可影響開發工作流程，讓開發工作順利進行。舉例來說，您可以主動管理公司中特定使用者群組使用的瀏覽器版本。
本文的第二部分將說明如何使用 Chrome 的管道和企業政策。
Chrome 發布版本
根據預設，Chrome 會自動更新，確保每位使用者都能執行最新、最穩定且最安全的 Chrome 版本，包括所有最新功能，也就是在穩定版發布的 Chrome 版本。
如果貴公司正在開發網路產品，建議您在穩定版管道推出前使用瀏覽器，讓產品團隊有時間調整產品，以因應網路平台的變更。
針對這個用途，Chrome 提供四個發布版本，適用於不同的使用者群組。
以 Chrome 來說，您可以使用不同的發布版本，預先瞭解未來的瀏覽器變更，並在最新功能正式推出前測試這些功能：
- 穩定版：這是大部分使用者所在的版本。穩定版會在每月推出的新版 Chrome 發布時自動更新。
- Beta 版：這個版本會在四到六週內推出穩定版，讓您預覽及測試即將推出的穩定版，並做好準備。
- 開發人員版：這個頻道每週會推出新版 Chrome，並包含所有最終會納入 Beta 版的最新修正項目。顧名思義，這個管道仍在開發中，因此可能會發生意外中斷的情形，但也包含最新的功能，有時甚至比穩定版推出還早。因此，開發人員頻道是製作原型和進行尖端開發作業的絕佳工具。
- 初期測試版本管道：最具實驗性的管道，包含所有最新功能，但未經過太多測試。至少每天發布一則。
如要進一步瞭解 Chrome 的管道，請查看相關的 Chrome 概念集。
在示例機構中使用管道
產品團隊的結構因機構而異，因為軟體開發並沒有一體適用的方法。我們假設團隊有以下角色：產品管理、使用者體驗和使用者介面、工程、作業和支援。
對於這類機構，您可以考慮採用下列管道分配方式：
- 產品管理：PM 通常會使用穩定版，以便與大多數使用者使用相同版本。如果他們正在開發需要尚未推出的 API 的功能，有時可以使用Beta 版或開發人員頻道。
- 工程和使用者體驗：這些團隊的部分成員可以使用開發人員版，即使在功能尚未穩定前，也能存取最新功能，例如View 轉場效果。
- 作業：可在beta 版中使用，以便預測下次影響使用者的中斷情形。
- 支援：可以留在穩定管道，確保他們與產品互動時，使用的瀏覽器與大多數客戶相同。
使用企業政策管理管道
除了提供指南，讓使用者自行決定要使用的管道，Chrome 也提供企業和管理工具，可主動管理每位使用者最終使用的管道。這項功能非常實用，因為它會立即將測試介面從少數個使用者擴大到確定性的使用者組合，有助於盡早以可追蹤的方式找出問題。
如果您想使用這類控管方式，建議採用以下設定：
- 員工 (應用程式使用者)：為盡量降低服務中斷的風險，大部分員工應使用已通過 Chrome 測試小組全面測試的穩定版。此外，少部分使用者 (5% 到 10%) 可以使用Beta 版。這個管道可讓管理員在推出穩定版前，先進行 4 到 6 週的預覽，以便找出版本可能存在的問題，並有更多時間解決問題。
- IT 部門：IT 部門成員 (包括系統管理員) 可以使用測試版或開發人員版，提前 4 到 6 週或 9 到 12 週試用 Chrome 穩定版即將推出的功能。
長期發布版本
產品開發作業可能無法如期進行，而 Chrome 每月一次的發布節奏也許太高。針對這種用途，Chrome 提供擴充穩定版，可讓使用者收到功能更新的頻率降低，但仍可收到安全性修正。這個版本每八週更新一次。
下圖顯示不同里程碑如何透過 Chrome 的不同發布管道進行：
- 穩定版和延長穩定版在前四週內會發布相同版本，之後兩者就會分道揚鑣。
- 沒有擴充 Beta 版管道，而是使用標準的四週 Beta 版週期，以穩定版和擴充穩定版為目標。選擇採用八週延長版穩定版的企業，應繼續執行 Beta 版管道，以便主動找出可能影響其環境的問題。
結論
測試是軟體開發公司確保產品品質的重要環節，也是系統管理員讓機構員工使用高品質軟體，避免中斷業務流程的重要步驟。
為了在組織內部導入測試工作流程，每個人都必須抱持相同的想法，認為品質和測試是功能的一部分。
本文將介紹各種方法，協助您將測試最佳做法整合至貴機構。如要深入瞭解現有的測試工具，請參閱「Chrome 提供的工具，可進行無摩擦的自動化測試」一文。