由軟體測試到品質工程 — QA 該知道的那些事之 Q&A Part A
📢 如果此文章有幫助到你，請按此追蹤 一日測試 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 在邀請我們一日測試技術分享時，最終題目的定稿會定在「品質工程」的原因。也因為分享當日的時間有限，無法一一回答每個人的問題，希望透過這系列的文章回答能回饋給當日參與講座的成員們，特別感謝大家對於講座活動的積極參與！
過往有曾經測過 SDK 的經驗，而如同講座所分享的核心思考，每一個入參與出參都有其重要性，首先要釐清業務需求並確認該 SDK 所負責的功能為何，知道 SDK 在整體流程的上下游所扮演的角色，建議使用功能整合測試的維度把 SDK 變成其中的一個組件，確認其功能是否能正常運行。而這個組件本身的判空邏輯或是否有 Cache 的處理機制也是一個注意的要點，可透過每次的請求，看相關日誌檔的紀錄來確保行為是否如期，而自動化的部份，將其當做黑箱進行端對端的驗測，覆蓋業務的使用場景，也不失為一個好方法。
業務的持續新增，端看是否能完整的交付到使用者手上並產生相關價值，若無法，則必須思考這類型的業務是否有其持續新增的必要性。需求總有其優先級，找到最重要且最緊急的需求，透過系統化的方式給予解決方案，並要確保其方案的提出具有復用性。每個需求所要達到的品質要求也會有所不同，因此，投入到業務需求中的測試成本不會是一樣的，可以透過資源的彈性安排，來消化持續新增的業務。
對測試團隊而言，手動測試與自動化測試的比例，一直是業界很關注的一件事情。而有個迷思是，似乎只要自動化測試能夠大範圍的涵蓋，就一定是好的；換個角度想，如果一再的使用自動化測試，但這些自動化卻沒有辦法抓到有效的 Bug，那這些自動化測試是不是有其必要性，也是一個值得思考的議題。
筆者的建議是：先釐清自動化本身存在的價值是什麼？若是為了要節省手動重複回歸驗測的成本。老闆們，那這部份的自動化就很值得投資！🙋🏻♂️ 因為並未涉及新的業務知識領域，一再執行同樣案例的手動測試並沒有辦法提高測試人員的技術能力。在流程不變的前提下，自動化的出錯機率相對低，測試結果也相對可信，那就提高自動化測試的產能！而自動化穩定度的部份，則需要透過時間的積累進行持續調整，這部份的成本是勢必得要投入的。但如果是新型業務的展開，手動測試就有其不可取代的位置，以不同的測試案例發想覆蓋可能的業務情境，能夠很好的保障使用者故事的實踐。
舉個簡單的例子，我們要測試一個計算功能：「加法」，而業務的實際情境是：「在一個兒童簡易的玩具計算機上只有九個鍵，分別是 1+1, 2+2, 3+3,…進行加法」。如果先不看業務，只知道要測加法，你會想到什麼？入參的差異是一個很明顯的變因，所以入參的內容就要先定義好，此時就會先想到會不會有 0？如果是小數相加，可能會有什麼結果？如果是循環小數相加又會有什麼結果？如果入參不只是數字，會不會有英文字母？會不會有不同的字元？Emoji 呢？這些都要被排除……。但如果知道今天的測試目的，把業務情境加進來，那自動化的案例就會變得很簡單。
發現了嗎？沒有業務的定義，先不論手動或自動，測試本身本來就是發散的，沒有邊界的，甚至可以說測了可能沒有任何的意義。回歸到現實就會變成，「那個誰誰誰，幫我測一下那個功能，因為我改了一個東西！」，但身為測試的你，不理解業務的 knowhow，根本不知道改了什麼，也不知道細節調整了什麼，這次的修改是為了什麼目的，一整個瞎子摸象的狀態，如果連手動的測試範圍都不確定了，那自動化還能精準的測到位嗎？
AI 工具在近期如雨後春筍般的冒出，甚至許多大廠都各自在研發自己的解決方案，因此，以我們的角度而言不適合推薦任何的 AI 工具使用。就拿 ChatGPT 來說，有 GPT-3.5 與 GPT-4 的語言模型，其結果的生成完全看使用者的需求，如果你只需要做到 AI 幫忙做簡單的歸納，那 GPT-3.5 也許就能符合你的期待，但如果你今天需要的不只是歸納，甚至請 AI 依據過往結果做後續的預測，並給予可持續性的解法，整體的複雜度更甚歸納，那 GPT-4 也許會是個更好的選擇。
以目前業界的使用 AI 應用於軟體測試的方案，主流的發展還是著重在「解析測試結果」與「挑選/生成適合的測試案例」這兩個方向，而 AI 使用的最終結果仍然需要透過人類進行確認是否有符合預期，因此，目前並未發展出一套完整不需要人力介入的品質解決方案，但引入 AI 工具，對既有的流程有著一定的顯著的效益，相信在不久的未來，應該會有許多超級平台生成，只要輸入既定的需求格式與內容後，並會透過 AI 自動產生相關的自動測試方案與案例的使用，但依舊需要透過人力介入進行降噪、挑選、修正其結果，讓我們期待這個時間點的到來！
每間公司與每個測試團隊對於 QA 的測試品質指標都有不一樣的定義，若以筆者的經驗而言，我會著重在以下幾個指標，也請特別注意，並非所有指標都適用於所有情況：
- 測試覆蓋率（Test Coverage）：測試案例覆蓋程式碼、功能或系統的百分比，了解目前有哪些業務或執行面是已經被覆蓋了，愈齊全自然是愈好，但怎麼衡量其效用就是另一個議題了，很多企業將測試覆蓋率轉成 KPI 的指標，但會變相的為了衝高測試覆蓋率而寫了沒有意義的自動化，這就不是我們所預期的了！
- 速度（Velocity）：於品質工程的各個環節（可參考投影片的相關內容）將速度提升，無論是知識領域的涉及、核心基礎功能的建模、測試方案與案例的產生、測試的執行速度，甚至是編寫基本的業務校驗規則，都是可以提速的範圍
- 開發迭代中的缺陷趨勢（Bug Trend in Development Iterations）：在特定時間內，同一種類型的業務或專案下，缺陷的趨勢是否是下行走向，如果你們的品質團隊有利用領域劃分測試負責人，那這會是一個評估該特定領域表現的重要指標，可以幫助發現和解決早期的品質問題，大量降低解決缺陷的成本（可參考投影片的相關內容）
- MTTD/MTBF/MTTR：相關的穩定性指標，也是評估品質團隊在處理線上緊急問題時，是否已經有既定的標準流程，能夠按部就班的處理，並想盡辦法的降低對使用者的影響
- 投資報酬率與精確度（ROI ＆ Accuracy）：測試的資源有限，因此依據優先級將測試資源投入特定的項目與專案，同時並行提高測試資源的使用，在測試的方向與範圍減少不確定性，以提高精確度（可參考投影片的相關內容）
👉🏻 點擊閱讀：由軟體測試到品質工程 — QA 該知道的那些事之 Q&A Part B
Howard Chiang
2023.08.06
