從軟件測試看挨踢項目求生法則(2)

　　1)例1：我無法開展測試

　　某測試人員的工作一直不能開展，我很郁悶，他解釋：這個“增加”功能一直沒有做出來，雖然“修改”和“刪除”功能做出來了，但因為沒有“增加”功能可用，所以……

　　聽了后我有點惱火：為什么你不能到數據庫中添加一條記錄，然后你不就可以去測“修改”和“刪除”功能羅!

　　他不好意思地說：我沒玩過數據庫……

　　2)例2：需要程序員幫忙的測試

　　我有事找某程序員，但他不在座位不知道干嘛去了，后來我了解到原來他去幫助美女測試了，他幫忙設置測試環境，包括：安裝服務器的操作系統、安裝數據庫、安裝程序、設好配置文件等等。

　　我覺得他做得挺好的，大家就應該互相幫忙嘛。但下一個版本，他又重復做類似的事情。

　　我問：上次你沒有教會她嗎?這次讓她自己搞定就行了。

　　他說：她好像不太愿意學……

　　類似的事情我遇到的不少，由于測試人員掌握得知識太少了，以致很多工作都需要別人準備好安排好他才能做。而更讓我氣憤的是，有些測試學習的欲望很弱，而且對測試工作的認識很膚淺。一些測試認為：測試工作就是軟件做好能見到界面后，我在界面上點鼠標和敲鍵盤就可以了，高級一點的測試工作就是能用LoadRunner之類的工具來做性能測試。

　　其實大部分測試都是追求進步的，“學習欲望弱”很可能是沒有認識到自己需要學什么，沒有打牌自己固有的思維框框，沒有能發揮自己的強大潛力。要改善測試工作，作為測試人員的你首先應該自我檢討，看看有什么可以改善的地方。

　　“圖1：測試人員應該具備的技能” 中列出的要求，你必須至少要達到“基本技能要求”和“進階技能要求”這兩個層次。只要你有心去學，只需要3-6個月你就可以基本滿足這兩個層次的要求。而 “高級技能要求”難度有點大，一般沒有3年以上的相關工作經驗是很難滿足的，你可以考慮將這方面列為你的發展方向。只要你達到“基本技能要求”和“進階技能要求”，你的能量將會成幾倍爆發!

　　法則2：拒絕二手需求

　　“二手需求”就是項目經理獲取需求后，將需求傳達給測試，這樣就變成二手需求了。

　　但這只是理想境界，通常是項目經理將需求傳遞給開發，然后開發告訴測試你怎樣測就可以了。所以實際情況是，我們測試得到的是三手甚至三手以上的需求!

　　讓測試獲取一手需求的做法：

　　1)測試人員參與到需求調研中來，甚至讓測試成為需求負責人;

　　2)需求文檔不要等全部寫好才給測試看，每寫一部分就要與測試溝通。

　　法則3：測試至少要成為第二熟悉需求的人

　　項目中最熟悉需求的人通常就是項目經理，或者是需求分析師(產品經理)。

　　測試至少要成為第二個最熟悉需求的人，并且要爭取成為第一位，將項目經理“干掉”!

　　法則4：拒絕半個人

　　不少項目后期才安排測試人員進入，而且測試人員還需要同時負責另外一個項目的測試，你最多只能得到“半個測試工程師”。

　　測試需要從項目的一開始就介入，并且每個項目至少要配備一名“完整”的測試。

　　法則5：是不是缺陷，測試說了算!

　　有一個缺陷，測試認為是缺陷，但開發認為不是，并且用一堆測試聽不懂的話來解釋這不是缺陷。

　　這種狀況很常見，你們會用哪種方法裁決?

　　A)測試因為聽不懂，所以最終被開發“說服”，這個不是缺陷。

　　B)交項目經理裁決，項目經理通常是開發出身的，所以最后就會變成這個不是缺陷。

　　C)交客戶裁決。

　　D)少數服從多數。測試一定是少數，所以結果你懂的……

　　我以前的做法就是交項目經理裁決，后來覺得可以做得更好，我將做法改成：其他人可以提建議，但是不是缺陷的決定權在于測試!

　　我這樣做是因為：

　　1)測試的角度更接近客戶，他的判斷更靠譜。

　　2)測試因為有這樣的一個責任和權力，他工作會更投入，會更加努力提升水平。

　　3)“是不是缺陷”和“能不能按時發布”，兩個問題要分開處理。不能因為要按時發布而掩蓋質量問題，有質量問題也可以按時發布的嘛，但如果缺陷被掩蓋掉了，就相當于埋下定時炸彈。

　　法則6：測試獲取開發代碼

　　請先看一個案例。

　　案例：需要界面規格說明的測試

　　某測試提出這樣的要求，希望開發人員能提供界面的詳細規格說明，以便可以開始準備測試用例，為正式測試做好準備。

　　開發人員反對這樣的要求，因為這事情太浪費時間了，而且界面經常會變和調整的，這個文檔我豈不是要天天改!

　　這是事情解決起來很簡單，每一位測試的電腦上都裝上開發工具，每天測試就好像開發一樣去獲取代碼，測試每天干這些事情：

　　1)編譯代碼，檢查是否編譯通過。如果發現編譯不通過，項目小組發達了，今天有人請吃飯，請客的人就是讓代碼編譯不通過的代碼提交者。

　　2)如果編譯通過，那就進行“冒煙測試”。冒煙測試干的事情就是將主干業務流程走一遍，將所有能點的按鈕和菜單走一遍，看看會不會出錯。如果出錯，那恭喜你，又有人請吃飯了!

　　3)對照需求檢查程序是否在正確的軌道上，及時提出易用性方面的改進建議。

　　這樣干其實就已經做到測試前置了，這樣做就不會出現直到正式測試階段才能見到軟件廬山真面目的情況，問題不會在最后才爆發出來，前期已經發現并避免了。

　　要做這個事情，測試并不需要懂開發，會用開發工具，會編譯軟件就可以了。有條件的時候，測試還可以去學習代碼，甚至逐步開始寫一些測試代碼呢!

　　法則7：人人都是測試

　　一般軟件公司開發與測試的人數比例，大概是 4-8:1，當然也會有比較悲劇的公司是 20+:1 的。

原文轉自：http://www.cnblogs.com/umlonline/p/3485631.html