前言

測試不是僅僅檢查有沒有問題，還有一個重點是「學習」。發揮人的特色，在經驗中學習，我們可以藉由測試結果、bug issue 中檢討，讓下一次的開發與測試更為準確。

測試結果呈現

測試完成後，呈現測試結果以及進行反思和檢討是非常重要的步驟，以確保測試流程的效益和品質持續改進。

在反思的第一步中，需要整理出相關資料，這時候就是要一些測試的報告。經由這些透明的測試結果呈現，讓團隊成員和利益相關者了解測試的進展和品質。它促進了團隊內外的溝通和理解。而團隊成員可以快速的識別與解決問題，進而改善自己與團隊，讓開發與測試得以更為順暢。

首先，第一步就是要呈現測試結果，可以用下列的方式呈現：

• 測試報告（Test Report）：撰寫一份詳細的測試報告，記錄測試過程中的所有關鍵訊息，包括測試案例的執行結果、問題列表、測試覆蓋率等。這份報告應該能夠清楚地傳達測試結果，以及任何發現的問題。
• 測試度量（Test Metrics）：提供有關測試執行的度量數據，例如通過的測試案例數、失敗的測試案例數、測試覆蓋率、問題的嚴重性分佈等。這些度量數據有助於評估測試的效率和品質。
• 問題報告（Issue Reports）：提供問題報告，詳細說明每個發現的問題，包括問題描述、重現步驟、嚴重性、優先順序和解決狀態。這有助於開發團隊更好地理解和解決問題。

關於測試報告

測試報告，可以是一份完整的報告，涵蓋方方面面，也可以是簡單的整理測試概況以及解決進度。簡單來說，是將測試結果和相關數據呈現給團隊成員的文件，會根據每個團隊的屬性提供不一樣程度的報告。

以下是提供較為完整的內容：

• 報告摘要（Report Summary）：報告開頭通常包括一個簡要的摘要，概述了測試的目標、範圍和主要結論。這是為了讓讀者迅速了解測試的主要結果。
• 測試環境（Test Environment）：說明在哪個環境中執行測試，包括硬體、軟體、操作系統版本等訊息。這有助於確保測試結果的可重現性。
• 測試計劃和策略（Test Plan and Strategy）：提供測試計劃和策略的概要，包括測試的目標、測試案例的規劃和預期的測試覆蓋範圍。
• 測試執行（Test Execution）：詳細描述測試的執行過程，包括執行的測試案例、執行日期、執行人員等訊息。這部分通常包括測試結果的摘要，例如通過的案例數、失敗的案例數等。
• 問題和缺陷（Issues and Defects）：列出在測試過程中發現的問題、缺陷和改進建議。每個問題通常包括標題、嚴重性、狀態、分派給誰等訊息。
• 測試度量（Test Metrics）：報告測試的關鍵度量指標，如通過率、失敗率、覆蓋率等。這有助於評估測試的效率和品質。
• 測試日誌（Test Log）：提供詳細的測試日誌，記錄每個測試案例的執行步驟和結果，以便於問題追蹤和日後的分析。
• 總結和建議（Summary and Recommendations）：在報告的結尾，通常提供了對測試結果的總結，以及對改進和下一步行動的建議。

以業界來說，有很多軟體可以協助做出這樣的測試報告，像是 TestRail、Jira 等等管理工具都可以進行這樣的報告產出，差別就是在於他們著重的面向不同而已。TestRail 重點要於 Test Plan 和 Test Run，而 Jira 則是在於專案管理，與處理上。因此我們團隊進行報告時，會兩者結合，一來可以知道測試的度量和測試計畫，二來可以知道問題的多寡、嚴重性，以及現在的處理狀態。

關於測試度量

測試度量（Test Metrics）是測試流程中的關鍵指標和度量數據，用於評估測試的進展、品質和效率。這些指標和數據提供了對測試過程的可視化和定量評估，有助於團隊了解測試的狀況，識別潛在的問題，並制定改進策略。

常見的度量指摽有：

