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或者說亮點可以作為質量問題的一個事后彌補措施。
64. 盡可能縮短產品的啟動時間要這樣。軟件啟動時間（Start-Up time）是客戶對性能好壞的第一印象。
65. 不要過于注重內在品質而忽視了第一眼的外在印象程序員容易犯這個錯誤：太看重性能、穩定性、存儲效率，但忽視了外在感受。而高層經理、客戶正相反。這兩方面要兼顧，協調這些是PM的工作。
66. 你們根據詳細產品功能說明書做開發么？
要這樣。要有設計才能開發，這是必須的。設計文檔，應該說清楚這個產品會怎么運行，應該采取一些講故事的方法。設計的時候千萬別鉆細節，別鉆到數據庫、代碼等具體實現里面去，那些是后面的事情，一步步來不能著急。
67. 開始開發和測試之前每個人都仔細審閱功能設計么？
要做。Function Spec review是用來統一思想的。而且，review過以后形成了一致意見，將來再也沒有人可以說“你看，當初我就是反對這么設計的，現在吃苦頭了吧”
68. 所有人都始終想著The Whole Image么？
要這樣。項目里面每個人雖然都只是在制造一片葉子，但每個人都應該知道自己在制造的那片葉子所在的樹是怎么樣子的。我反對軟件藍領，反對過分的把軟件制造看成流水線、車間。參見第61條。
69. Dev工作的劃分是單純縱向或橫向的么？
不能單純的根據功能模塊分，或者單純根據表現層、中間層、數據庫層分。我推薦這么做：首先根據功能模塊分，然后每個“層”都有一個Owner來Review所有人的設計和代碼，保證consistency. 70. 你們的程序員寫程序設計說明文檔么？
要。不過我聽說微軟的程序員1999年以前也不寫。所以說，寫不寫也不是絕對的，偷懶有時候也是可以的。參見第56條。
71. 你在招人面試時讓他寫一段程序么？
要的。我最喜歡讓人做字符串和鏈表一類的題目。這種題目有很多循環、判斷、指針、遞歸等，既不偏向過于考算法，也不偏向過于考特定的API. 72. 你們有沒有技術交流講座？
要的。每一兩個禮拜搞一次內部的Tech Talk或者Chalk Talk吧。讓組員之間分享技術心得，這筆花錢送到外面去培訓劃算。
73. 你們的程序員都能專注于一件事情么？
要讓程序員專注一件事。例如說，一個部門有兩個項目和10個人，一種方法是讓10個人同時參加兩個項目，每個項目上每個人都花50%時間；另一種方法是5個人去項目A，5個人去項目B，每個人都100%在某一個項目上。我一定選后面一種。這個道理很多人都懂，但很多領導實踐起來就把屬下當成可以任意拆分的資源了。
74. 你們的程序員會夸大完成某項工作所需要的時間么？
會的，這是常見的，尤其會在項目后期夸大做某個change所需要的時間，以次來抵制change.解決的方法是坐下來慢慢磨，磨掉程序員的逆反心理，一起分析，并把估算時間的顆粒度變小。
75. 盡量不要用Virtual Heads
最好不要用Virtual Heads.Virtual heads意味著resource is not secure，shared resource會降低resource的工作效率，容易增加出錯的機會，會讓一心二用的人沒有太多時間去review spec、review design.一個dedicated的人，要強過兩個只能投入50%時間和精力的人。我是吃過虧的：7個part time的tester，發現的Bug和干的活，加起來還不如兩個full-time的。參見第73條。73條是針對程序員的，75條是針對Resource Manager的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
