最近參與了幾回面試,面試者的簡歷中都會說起:需求或者版本測試結束後會進行版本總結,而不只僅是提供一份測試報告。html
因而特地追問了一下,總結中都包含什麼內容,答覆上基本都是圍繞這次測試過程當中發現的BUG數量以及修復狀況進行分析總結,其它方面的延伸比較少。面試
本身也思考了一些,在這裏與你們交流,歡迎你們爭相討論。併發
區別與測試報告通常是針對開發完成編碼後對開發質量的一個總結。單元測試
測試總結站的角度,更可能是在整個軟件研發過程當中全部問題的總結。測試
包含需求蒐集階段的問題、產品需求分析設計階段的問題、開發設計編輯階段的問題、產品測試階段的問題、項目上線後反饋的問題的總結。優化
1.需求測試或者版本發佈測試結束後編碼
此時進行總結更具備時效性,但缺乏使用者對此版本的直接反饋,只能算是內部總結。設計
2.產品上線應用一段時間以後3d
增長了客戶使用後的反饋,更有利於從第三方視角反饋發佈版本的質量狀況及用戶視角暴露的問題。excel
組織者:通常由測試經理或者對應項目的測試主管組織。
參與者:項目總監、產品經理、開發經理、測試經理及其它相關開發測試工程師。
1.召開總結會議(載體:word、excel、ppt、視頻等),經常使用ppt。
2.郵件溝通反饋
3.視頻會議等
具體形式因團隊而已,重點要關注效果,總結後要造成可落地的改進計劃。
版本總結中應該包含哪些內容?那些量化的數據能夠分析?
這兩日讀了Vincent的軟件質量報告模板-產品質量度量,針對研發及測試階段的分析說明已經很到位。
涉及到開發、測試計劃偏離度的分析,缺陷類型、優先級、分佈、質量趨勢的分析,建議你們能夠仔細拜讀下。
裏面涉及的內容這裏就再也不次說明,其餘方面的內容這裏作下補充,你們能夠整合一份適用於本身公司的一套標準。
前邊咱們提到,要總結需求蒐集階段的問題、產品需求分析設計階段的問題、開發設計編碼階段的問題、產品測試階段的問題、項目上線後反饋的問題等。
針對需求提交是否及時、是否提交符合規範、描述是否清晰、業務場景是否完備等進行統計分析。
如圖中V1.0版本需求按時提交率只有75%,頗有可能形成版本規劃延期或者版本發佈時間壓縮。
根據相關數據及測試過程當中產生的影響,針對需求蒐集放提出相應建議,並要求需求蒐集放給出相應的保障措施及計劃。
針對需求,產品是否按時審批、按時提交相關設計、組織相關需求評審溝通會議、插入需求佔比等相等
此處插入需求佔比,也可根據插入需求工時與版本規劃工時進行對比統計。
針對開發設計提交及時性、開發計劃按時完成狀況、缺陷數量、缺陷密度、缺陷修復週期、缺陷分類、缺陷修復狀況分析Vincent文章中已經說明。
下面咱們從另一個角度,工時投入狀況去分析。
從上述看,咱們可以發現開發在自測與設計階段的投入較少,從而形成大部分精力都在修復BUG。
建議開發:按期進行設計Review、代碼Review,要求開發作單元測試,寫自測報告。
針對測試用例、測試報告提交的及時性、版本發佈內容提交的完備性、計劃按時完成狀況、缺陷遺留狀況、客戶,項目反饋問題狀況進行分析。
下面咱們從另一個角度,工時投入狀況去分析。
從上述看,測試在BUG與產品設計優化上的投入將近佔了測試工做的一半,說明開發質量與產品設計存在必定的問題。
針對項目/客戶反饋問題進行分析總結,相似缺陷分析,重點總結遺漏的緣由及後需的規避措施。
上述看,場景遺漏致使的問題較多,測試側應該在用例設計及評審上作重點改進。
基於測試總結過程當中的數據分析,咱們提出了對部門的建議。
針對提出的建議,各部門要配合梳理可落地的改進措施,彙總到測試部門,測試部門負責整理髮布,並監督改進的落地。
以保障在下個版本測試過程當中,相關問題可以獲得有效的規避,從而提高工做的效率與質量。
針對上述各個階段的分析總結,除了一些具體的數據之外,能夠增長一些具體的案例,這樣在分析總結是你們才能切身體會。
數據的背後不是吐槽那個階段,那個部門的很差,目的是透過數據看本質,不斷完善咱們的工做流程,達到高效協做,高質輸出的目標。