• 通過的測試案例數（Passed Test Cases）：這是指在測試過程中成功通過的測試案例數量。它表示了應用程式的某個部分或整體功能的正確性。
• 失敗的測試案例數（Failed Test Cases）：這是指在測試過程中未能通過的測試案例數量。失敗的測試案例可能指示了應用程式中的潛在問題。
• 未執行的測試案例數（Not Run Test Cases）：這是指在測試計劃中包含但尚未執行的測試案例數量。這可能是由於資源不足、時間不足或其他原因造成的。
• 測試覆蓋率（Test Coverage）：測試覆蓋率衡量了測試中覆蓋的程式碼、功能或需求的百分比。高測試覆蓋率表示測試涵蓋了更多的程式碼或功能，有助於減少潛在的未檢測問題。
• 測試通過率（Pass Rate）：這是指通過的測試案例數量與總測試案例數量之比。通過率可以幫助評估測試的整體成功率。
• 平均測試執行時間（Average Test Execution Time）：這是指每個測試案例的平均執行時間。它有助於評估測試執行的效率。
• 問題數量（Number of Issues）：這是指在測試過程中識別並記錄的問題數量。問題可以包括錯誤、缺陷、建議的改進等等。
• 嚴重性分佈（Severity Distribution）：這是指已識別問題的嚴重性級別分佈。通常分為致命、嚴重、一般、輕微等級別，有助於評估問題的嚴重程度。
• 測試執行進度（Test Execution Progress）：這是指測試計劃中的測試案例執行進度。它可以顯示哪些測試已經完成，哪些尚未執行，以及哪些正在進行中。
• 測試自動化覆蓋率（Test Automation Coverage）：這是指自動化測試覆蓋的功能或需求的百分比。高自動化覆蓋率可以提高測試的效率和一致性。

簡單來說，就是藉由測試案例中，檢討問題的狀況，像是可以檢討為什麼有這麼多致命的
bugs，是不是開發時沒有注意到；或者是，為什麼測試的執行時間這麼長，是不是程式沒有寫好等等，藉由這樣的數據，可以快速的檢討，指出值得優化的地方。

關於問題報告

不同於測試度量（Test Metrics）是針對測試的案例進行整理與分析，問題報告（Issue Reports）則是以問題本身去做分析，根據問題的重要性、優先級進行探索。藉由狀態管理，可以讓各關係者可以知道現況，確保問題都有被適當的處理，而未來也可以知道問題的發生原因，避免以後重蹈覆轍。

以下是問題報告的主要元素：

• 問題描述：這是報告中最重要的部分，它清楚地描述了問題的性質、現象和影響。問題描述應該盡量詳細，以便讀者能夠理解問題的本質，無需查看其他文件或資源。
• 重要性和優先級：問題報告通常包括對問題重要性的評估，如嚴重性、緊急性和影響程度。這有助於決定問題的處理優先級，確保最重要的問題得到及時處理。
• 問題的狀態：問題報告中會跟蹤問題的當前狀態，例如新建（New）、處理中（In Progress）、已解決（Resolved）或關閉（Closed）。這有助於追蹤問題的進展。
• 詳細訊息：問題報告可能包括其他詳細訊息，如問題的提交日期、報告人員、處理人員、問題的定位、相關的測試案例、屬性、附件、截圖等等。
• 相關記錄：問題報告可能包含與問題相關的其他記錄，如測試日誌、日誌文件、錯誤訊息、異常堆棧、版本訊息等。這些記錄有助於開發和測試團隊更容易地定位和修復問題。

進行反思

反思的儀式，可能會在專案結束時，或是每個 sprint（衝刺）後的 Retroactive（回顧會議）進行檢討。簡單來說會有這樣的流程，進行反思：

• 測試回顧會議（Test Retrospective Meeting）：安排一個測試回顧會議，參與測試的團隊成員一起討論測試過程中的成功和挑戰。這是一個學習和改進的機會。
• 識別成功和改進點（Identify Successes and Improvements）：在回顧會議中，識別測試過程中的成功之處，以及需要改進的方面。這可以包括工作流程、測試策略、工具使用等等。
• 制定行動計劃（Action Plan）：基於回顧的結果，制定一個具體的行動計劃，包括改進措施、負責人、時間表和目標。確保每個改進點都有明確的行動計劃。
• 追蹤改進（Track Improvements）：在下一個測試週期中，追蹤和評估實施的改進措施。確保這些改進能夠產生實際的影響。
• 持續改進（Continuous Improvement）：測試過程是一個不斷改進的過程。定期回顧測試流程，並持續進行改進，以提高測試的效率和品質。

後記

在這階段，除了大量的使用 TestRail 和 Jira 外，也會使用整合的報告呈現給各單位看，像是可以用文件的方式詳實報告，或是用圖表的方式如 Dashboard、Silde 方式呈現。就是需要一個更廣泛性的整合，讓除了測試團隊外，像是開發團隊、專案經理、營運團隊等等，可以快速地瞭解產品的狀況，以及現在的處理進度。當然有很多工具可以使用，除了 TestRail 和 Jira 本身外，還有 Confluence、Google Document 可以使用，就看團隊的方向，以及要讀的客群為何。

參考資料

• What is a Sprint Retrospective?