軟件測試部實施測試流程混亂的一些想法

　　前段時間我們測試部開周例會的時候，功能組同事提到現在測試流程比較混亂。對于流程這塊我們測試部以及其他領導聊了很多，從測試環境和開發環境的使用，再到開發人員提測項目方式以及項目變更控制流程，最后討論到測試人員與產品人員以及開發人員在需求上的矛盾。這里的矛盾不是對待是什么需求的問題，當然是什么樣需求、要實現什么樣的產品是由產品部同事和市場部同事制確定的，開發部和測試部只有執行和建議的份。產品部是老大，一個IT產品公司中可以沒有測試部，但是不能沒有產品部，產品的創新、以及市場競爭力主要依靠產品部門，這里有些扯的遠啦。當然測試部更重要，O(∩_∩)O哈哈~

　　開發人員也有獨立的開發環境，但是他們卻很少在他們的開發環境上使用，他們在自己的本地電腦上開發、修改bug程序。有人會問那你們的開發是怎么和其他同事負責的模塊進行聯調的呢?他們都在自己的電腦上部署所有站點的程序，配置這塊，數據庫路徑連接的是測試環境的地址。有些開發更懶，甚至都沒有和其他模塊或者站點的程序進行調試(他們大都是這樣的)，而是直接提交給測試這邊的配置管理員部署到測試環境。也許開發人員很有自信心，對自己的編碼水平絲毫不存在懷疑，其實也值得我們尊重呀 哈哈。說句實話，好像測試就是開發人員的專職保姆，活不少干，整天忙得焦頭爛額，導致自己的測試流程被完全打亂，出不了成績，被測試的模塊一次次回歸。好像他們早已經形成了這個大少爺習慣，冒煙測試的工作應該完全由開發人員自己來進行的，現在卻成了測試人員來做。這中間我們也意識到無形的矛盾存在，也找過開發的負責人進行協商，我們測試可以出一個配置管理員向他們的開發服務器提交他們的冒煙測試程序，然后他們對自己的程序進行初步驗證后再提交到測試環境，再次進行深入的測試。對于該提議，也得到開發部門同事的一致認同，但中間不知道什么原因沒有這么做，主要還是領導的執行力度不夠，以及部門間缺少這種協作控制的維護體系。

　　不知道其他公司是不是也有這樣的矛盾。

　　在需求這塊，除了大項目以外，很多時候測試人員在開發人員沒有提測以前，根本不知道還有這個功能或者變更需求，直到開發人員向測試部的配置人員提交測試版本我們這邊才知道還有這個測試。至于要實現的功能，開發人員說產品部沒有給什么文檔，只有口頭一句話或者QQ上一句話需求等。這時候測試部還要去找產品部相關人員調研需求，向他們索要功能需求文檔(他們是沒有寫的，除了大一些的開發項目)。如果不找產品部核對需求，只憑開發人員的一句話，那就只等著翻工的份啦，因為測試部的最終客戶是產品部。對于一個IT公司部門協作之間也存在甲方、乙方的關系，盡管沒有報酬環節，但這種關系卻的的確確存在的。這時候開發和測試是坐在一條船上的，代碼的質量以及開發的進度，會影響測試的效率和進度。在同一個公司中我認為的甲方包括公司老板、CTO、公司的某一個部門(產品部、市場部);乙方包括開發部、測試部。對于領導以及一些人員的一句話需求，開發人員如果定位的有偏差，不僅開發人員要翻工，而且測試人員工作不到位，也必然翻工，對于需求的定位很重要。另外產品部提交不出測試需求文檔，測試人員也就沒有可以信任的東西寫case啦。

　　總體來說，這些問題的存在在無形之中阻礙了開發、測試的進度，特別是因為需求發起、需求變更引起的問題，給測試人員造成不少的困擾。部門間沒有協作控制規范體系來相互束縛，提交需求人員舍不得編寫需求文檔，久而久之就會產生一種依賴心里，在需求需要變更時，隨時一句話就可以變更。測試工作中不僅僅要建立完善的測試體系，在適當的時候也要拉上開發、產品一起來規范這個體系，由于是部門間協作，一定要強硬執行，要讓他們知道測試是版本走出家門的最后一道崗。

原文轉自：http://www.cnblogs.com/zhuque/archive/2013/03/15/2961953.html