9. 你遇到過有人說“我以為…”么?
要消滅“我以為”。Never assume anything。
10. 你們的項目組中所有的人都坐在一起么?
需要。我反對Virtual Team，也反對Dev在美國、Test在中國這種開發方式。能坐在一起就最好坐在一起，好處多得不得了。
11. 你們的進度表是否反映最新開發進展情況?
應該反映。但是，應該用Baseline的方法來管理進度表：維護一份穩定的Schedule，再維護一份最新更改。Baseline的方法也應該用于其它的Spec。Baseline是變更管理里面的一個重要手段。
12. 你們的工作量是先由每個人自己估算的么?
應該讓每個人自己估算。要從下而上估算工作量，而不是從上往下分派。除非有其他原因，比如政治任務工期固定等。
13. 你們的開發人員從項目一開始就加班么?
不要這樣。不要一開始就搞疲勞戰。從項目一開始就加班，只能說明項目進度不合理。當然，一些對日軟件外包必須天天加班，那屬于剝削的范疇。
14. 你們的項目計劃中Buffer Time是加在每個小任務后面的么?
不要。Buffer Time加在每個小任務后面，很容易輕易的就被消耗掉。Buffer 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。但這種約定可以根據產品質量現狀適當進行調整。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
