Time要整段的加在一個Milestone或者checkpoint前面。
15. 值得再多花一些時間，從95%做到100%好值得，非常值得。
尤其當項目后期人困馬乏的時候，要堅持。這會給產品帶來質的區別。
16. 登記新缺陷時，是否寫清了重現步驟？
要。這屬于Dev和Test之間的溝通手段。面對面溝通需要，詳細填寫Repro Steps
也需要。
17. 寫新代碼前會把已知缺陷解決么？要。每個人的缺陷不能超過10個或15個，
否則必須先解決老的bug才能繼續寫新代碼。
18. 你們對缺陷的輕重緩急有事先的約定么？
必須有定義。Severity要分1、2、3，約定好：藍屏和Data Lost算Sev 1，
Function Error算Sev 2，界面上的算Sev 3。但這種約定可以根據產品質量現狀
適當進行調整。
19. 你們對意見不一的缺陷有三國會議么？必須要有。要有一個明確的決策過程
。這類似于CCB (Change Control Board)的概念。
20. 所有的缺陷都是由登記的人最后關閉的么？
Bug應該由Opener關閉。Dev不能私自關閉Bug。
21. 你們的程序員厭惡修改老的代碼么？
厭惡是正常的。解決方法是組織Code Review，單獨留出時間來。XP也是一個方法
。
22. 你們項目組有Team Morale Activity么？
每個月都要搞一次，吃飯、唱歌、Outing、打球、開卡丁車等等，一定要有。不
要剩這些錢。
23. 你們項目組有自己的Logo么？
要有自己的Logo。至少應該有自己的Codename。
24. 你們的員工有印有公司Logo的T-Shirt么？
要有。能增強歸屬感。當然，T-Shirt要做的好看一些，最好用80支的棉來做。別
沒穿幾次就破破爛爛的。
25. 總經理至少每月參加次項目組會議要的。
要讓team member覺得高層關注這個項目。
26. 你們是給每個Dev開一個分支么？
反對。Branch的管理以及Merge的工作量太大，而且容易出錯。
27. 有人長期不Check-In代碼么？
不可以。對大部分項目來說，最多兩三天就應該Check-In。
28. 在Check-In代碼時都填寫注釋了么？
要寫的，至少一兩句話，比如“解決了Bug No.225”。如果往高處拔，這也算做
“配置審計”的一部分。
29. 有沒有設定每天Check-In的最后期限？
要的，要明確Check-In Deadline。否則會Build Break。
30. 你們能把所有源碼一下子編譯成安裝文件嗎？
要的。這是每日編譯（Daily Build）的基礎。而且必須要能夠做成自動的。
31. 你們的項目組做每日編譯么？
當然要做。有三樣東西是軟件項目/產品開發必備的：1. bug management; 2.
文章來源于領測軟件測試網 http://www.kjueaiud.com/
