本文來自網易雲社區。html
做者:沈琪併發
測試周期結束時,QA同窗要完成一份質量報告,用來反映產品測試過程當中的問題及產品質量。做爲項目的測試負責人小R同窗通過各類繁雜的數據總結,完成質量報告,然而項目組成員在閱讀時卻出現如下問題:ide
案例一:
質量報告中包含了一項【bug數量按人員分佈】,這個數據統計使開發人員的bug數量產生一個鮮明的對比,形成某些開發的情緒不是很好。由於這個數據不能準確的代表開發的質量好或者很差,某些開發承擔的任務較多勢必形成bug數量的增長,而報告中沒有對bug數量多進行一個說明,會誤導閱讀質量報告的人。
改進方案:QA應對一些不能準確體現質量的數據作一個說明或者乾脆不要將此類數據歸入到質量報告裏。
測試
案例二:
質量報告中QA對【項目質量】、【風險評估】的結論沒有一個標準,致使質量報告中該2項的評判只靠QA的主觀判斷,沒法解釋項目方的質疑。
改進方案:QA部門定一個總體的標準,全部的質量報告嚴格按照該標準執行,可以讓產品方作一個橫向對比,而且在質量報告完成後與項目經理、技術負責人、策劃一塊兒review並確認質量報告中有異議的點。此外在羣發項目成員時將報告和質量一併發送,從而使項目成員明確質量報告的標準,避免歧義。目前標準還在制定中。大數據
通過以上的案例,做爲項目負責人如何寫好質量報告呢?下面來談一些個人看法。.net
在寫質量報告以前咱們首先要思考的問題是這份報告的受衆是哪些人,他們關心哪些問題,不關心哪些問題,甚至是他們不喜歡哪些問題。只有瞭解用戶的指望,咱們才能將有用的東西呈如今質量報告中。一般整個項目的成員分爲如下幾種人:htm
產品總監:着重面向終端用戶的bug數量及與其餘產品的比較。
策劃:着重項目是否能如期上線及上線的功能是否符合本身的指望。
項目經理:資源成本、風險評估及是否能正常上線。
開發:bug的結果分析及分析得出的產品質量信息。
測試:項目質量及流程控制。blog
因此一份詳細的質量報告應該包含上述的幾個部分。那是否將上面的信息統合一下就行了呢?答案是否認的,一份優秀的質量報告不只僅在數據上體現產品的質量,還應該告訴項目組成員,QA在整個測試過程當中作過哪些,將咱們的測試工做透明化,使你們對項目的質量更明確化:清楚哪些作過測試、哪些沒作過測試、是否有必要測試、沒作過測試的地方風險多大等等。遊戲
上面只是我我的的一些經驗之談,欠缺之處但願你們能指出更正。最後感謝相冊以及公衆平臺組QA的辛勤付出。資源
網易雲免費體驗館,0成本體驗20+款雲產品!
更多網易研發、產品、運營經驗分享請訪問網易雲社區。
相關文章:
【推薦】 當咱們在談論multidex65535時,咱們在談論什麼
【推薦】 盤點大數據在遊戲行業中的應用