3．測試人員第一件事做什么？

答案：打開Raid/BMS，查看指定給自己的Bug，驗(yàn)證已解決的Bug。

接下來，測試人員會(huì)…

根據(jù)測試用例檢驗(yàn)的Build
在Raid/BMS中記錄新發(fā)現(xiàn)的Bug
4．專家會(huì)診

參加者：項(xiàng)目經(jīng)理和開發(fā)組長、測試組長
通過Raid/BMS評估每個(gè)未解決的Bug
決定Bug優(yōu)先度
可否等到下個(gè)里程碑或版本解決？
誰來解決
預(yù)測項(xiàng)目實(shí)際進(jìn)度和發(fā)布時(shí)間
缺陷走勢圖 

5．回顧微軟的

構(gòu)造: daily build
開發(fā): 解決blocking bugs， 實(shí)現(xiàn)功能， check-out， code review， check-in
測試: BVT， 使用測試用例進(jìn)行測試
項(xiàng)目經(jīng)理/組長: 專家會(huì)診
6．微軟的做法解決了那些常見問題？

質(zhì)量問題

以前解決過的問題發(fā)布時(shí)又出現(xiàn)了，需要返工
無法預(yù)估發(fā)布時(shí)間 過早發(fā)布，帶來質(zhì)量和維護(hù)問題
測試發(fā)現(xiàn)的問題被忘卻或不了了之
無法衡量測試員和開發(fā)員的工作
程序中的問題往往在發(fā)布后才發(fā)現(xiàn)
文檔管理問題

文檔與程序脫節(jié)，文檔成為程序結(jié)果的描述
項(xiàng)目組把寫文檔看成負(fù)擔(dān)
團(tuán)隊(duì)協(xié)調(diào)問題

開發(fā)人員各自為戰(zhàn)，進(jìn)行整合時(shí)發(fā)現(xiàn)模塊銜接中的嚴(yán)重問題 需要作大的改動(dòng)
沒有保管好公司以往的版本和代碼，無法滿足用戶對舊版本的更改要求
開發(fā)人員離職對項(xiàng)目帶來很大沖擊，沒有人知道代碼在哪，或無法讀懂