想像一下公司最重要的軟體突然中斷，會發生什麼事？訂單可能會遺失、錯過期限，但客戶一定會抱怨。
這種夢幻案例能避免：透過實作持續嚴謹的測試流程，找出問題並造成問題。但是在組織中實作這類程序比做這麼簡單。
這篇文章會說明開始在公司環境中開始測試時需要的所有註意事項，以及如何長期下來從測試中獲益。
產品團隊適用的測試最佳做法
本文第一部分涵蓋開始在工作流程中實作測試的程序。
在團隊中導入測試文化
如要在團隊成功導入測試，每個人都必須擁有共通的思維，並將品質視為投入資金，而非負擔。在這個過程中，隨著所有其他文化轉變，這個過程都需要時間和一致性。
要塑造這個文化，有一件事可以安排定期會談，討論瑕疵、影響、從何處解決，以及解決這些問題的方法。這有助於喚起知名度，一開始就避免這類瑕疵。
不妨指派一個專責團隊監督並負責監管事務，大幅提高成功機率。負責定義團隊 (甚至是整個機構) 的指導人員，會收集最佳做法並分享最佳做法，並倡導各層級的訓練。
另一種實用的做法是輪替產品的支援角色。從客戶直接取得未經篩選的深入分析，並瞭解客戶遇到的每一種產品問題，能為產品經理、設計人員和開發人員帶來極大的助益。
目標是讓所有團隊都能瞭解品質的重要性，與您為產品建構的任何其他功能一樣重要。每人都採用這個思維後，自然是瞭解測試也是一項功能的過程。因為測試旨在確保運送品質。
逐步測試程序
當產品開發過程中的不同團隊之間達成共識後，您就可以進一步將測試的存在和用法正式化。
將測試做為「完成的定義」
只要將測試新增為功能要求，就表示功能在正確且經過自動測試前，尚未準備好發布
定期測試
實作後，自動化測試即可成為開發過程中每個步驟的保護措施。這類測試無需人為介入，可在開發管道的每個重要步驟中執行。例如：
- 針對每個修訂版本。
- 在每次提取要求時發出呼叫。
- 每次完整發布或環境變更後。
如果您在實際工作環境中使用第三方服務，甚至可以針對實際工作環境進行測試，確保第三方 API 可正常運作。
定義及收集指標
請務必定義一組指標，以便評估測試的成效，以及測試工作流程對業務的影響。以下列舉一些您可以使用的指標：
- 每月版本數量：每個月的發布數量越多，代表開發程序越靈活。此時，自動化測試扮演著關鍵的角色，可確保發布版本能自信地進行。
- 錯誤報告：錯誤報告的趨勢呈現下滑趨勢，可能表示您的測試 (和開發程序) 有效。
- 測試涵蓋範圍：雖然沒有確切的指標，但涵蓋範圍是瞭解您測試重要用途的深度。
請注意，這些指標也會受到其他因素影響，導致模型出現偏差。例如，版本數量可能會在節慶季節期間下滑，而錯誤報告卻增加。因此，不要只依賴其中幾個，務必要將其與團隊可用的其他資料交叉比對。
當您與團隊成功執行這些步驟後，長期下來，您的產品健康狀態必定有所助益。不過，你還可以執行更多操作！
系統管理員測試最佳做法
產品團隊無法自行處理。仰賴系統管理員維護的硬體、工具和基礎架構。雖然系統管理員通常不會直接參與產品開發，但他們仍可影響開發工作流程。例如，主動管理公司使用的特定瀏覽器版本使用者群組。
本文的第二部分將介紹如何使用 Chrome 的管道和企業政策。
Chrome 發布版本
根據預設，Chrome 會自動更新，確保每位使用者執行的是最新、最穩定、最安全的 Chrome 版本，包括所有最新功能，也就是在穩定版上發布的 Chrome 版本。
當公司開發網路式產品時，建議您在穩定版之前使用瀏覽器，讓您的產品團隊有時間配合網路平台的變動調整產品。
以這個用途來說，Chrome 總共提供四個發布版本，分別適用於不同的使用者群組。
如果是 Chrome，您可以使用不同發布版本預測瀏覽器日後的變更，並在最新功能正式推出前進行測試：
- 穩定版：這是大多數使用者所在的位置。當我們每月推出新的 Chrome 版本時，穩定版也會自動更新。
- Beta 版：這個版本會在四到六週內成為穩定版，讓您有機會預覽及測試即將推出的穩定版本，並做好萬全準備。
- 開發人員版：這個版本每週會取得一次新版 Chrome，並包含最終會進入 Beta 版的所有最新修正項目。正如頻道名稱所示，它仍在開發階段，因此可能會意外中斷，但其中也包含最新功能，有時仍會成為穩定版。因此開發頻道 是設計原型和先進開發的絕佳工具
- 初期測試版本：最實驗性的版本，包含每個最新功能，但沒有太多測試。至少每天發布一次。
如要進一步瞭解 Chrome 的管道，請查看相關的 Chrome 概念節目。
為營運機構使用管道
產品團隊的結構因機構而異，因為無法一體適用軟體開發方法。舉例來說，我們會假設一個團隊具備下列角色：產品管理、使用者體驗與使用者介面、工程、作業與支援。
對於這類組織，可以考慮下列管道分配：
- 產品管理：PM 通常可用於「stable」版本，以便使用與大多數使用者相同的版本。有時候，他們可以使用 Beta 版或 dev 版本處理所需功能需要的 API 尚未推出。
- 工程和使用者體驗：這些團隊的某些部分可造訪 dev 版本，讓他們能夠使用最新功能，例如檢視轉換，即使尚未穩定也沒問題。
- 作業：可能啟用 Beta 版，可預見影響到使用者的服務中斷情況。
- 支援：繼續使用「stable」版本，確保和大多數客戶透過相同的瀏覽器與產品互動。
使用企業政策管理頻道
Chrome 不會提供指引，也不用自行決定要使用哪個版本，而是提供企業和管理工具，可主動管理每位使用者最終使用的管道。這種做法非常實用，因為可立即將測試途徑從少數使用者增加到確定的一組使用者，有助於盡早發現中斷情形，並以可追蹤的方式進行追蹤。
如要使用該層級控管，建議採用以下設定：
- 員工 (應用程式使用者)：為盡可能降低服務中斷的風險，大部分的員工都應使用經過 Chrome 測試團隊全面測試的「stable」版本。此外，一小部分使用者 (從 5 到 10%) 都可採用 Beta 版版本。這個版本提供 4 到 6 週的穩定版預覽功能，可協助管理員找出版本的潛在問題，進而在其他人發布前有更多時間解決問題。
- IT 部門：IT 部門的成員 (包括系統管理員) 可選擇使用 Beta 版或 dev 版，提前 4 至 6 個或 9 至 12 週試用 Chrome 穩定版即將新增的功能。
長期發布版本
產品的開發速度可能會不夠快，且 Chrome 每個月的發布頻率可能太高。針對這種情況，Chrome 提供擴充穩定版，可讓您降低功能更新的頻率，但仍能收到安全性修正項目。這個版本每八週更新一次。
下圖說明不同的里程碑如何在 Chrome 的不同發布版本中執行：
- 無論是穩定或擴充的穩定版本，前四週都會推出相同的版本，之後兩者會區分。
- 沒有擴充 Beta 版；相反地，系統會使用標準的四週 Beta 版測試週期，同時穩定保持穩定及擴充的穩定版本。如果企業選擇加入第八週擴充穩定版，應像現在一樣繼續執行 Beta 版，以便主動找出可能影響環境的問題。
結論
測試是軟體開發公司不可或缺的一環，可以確保其產品品質，以及系統管理員的重要步驟，讓機構員工能存取高品質的軟體，同時避免業務程序中斷。
為了成功在機構內實作測試工作流程，每個人都必須具有相同的共同思維，因此測試是一項功能。
本文介紹了將測試最佳做法整合至機構中的各種方式；如要深入瞭解現有的測試工具，請參閱「Chrome 提供順暢的自動化測試工具」一文。
如需測試從開始到結束的實作指南，請一併參閱我們近期的 Learning Testing 課程，以及 web.dev 上的測試自動化最佳做法。