軟體測試實務：業界成功案例與高效實踐
台灣第一本跨業界團隊合著大作
📢 如果此文章有幫助到你，請按此追蹤 一日測試 IG (oneday.software) ，與我們保持高度互動，以獲取最新的軟體資訊與技術方案！
📚 資訊同步：
👉🏻 2023.05.23 開始預購
👉🏻 2023.06.05 實體書籍販售
👉🏻 2023.06.18 新書分享會（後續更新細節）
👉🏻 2023.08.05 預計電子書上架時間
🎉 書籍佳績：
👉🏻 預購第 2 日，天瓏近 7 天中文熱門暢銷書「第 1 名」與「第 2 名」
👉🏻 預購第 8 日，天瓏近 30 天中文熱門暢銷書「第 1 名」與「第 2 名」
👉🏻 開賣次日，書籍二刷
🔗 相關連結：
👉🏻 書籍官方網站
👉🏻 天瓏書局 — 軟體測試實務 : 業界成功案例與高效實踐 [ I ] [ II ]
👉🏻 金石堂 — 軟體測試實務 : 業界成功案例與高效實踐 [ I ] [ II ]
👉🏻 博客來 — 軟體測試實務 : 業界成功案例與高效實踐 [ I ] [ II ]
記得在 2020.7 在 Medium 的第一篇文發出後，並不預期能夠獲得什麼樣的迴響，純粹只是紀錄工作的思考脈絡，並分享給有需要的人。而隨著追蹤人數、閱讀量愈來愈多，也希望當下團隊能發揮影響力，透過文檔的輸出讓業務邏輯、問題與解法都能有很好的沉澱。
很快的，當時投遞履歷的人數愈來愈多，在交流的過程中才被告知，很多候選人是因為文章的定期輸出，而對當時組織的文化與運作感到好奇，這是從未想過的影響，也是在這樣的契機下，一日測試才會誕生。
從大學時期，就一直聽到，「一日測試，終身測試」，類似揶揄的話語層出不窮，總認為不會寫程式、技術能力不精才會往測試走。但是，若真要追溯軟體測試的歷史，在 1950 年代和 1960 年代，隨著軟體開發過程的發展，開發人員則開始使用單元測試的概念。單元測試通常是由開發人員自己創建和執行。那跟「不會寫程式、技術能力不精」根本沒有任何關聯，為什麼軟體測試會給人技術門檻較低或是話語權相對弱勢的印象呢？
主要還是因為兩個原因：「認知偏見」與「經驗價值」。
- 認知偏見：測試往往被視為開發過程的附屬部分，而不是核心活動，期望測試為問題發現者。這種刻板的觀點可能導致測試被低估，並使其在團隊中的話語權相對降低。
- 經驗價值：軟體測試是一項經驗密集型的工作，該專業很吃經驗但是缺乏可量化的成果指標，因此測試人員的價值不太容易被直接衡量和評估。
既然理解角色被弱化的原由，那就由自己的團隊開始進行改變，核心價值觀的建立，「品質，是公司內建的文化，而測試只是一種手段」，因此，「把品質好的內容或產品交付到使用者手上才能完整實現努力的價值」，則為公司上下的一致目標。
由測試團隊 → 技術團隊 → 產品團隊 → 客服團隊 → 行銷團隊……，慢慢影響到整間公司，讓測試變成核心活動，也把測試的角色定位由「問題發現者」改成「品質倡導者」，那基本上就完成品質在該公司的價值定錨。而測試人員的價值必需能被實時的反應，因此測試人員對於專業領域的知識地圖內化、品質儀表板的建立、站在使用者角度衡量業務情境的應用是否符合需求等專業技術能力都要能被量化。
完成了「對內的文化沉澱」，那下一步則是「對外的影響力輸出」。所以在 2021 年底，當時的團隊在 Medium 的文章輸出則變得相對活躍，而正當在想是不是應該跟公司外部的教學組織進行深度合作，或是能更進階的與出版社洽談出版物……
Messenger 就在 2022.3.9 傳來了一封訊息
「Howard 您好! 很冒昧打擾了! 我是成大資工系李信杰老師，請問 https://onedaysoftware.medium.com/ 上的這些文章是您或您團隊(街口支付) 撰寫的嗎? 我相當的感興趣，有一些合作的想法看看有沒有機會跟您討論看看~~」
『老師你好， 是的，這些文章都是我們團隊的努力成果。 感謝你對我們的產出有興趣，想請問一下，大概會是什麼樣的合作方式呢？』
「有鑑於軟體品質保證一直都是軟體開發領域中重要的階段，但國內一直都沒有一本軟體測試實踐相關的中文書籍，因此我今年欲編一本「軟體測試實踐」一書，邀請一些業界測試專家撰寫章節，彙編成書，希望能藉此協助培育更多的國內軟體品質人才，促進提升我國軟體測試實務能量。」
機會來得好，不如來得巧！合作就這樣牽上線了。台灣軟體測試領域總是處於鴨子划水的狀態，但就是缺乏了那一陣風。很感謝成大資工系 李信杰 教授所提出的合作案，也很感謝參與各章撰寫的作者們無私的分享、更感謝博碩文化（特別感謝 Abby 與 Cathy 的努力與編輯）對於軟體測試的支持。而屬於「軟體測試」的那陣風吹來了，讓我們乘風而上，鳥瞰「軟體測試」在台灣的另一片天空！
街口測試團隊的夥伴們在「軟體測試實務：業界成功案例與高效實踐 [I][II] 」總共貢獻了三個章節，分別是：
CH6 測試，不只是測試
6.1 重新實踐「軟體測試」與「測試工程師」
6.1.1 Quality Assurance Engineer (QA)
6.1.2 Software Development Engineer in Test (SDET)
6.1.3 小結
6.2 專案流程中的測試左移、右移
6.2.1 軟體專案流程說明
6.2.2 測試左移
6.2.3 測試右移
6.2.4 應用 PDCA 循環
6.2.5 小結
6.3 以品質角度來驅動產品與開發
6.3.1 測試驅動開發（TDD）
6.3.2 驗收測試驅動開發（ATDD）
6.3.3 行為驅動開發（BDD）
6.3.4 領域驅動設計（DDD）
6.3.5 街口的專案開發流程
6.3.6 小結
6.4 線上服務故障處理
6.4.1 高品質的定義
6.4.2 用來衡量系統表現的指標
6.4.3 有效限縮故障影響範圍
6.4.4 標準化故障處理流程
6.4.5 街口案例分享
6.4.6 小結
6.5 結語
CH2 效能測試－街口購物節
2.1 效能測試方案
2.1.1 需求價值分析
2.1.2 效能測試概述
2.1.3 效能測試計畫產出
2.1.4 小結
2.2 效能流量模型
2.2.1 流量模型的建立
2.2.2 流量模型的優化
2.2.3 小結
2.3 效能測試實踐
2.3.1 效能測試目標訂定
2.3.2 效能測試模型產出
2.3.3 壓測流程
2.3.4 壓測結果分析
2.3.5 小結
2.4 數據監控與止血預案
2.4.1 數據監控
2.4.2 止血預案
2.4.3 小結
2.5 結語
CH5 第三方服務整合規劃、測試與維運實踐
5.1 街口標準測試流程
5.1.1 需求分析讓測試不只為了測試
5.1.2 擬定測試計畫並確保測試情境完整性
5.1.3 著手測試並實際執行測試項目
5.1.4 小結
5.2 串接第三方測試實例分享與痛點解決
5.2.1 串接第三方測試實例與測試要點
5.2.2 串接第三方測試痛點解決與線上監控
5.2.3 小結
5.3 開放外部業者串接
5.3.1 開放授權能力
5.3.2 外部整合測試
5.3.3 小結
5.4 結語以上的三個章節是街口測試團隊的心血產出，而其他章節來自於台灣許多知名企業的軟體測試團隊，每個章節的想法都有其精華，也希望讀者們能獲取到自己想要的養分。軟體品質工程能探討的議題還有很多，相信在未來還能產出不一樣的想法，「讓我們在各自的守備範圍中努力，在軟體測試領域中聚首」。
We’re definitely the GOAT.
Howard Chiang
2023.6.3
