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

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

接下來，測試人員會…

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

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

5．回顧微軟的

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

質量問題

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

文檔與程序脫節(jié)，文檔成為程序結果的描述
項目組把寫文檔看成負擔
團隊協(xié)調問題

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