由軟體測試到品質工程 — QA 該知道的那些事之 Q&A Part B
📢 如果此文章有幫助到你，請按此追蹤 一日測試 IG (oneday.software) ，與我們保持高度互動，以獲取最新的軟體資訊與技術方案！
It seems obvious based on the survey results that irrespective
of technology trends, quality engineering will continue to be
a focus in the months and years to come, and that it will, if
anything, become more relevant than ever.
根據 World Quality Report 2022–23 第 46 頁的說明，「品質工程將會持續的成為焦點」。無論科技趨勢如何發展，在快速迭代產生產品的原型後，除了檢驗商模與產品是否能解決使用者的問題，品質也遲早是一個需要被關注的議題，遲或早而已。而這也是為什麼當初 AppWorks School 在邀請我們一日測試技術分享時，最終題目的定稿會定在「品質工程」的原因。也因為分享當日的時間有限，無法一一回答每個人的問題，希望透過這系列的文章回答能回饋給當日參與講座的成員們，特別感謝大家對於講座活動的積極參與！
測試覆蓋率主要是一個技術層面的指標，旨在衡量測試的完整性。雖然測試覆蓋率對於確保測試的廣度非常有用，但並不能完全代表應用程式的完整測試情形。測試覆蓋率通常有幾個通用的指標：行覆蓋率、分支覆蓋率、方法覆蓋率……，在此我們不展開討論。因為筆者以往待過的公司主要的程式語言棧為 Java 或是 Python，因此曾經透過 JaCoCo 或是 Coverage.py 來將相關的數據計算出來，慶幸的是！這兩個工具目前仍有在持續更新與維護，若有興趣的小夥伴可以透過上述兩個工具，或是其他語言和框架的相應工具，將測試覆蓋率計算出來。
容筆者再次提醒，「測試覆蓋率」僅僅是一個衡量測試程度的指標，一味的追求測試覆蓋率的提升，或是以測試覆蓋率設定為 KPI 會提升團隊的內耗，請小心使用！與其過度追求測試覆蓋率的數值，不如將測試覆蓋率設定在一個閾值以上即可，並將資源成本投入在編寫有效且有意義的測試案例上，相輔相成，相信會帶來很好的品質成效。
不是，是 Typo，不要浪費問題 🤣🤣🤣，特別感謝提醒！
以上的軟體測試人員能力全圖，是筆者在這十年的軟體品質從業經驗中，所做的一個簡單歸納與總結，若有興趣的朋友，可參考投影片的相關內容。但下一個問題可能會說，那如果不是 SQL，還缺一格會是什麼？另一個方塊是 Git，就筆者的經驗而言，身為一個測試開發人員需要具備版控的能力，無論在寫自動化程式，或是在查找開發的程式碼，都會有很大的益處。
其實每間公司的成長軌跡不太一樣，每個組織內部的測試團隊的發展路徑皆需要被完整檢視後，找到其強項給予支持，找到弱項加以補強。
而筆者目前所待的公司 — 阿福管家，是一間非常以使用者中心的台灣本土公司。所有相關的決策也都是根據 「數字化」進行驅動，依據相關的數字反饋，透過迭代修正讓使用者能更直覺的體驗到我們想傳達的安心感，這也是為什麼目前阿福管家能擁有高達 7,000 萬下載量的核心價值！
依稀記得當時面試時，CEO Alex 跟筆者提到：目前對這個職位有兩個期望，一是希望能把「安心感」傳遞給我們的用戶，而產品在使用者手上必須有一定的品質。二是希望能讓測試團隊有更明確的發展未來，而公司願意投資在品質領域上！而上述內容跟 QA 的規劃有任何關係嗎？有的！
首先要記得，品質本身就應該是公司的 DNA，所以當有了明確的目標後，會先從統一團隊對於品質的核心價值觀開始，進行資源梳理，並打通品質在各團隊之間的渠道，給予不同的刺激後，建立基本作業流程這是短期的規劃。在中期的部份則是在建立好基礎的流程之上，給予目標與實踐方針，打造一個優化過後的流程體系，並深化與拉抬每個組成的軟/硬實力，無論是思考脈絡、技術、框架、工具或整合沉澱與輸出的技能。長期會更著重在整個組織的文化建立、持續改進、新舊技術的整合應用、針對新興領域能憑藉調研與過往的經驗延伸將其落地並取得正向成果，以期最終能在市場上有影響力。
礙於筆者目前身分，無法將團隊在短、中、長期的規劃內容完整揭露，因此給了一個相對概略的敘述，希望能給大家一些幫助，但若有想做細部討論，還是可以聯繫我們一日測試，我們很樂於分享過去的經驗。但還是必須得聲明，擁抱變化並審時度勢，時刻依據業界的風向給予團隊刺激是很重要的！而規劃，就是用來應對變化的。
很抱歉，因為沒有參與到各公司的專案或是流程，無法一言以蔽之。
但是 Scrum 有三個核心的角色，分別是：Scrum Master, Product Owner 與 Development Team，雖然 Scrum 並沒有專門的 QA 角色（因為以 Scrum 的定義而言，開發團隊是具有跨功能技能的自我組織團隊，負責設計、開發、測試和交付產品的功能。），但品質保證的工作在 Scrum 團隊中仍是非常重要的！因此，如果在 Scrum 團隊中擁有 QA 的背景，其實能在所屬團隊貢獻測試的專業知識，並參與到開發的其他方面，以確保團隊的協同合作，這會是相對好的做法。
建議是積極地參與 Design Review 的會議，由需求與設計的來源進行確認與了解，並透過專業的技術能力與經驗，針對需求或設計的原型提出風險預警。在「由軟體測試到品質工程 — QA 該知道的那些事」的講座中亦有提到，每個環節的釋出都應該是一個高品質的交付，在投影片的第 9 頁與第 21 頁皆有提及相關的內容與應該如何注意，若有興趣的夥伴歡迎下載查看。
寫在最後的最後，稟持初心，希望透過持續的學習能給予讀者們很有用的資訊！過往的所有分享很多是筆者與合作夥伴們的經驗談或是曾經的處理方式，無法透過 AI 生成，或是 AI 現在看到就截取走了。🤣 無論如何，希望能透過分享的模式激發出大家在軟體品質領域一點不一樣的想法，如果能幫助到大家那真的是「一日測試」的榮幸！如果此文章有幫助到你，請按此追蹤 一日測試 IG (oneday.software) ，與我們保持高度互動，以獲取最新的軟體資訊與技術方案！
👉🏻 點擊閱讀：由軟體測試到品質工程 — QA 該知道的那些事之 Q&A Part A
Howard Chiang
2023.08.10
