系統測試團隊是檢驗軟件需求完成度,軟件質(zhì)量,用戶(hù)體驗的重要角色,只有系統測試團隊對需求以及用戶(hù)的最終訴求有充分的理解后,才能提高測試的效率和質(zhì)量。但是在現實(shí)工作中測試團隊在需求開(kāi)發(fā)階段的參與度往往被忽視,測試團隊總是被動(dòng)的接受需求。另一種情況是,了解了測試人員參與需求開(kāi)發(fā)的重要性,但是不知道該如何參與,關(guān)注點(diǎn)是什么。本文按照需求開(kāi)發(fā)的不同階段為大家詳細介紹系統測試團隊在該階段的關(guān)注點(diǎn)是什么,如何參與其中以及如何為接下的測試工作打好基礎。
一、 制定用戶(hù)需求開(kāi)發(fā)計劃
在制定需求開(kāi)發(fā)計劃時(shí)往往忽略了測試人員, 所以首先測試人員要保證是需求開(kāi)發(fā)小組的一員。
了解需求開(kāi)發(fā)的進(jìn)度安排和期限,明白全盤(pán)的計劃。在相應的階段,切換不同的關(guān)注點(diǎn)。
不僅要了解調查的對象是誰(shuí)和這個(gè)對象對應的調查內容,還要了解調查對象的職務(wù)和客戶(hù)方的組織架構以及決策鏈。
明確需求開(kāi)發(fā)后的產(chǎn)出物有哪些,這些產(chǎn)出物都是日后系統測試階段的重要輸入。
二、 用戶(hù)需求調研準備
需求開(kāi)發(fā)小組會(huì )綜合考慮來(lái)制定調研方式,測試人員需要明白不同調研方式的特點(diǎn),和為什么要選用這些調研方式。
測試人員熟悉用戶(hù)提供的資料及業(yè)務(wù)狀況后,以用戶(hù)的角度準備部分調研問(wèn)題。
分享類(lèi)似項目的經(jīng)驗。
三、 用戶(hù)需求調研
測試人員在需求獲取過(guò)程中,獲取和整理專(zhuān)業(yè)詞匯,項目組內達成一致。保證測試人員與其他項目成員溝通中無(wú)障礙。同時(shí)可以運用到測試用例或Bug的描述中,體現專(zhuān)業(yè)性。
進(jìn)一步明確和細化的客戶(hù)組織結構、人員類(lèi)型、能力水平等組織狀態(tài)。通過(guò)對用戶(hù)組織的評估,確定業(yè)務(wù)應用的場(chǎng)景、相關(guān)干系人等信息。
在初步和客戶(hù)溝通中,首先要進(jìn)一步明確客戶(hù)對軟件的期望。不要太關(guān)注軟件的細節。深度溝通時(shí)要關(guān)注細節,記錄需求中不明確的問(wèn)題,及時(shí)與客戶(hù)溝通確認。
四、 用戶(hù)需求分析
運用場(chǎng)景分析法,和需求開(kāi)發(fā)人員共同梳理用戶(hù)工作流程,捕獲場(chǎng)景的細節。觀(guān)察用戶(hù)執行業(yè)務(wù)任務(wù)的過(guò)程,場(chǎng)景測試大綱的草稿就產(chǎn)生了。
在梳理用戶(hù)工作流程的同時(shí),數據項也要識別出來(lái)。測試人員可以開(kāi)始提前準備測試數據。
測試人員可以依據需求優(yōu)先級來(lái)制定測試計劃。
通過(guò)系統運行環(huán)境分析,了解系統的環(huán)境要求,提早做好測試環(huán)境準備。
將功能性和非功能性需求分離。整理后初步形成軟件的功能和非功能性驗收標準。同時(shí)也可作為編寫(xiě)測試用例的輸入,測試用例也可以分這兩大類(lèi)來(lái)寫(xiě)。
用戶(hù)文檔需求包括(但不限于):用戶(hù)手冊、聯(lián)機幫助、系統安裝手冊、配置文件、自述文件等。這些文檔也是產(chǎn)品之一,測試人員也要保證其質(zhì)量,不要忽視。
五、 用戶(hù)需求文檔編寫(xiě)
與開(kāi)發(fā)人員一起制定需求分析文檔,通過(guò)討論而不是被動(dòng)接受的方式確定需求文檔。
每次的文檔變更,測試人員都要清楚文檔變更了哪些內容,為什么這樣變。
測試人員編寫(xiě)完成測試大綱初稿。
六、 需求的評審及確認
通常情況,內部會(huì )舉行多輪的評審,測試人員都要參加,發(fā)現需求不清、不一致或者二義性等問(wèn)題。
在客戶(hù)評審中,通過(guò)客戶(hù)提出的修改建議,了解客戶(hù)的想法,思考需求中還有沒(méi)有類(lèi)似的問(wèn)題。
需求的優(yōu)先級一定要和客戶(hù)確認。
確認完成后,進(jìn)入開(kāi)發(fā)和測試計劃階段。
原文轉自:http://blog.sina.com.cn/s/blog_d173cdd80101gg31.html