權且不說這些管理行為是否更加浪費工錢，我們應該很容易得到關于“產品開發初期測試人員該做些什么”的一致答復：測試計劃在開發初期能寫挺好，不寫也沒什么問題。測試一定要做的。但把怎樣的產品交給用戶是不確定的。目標就有一個，讓用戶用上再說——無論是對一個已經經營多年的產品，還是一個剛起步的公司……
其實，對測試的理解不是點頭說，測試很重要就夠了； 對測試的理解不是去聲稱，我們有一柜子完整的測試文檔；對測試的理解也不是只關心“做與不做”，而全然不理測試的有效性。
軟件測試該如何理解如何執行，是一個很大的題目。在這里，我更關心的是在項目設計初期，我們該不該忽略測試人員，而測試人員又該做些什么樣的工作。
微軟最新的軟件開發周期（product life cycle）分為產品定義（Product Definition），產品開發（Product Development），產品服務（Product Servicing）三個階段。為了使資源得到最有效的使用，測試人員主要參與產品開發和后期服務這兩個階段。而在產品的定義階段，則會有選擇的要求一些資深測試工程師和測試經理一起參與。他們主要負責：通過驗證產品核心功能或用戶使用場景，確定產品各功能的優先級；參加產品使用場景定義的評審；參加用戶體驗文檔的評審等。
當然每個公司應該定義適合自己的開發模式。但是是否讓測試工程師參與這些工作的主要目標應該是沒有區別的：首先是熟悉客戶需求；再來測試工程師應憑借自身經驗，從測試和維護的角度來判斷被細分的客戶需求中，哪些是合理的，哪些是不合理的，并反饋給項目經理或市場部門，以供他們參考；最后，則要根據這些項目需求以及軟件架構的文檔，給出測試計劃。
上面這番描述是不是看上去并不很復雜，也不重要呢？非要在項目初期做嗎？最終不都是根據需求文檔來寫測試計劃嘛……
這當然是很重要的環節。理由如下：
1． 產品的可測性嚴重影響了后期測試團隊的工作效率以及測試的有效性。越早提出此類相關問題，越可能進入開發工程師設計范圍。同時，該項指標可為項目經理提供一個與“開發難度”并列的“測試難度”——這將會影響到項目負責人對開發周期的設計。
2． 除項目經理外，測試工程師是最需要了解用戶需求以及用戶使用體驗的角色。參與這些由產品經理，項目經理編寫的文檔評審，會讓測試工程師們得到除了列在文檔上的核心需求外更多的信息——我們必須承認，因為人的因素，文檔是不可能涵蓋所有信息——這將會幫助工程師們以更快的速度對產品需求有更深層次的理解。
3． 使得測試經理能夠更早做出“是否需要提前編寫測試工具或搭建測試平臺”的決定。而這是很重要的一點。測試在開發流程中，因其所處位置，很容易因為開發團隊中的突發事件導致周期被壓縮。而自動化測試工具雖然可以節省人力，但相比于手工測試，開發周期較長，見效較晚。通常一個工具從開發到可以用于測試需要一周到數月不等——完全取決于工具的規模。因此，盡快確定“是否需要編寫測試工具”是必要的。它可以幫助測試團隊“搶回”更多的時間用于設計和調試測試工具，從而達到更好的測試效果。甚至可以避免掉因為時間不夠，而拒絕采用自動化工具轉為手工測試的被動局面。
理由其實還可以列出很多。但是，我覺得這幾點應是最為主要的。它們能足夠說明為什么測試人員需要參與產品開發初期的工作以及他們需要做些什么的問題。這里再重復一下，在開發初期測試工程師需要：確定產品的可測性，了解用戶需求，確定需要引入何種測試工具或平臺。
所以，在開發初期做好測試計劃并不是可有可無的；用戶需求不是只要工程師“買單”就可以的；不理會測試團隊而埋頭開發的產品，將會是一場“噩夢”，特別是當產品發布/部署的時候。
但每個公司每個項目組不需要套用一樣的模式。針對不同的需求，我們應該量體裁衣，做不同的剪裁。只是核心不該有變化，目標不該有變化。就如同國內一些公司對CMM的追寵——光有形，沒有神，是實在不可取的。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
