55. 你們項目組中有人能說出產品的當前整體質量情況么?
要有。當老板問起這個產品目前質量如何，Test Lead/Manager應該負責回答。
56. 你們有單元測試么?
單元測試要有的。不過沒有單元測試也不是不可以，我做過沒有單元測試的項目，也做成功了——可能是僥幸，可能是大家都是熟手的關系。還是那句話，軟件工程是非常實踐、非常工程、非常靈活的一套方法，某些方法在某些情況下會比另一些方法好，反之亦然。
57. 你們的程序員是寫完代碼就扔過墻的么?
大忌。寫好一塊程序以后，即便不做單元測試，也應該自己先跑一跑。雖然有了專門的測試人員，做開發的人也不可以一點測試都不做。微軟還有Test Release Document的說法，程序太爛的話，測試有權踢回去。
58. 你們的程序中所有的函數都有輸入檢查么?
不要。雖然說做輸入檢查是write secure code的要點，但不要做太多的輸入檢查，有些內部函數之間的參數傳遞就不必檢查輸入了，省點功夫。同樣的道理，未必要給所有的函數都寫注釋。寫一部分主要的就夠了。
59. 產品有統一的錯誤處理機制和報錯界面么?
要有。最好能有統一的error message，然后每個error message都帶一個error number。這樣，用戶可以自己根據error number到user manual里面去看看錯誤的具體描述和可能原因，就像SQL Server的錯誤那樣。同樣，ASP.NET也要有統一的Exception處理�？梢詤⒖加嘘P的Application Block。
60. 你們有統一的代碼書寫規范么?
要有。Code Convention很多，搞一份來發給大家就可以了。當然，要是有FxCop這種工具來檢查代碼就更好了。
61. 你們的每個人都了解項目的商業意義么?
要。這是Vision的意思。別把項目只當成工作。有時候要想著自己是在為中國某某行業的信息化作先驅者，或者時不時的告訴team member，這個項目能夠為某某某國家部門每年節省多少多少百萬的納稅人的錢，這樣就有動力了。平凡的事情也是可以有個崇高的目標的。
62. 產品各部分的界面和操作習慣一致么?
要這樣。要讓用戶覺得整個程序好像是一個人寫出來的那樣。
63. 有可以作為宣傳亮點的Cool Feature么?
要。這是增強團隊凝聚力、信心的。而且，“一俊遮百丑”，有亮點就可以掩蓋一些問題。這樣，對于客戶來說，會感覺產品從質量角度來說還是acceptable的�；蛘哒f，cool feature或者說亮點可以作為質量問題的一個事后彌補措施。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
