游戲測試工作的自我修養及提升流程
1.輔助過程裁減、細致化、明確項目規范.清晰產品在面向最終用戶時的形態,對策劃案(產品需求)中闡述不清晰或者有邏輯沖突的地方提出質疑.實際開發中,程序員受限于工作的焦點,所以QA/QC人員必須做到更了解產品將要達到一個什么樣的形態,期間QA/QC人員的思路應保持在最終用戶的身份上,而非開發參與者
要求:
仔細閱讀策劃案(產品需求)
對闡述不清或者產品需求本身邏輯沖突所導致的疑問,要求做出釋疑
依照開發目標,清晰該開發階段產品的目標形態,以及與最終形態的差距
2.制定〈質量保證計劃〉 參考相應的產品策劃案,嚴謹斟酌產品需求的合理性以及大膽假設在即定需求下有可能產生的BUG,以此制定出質量保證計劃(測試流程) 產品將要實現的功能必須嚴格遵守產品需求,對于產品需求本身的合理性以及需求中所忽略的重要缺憾及時的對開發團隊提出見解
要求:
確?!顿|量保證計劃》嚴格的依照產品的需求
對需求合理性及缺憾性需求提出成熟的見解
制定出完善的質量保證計劃,測試流程中不僅要保證每項功能的實現還必須最大程度的假設可能出現的情況
3.產品檢查.確保產品在嚴格依照策劃案(產品需求)實現了有效功能的同時,最大力度的保證實際開發人員所未預料到的BUG得到如實的反饋.依照制定的《質量保證計劃》嚴謹的落實測試項,并且如實詳盡的以書面形式(BUGZILLA)反饋
要求:
遵照已有的測試計劃完整的進行測試
參考現有產品需求,以用戶的角度斟酌是否合理和完善,并且如實向開發團隊反饋成熟建議
在確保測試流程完全落實,并且所有已知BUG已經反饋的情況下,進行大量重復性的測試(就公司產品而言,就是反復玩,實際工作中,僅僅有30%左右的BUG是在預先制定的測試流程中可以體現的,其他大部分BUG在無序測試中反而更容易被偵測到)
未預料到的BUG出現,則總結該BUG的類型,并且將非偶然性的BUG添加入《質量保證計劃》中。偶然性BUG權衡后記錄,見注①
4.過程審計 統計反饋BUG的隸屬對象 明確BUG會將由誰來處理,并且依照項目進度對BUG劃分優先級
要求:
明確BUG的處理方,并且在BUGZILLA中指定正確的對象(不排除A的代碼出現的BUG將由B處理的情況,具體實際對象應參考項目進度或服從安排)
明確目前的進度下將要處理的BUG
將反饋BUG的ID對應告知相應的開發人員
5.跟蹤問題處理.根據項目的實際開發進度,跟蹤已知的產品BUG處理情況.已[來源:GameRes.com]處理的BUG經過反復測試后,及時反饋
要求:
重復產品檢查過程
核實BUG是否完全處理,以及最大程度的保證沒有延伸BUG
及時在如:bugzilla中反饋BUG目前狀態。
6.度量及報告.資源有限的情況下,面對多個項目或者單元需要測試,QA/QC人員需要評估并且如實反饋
要求:
在項目進行中,有核心部分需要有較大的把握保證其穩定性,在人力和時間資源有限的情況下,將精力更多的花費在此方向上,對于整個項目來說,是更優選擇
7.經驗積累 自身的工作經驗的累積以外,對日漸成熟的工作方式及流程做書面保留,以實現公司非物質財富的累積
注①:偶然性BUG的處理在權衡后,明確其產生環境并加以記錄。如:使用不同引擎開發的產品 開發環境的不同其偶然性BUG總有著必然聯系,對此加以記錄方便后續工作者的快速任職
原文轉自:http://www.anti-gravitydesign.com