關于測試人員何時介入項目小組?

　　應該說這不是一篇文章，這應該屬于是一個討論的話題吧，無論觀點是否正確，希望大家能夠在論壇里面可以發表自己的見解。尤其在這方面深有感觸的朋友。

　　提起這個話題的原因是因為現在一個項目里面測試人員的介入是到開發后期階段——編碼工作完成之后介入的，我認為很不合理，所以提出這個問題。從大的方面來考慮的話，現在流程的測試模型有三種： V模型，W模型，H模型。而在這三種模型里面，無論哪一種模型，測試的介入都是在軟件開發過程的前期介入的。測試工作在這時介入，無論從哪方面考慮，都比我們直到開發過程的后期才介入更有好處。

　　從成本方面來看：前期介入也許增加了測試人員的成本，但是相對于后期的投入和項目的風險方面，這個成本顯然遠遠小于后期的投入，前期發現的Bug的修改代價比后期的修改代價小多了，如果把成本投入跟介入時間進行比較的話，那么應該可以得到如下的結論：介入時間越早，成本投入越小，反之越大。在需求調研階段，設計階段，編碼階段，測試階段，產品出貨階段我們都會發現bug，但是處理bug的代價在這幾個階段卻是截然不同的，越往后代價越高。做過項目的人應該都有體會的。

　　從項目風險來看：如果把編碼階段作為風水嶺的話，編碼階段之前的工作為前期工作，編碼階段包括編碼之后的工作為后期工作。一個問題在開發過程的前期被發現，則可以很大程度上降低項目的風險問題，如果在后期發現一個問題，將不可避免地要面對項目風險問題。很多時候一個項目最后實施的失敗大部分都是在后期發現的問題所致的。當然這不是實施失敗的全部因素。

　　從其他方面來考慮，都是前期介入比后期介入的情況好的。但是目前所遇到的情況是：等需求調研完成之后測試人員一起進行需求整理，這個時候我覺得很迷糊的一點就是測試人員都沒有參加過需求調研，讓測試人員進行需求調研整理，那不是需要重復一次工作嗎?很多問題測試人員還是要去問進行調研的人的。我覺得效率不是很高。而且經過中間的一道程序很多時候會發生一種曲解需求的現象。

　　所以測試人員的介入從有些方面來說還是值得一個項目小組的負責人考慮的，不能只是從投入成本來考慮，而且如果要從成本方面考慮的話那么請考慮整個項目周期的成本。項目風險是項目負責人必須面對的一個問題，而在這個問題上最重要的一個環節就是測試人員來進行把關的，當然有的公司在測試人員之后還有QA來負責質量的。其實關于這個話題要詳細展開的話不是三言兩語就可以說完的。今天只是有感而發。更何況有時候很多公司的規定都是不一樣的。有時候有些流程不一定往日的經驗就是很好的總結，該改新的時候還是需要動手術的。一成不變只能固步自封。墨守成規只能停滯不前。

　　我希望我們的測試人員不只是在程序員寫好程序之后直接把程序交付我們，并且附上一些應該算不上垃圾的但是并不很完整的文檔就交付成功了，然后我們按照流程說明進行鍵盤輸入，鼠標點擊的動作。我希望我們能更早的介入到項目當中。了解更多，做到更多，同時也學到更多。不要當一個廉價的可有可無的角色。那是一種悲哀!!!

　　其實有時候覺得測試也可以進行分階段，比如需求調研時候了解需求，然后等開發人員進行設計時候我們對需求進行剖解，然后提交代碼之后再開始執行測試，中間可以根據需求和設計做很多測試計劃，測試設計策略等方面的事情，主要包括測試計劃，測試用例的設計，產出，并且準備相關測試數據。然后主要的一點就是要對自己進行的項目測試有一個很可觀，比較全面的測試風險等的評估。

　　以下是幾個同行的跟帖，供大家參考：

　　呂不為：程序開發人員進行的是創造代碼的活動，所以，很多初級程序員在寫代碼之前，很明白自己在要做什么，該怎么做。但是，當開始寫代碼時，隨著時間的流逝，目的就不再那么清晰了，也偏離了原先自己的思路，只是顧全自己的部分邏輯，而對整體的業務邏輯不是很清楚。所以，為了保證程序員的正確航向，測試人員應該在程序員寫代碼前，先寫出測試用例，因為測試人員關心的是代碼運行的結果是否符合用戶的業務流程以及是否實現了預定的目標。相對來說，測試人員比開發人員更了解用戶對軟件的需求。因為測試是面向業務流程的，而軟件開發是按模塊分工的。所以，我們的做法是，在調研用戶需求的時候，首先寫出測試用例，用來規范程序開發人員的工作范圍，使他們能在正確的道路上前進而不會偏離用戶需求太遠。當用戶需求變化時，測試人員更改用例，開發人員修改代碼，以通過用例為準。

原文轉自：http://www.uml.org.cn/Test/200503104.htm