關於測試人員何時介入項目小組?
作者：Leveret
應該說這不是一篇文章，這應該屬於是一個討論的話題吧，無論觀點是否正確，希望大家能夠在論壇裏面可以發表自己的見解。尤其在這方面深有感觸的朋友。
提起這個話題的原因是因爲現在一個項目裏面測試人員的介入是到開發後期階段——編碼工作完成之後介入的，我認爲很不合理，所以提出這個問題。從大的方面來考慮的話，現在流程的測試模型有三種： V模型，W模型，H模型。而在這三種模型裏面，無論哪一種模型，測試的介入都是在軟件開發過程的前期介入的。測試工作在這時介入，無論從哪方面考慮，都比我們直到開發過程的後期才介入更有好處。
從成本方面來看：前期介入也許增加了測試人員的成本，但是相對於後期的投入和項目的風險方面，這個成本顯然遠遠小於後期的投入，前期發現的Bug的修改代價比後期的修改代價小多了，如果把成本投入跟介入時間進行比較的話，那麼應該可以得到如下的結論：介入時間越早，成本投入越小，反之越大。在需求調研階段，設計階段，編碼階段，測試階段，產品出貨階段我們都會發現bug，但是處理bug的代價在這幾個階段卻是截然不同的，越往後代價越高。做過項目的人應該都有體會的。
從項目風險來看：如果把編碼階段作爲風水嶺的話，編碼階段之前的工作爲前期工作，編碼階段包括編碼之後的工作爲後期工作。一個問題在開發過程的前期被發現，則可以很大程度上降低項目的風險問題，如果在後期發現一個問題，將不可避免地要面對項目風險問題。很多時候一個項目最後實施的失敗大部分都是在後期發現的問題所致的。當然這不是實施失敗的全部因素。
從其他方面來考慮，都是前期介入比後期介入的情況好的。但是目前所遇到的情況是：等需求調研完成之後測試人員一起進行需求整理，這個時候我覺得很迷糊的一點就是測試人員都沒有參加過需求調研，讓測試人員進行需求調研整理，那不是需要重複一次工作嗎？很多問題測試人員還是要去問進行調研的人的。我覺得效率不是很高。而且經過中間的一道程序很多時候會發生一種曲解需求的現象。
所以測試人員的介入從有些方面來說還是值得一個項目小組的負責人考慮的，不能只是從投入成本來考慮，而且如果要從成本方面考慮的話那麼請考慮整個項目週期的成本。項目風險是項目負責人必須面對的一個問題，而在這個問題上最重要的一個環節就是測試人員來進行把關的，當然有的公司在測試人員之後還有QA來負責質量的。其實關於這個話題要詳細展開的話不是三言兩語就可以說完的。今天只是有感而發。更何況有時候很多公司的規定都是不一樣的。有時候有些流程不一定往日的經驗就是很好的總結，該改新的時候還是需要動手術的。一成不變只能固步自封。墨守成規只能停滯不前。
我希望我們的測試人員不只是在程序員寫好程序之後直接把程序交付我們，並且附上一些應該算不上垃圾的但是並不很完整的文檔就交付成功了，然後我們按照流程說明進行鍵盤輸入，鼠標點擊的動作。我希望我們能更早的介入到項目當中。瞭解更多，做到更多，同時也學到更多。不要當一個廉價的可有可無的角色。那是一種悲哀！！！
其實有時候覺得測試也可以進行分階段，比如需求調研時候瞭解需求，然後等開發人員進行設計時候我們對需求進行剖解，然後提交代碼之後再開始執行測試，中間可以根據需求和設計做很多測試計劃，測試設計策略等方面的事情，主要包括測試計劃，測試用例的設計，產出，並且準備相關測試數據。然後主要的一點就是要對自己進行的項目測試有一個很可觀，比較全面的測試風險等的評估。
以下是幾個同行的跟帖，供大家參考：
呂不爲：程序開發人員進行的是創造代碼的活動，所以，很多初級程序員在寫代碼之前，很明白自己在要做什麼，該怎麼做。但是，當開始寫代碼時，隨着時間的流逝，目的就不再那麼清晰了，也偏離了原先自己的思路，只是顧全自己的部分邏輯，而對整體的業務邏輯不是很清楚。所以，爲了保證程序員的正確航向，測試人員應該在程序員寫代碼前，先寫出測試用例，因爲測試人員關心的是代碼運行的結果是否符合用戶的業務流程以及是否實現了預定的目標。相對來說，測試人員比開發人員更瞭解用戶對軟件的需求。因爲測試是面向業務流程的，而軟件開發是按模塊分工的。所以，我們的做法是，在調研用戶需求的時候，首先寫出測試用例，用來規範程序開發人員的工作範圍，使他們能在正確的道路上前進而不會偏離用戶需求太遠。當用戶需求變化時，測試人員更改用例，開發人員修改代碼，以通過用例爲準。
周舟：提到介入階段，做了這麼多項目我倒以爲這不是該有很嚴格界定的，也確實真的很難界定，因爲不論是需求，設計，永遠不變的是一切都在變，甚至上線應用之後，用戶認爲不滿意，那也還得再變。
所以依據需求分析，概要設計......寫出來的測試用例也很難一成不變。所以只要需求，設計都要變，測試就是有風險的。就算一切都是安裝需求和設計寫出來的，但那些不是用戶最終要求，最終就這樣白忙活了一場。
我以爲測試不論什麼時候介入，瞭解和理解用戶的最終需求是必須和萬無一失並適合中國國情的。
當然若是需求分析和設計能夠很好的瞭解和理解需求，那測試的工作到是可以減輕許多，並風險也會小很多。只要測試“實現的功能是否正確”就行了，而不必費心於“系統是否實現了正確的功能”的測試。
逐漸的行業背景知識竟也成了對測試人員的一種竟聘要求。
Leveret：To:周舟,"逐漸的行業背景知識竟也成了對測試人員的一種競聘要求。"這句話正在被越來越多的企業應用到，不僅僅是測試知識，相關的行業背景知識也是很重要的，需求很難被固定，用例總是在改動，這都是很正常的。思考了很久，也真的很難總結出真正的一個介入的分水嶺。還是活學活用吧，根據自己的實際，不要脫離科學的軌跡。路漫漫其修遠兮，偶們將上下而求索。。。。。。。。。。。。。。