正在閱讀一本很棒的書，《軟件測試經驗與教訓》。幾名國外的軟件測試大師，以大量的測試工作實戰經驗為出發點，總結了深刻而精悍的兩百多條經驗。作者把這些經驗比喻成為波爾多紅酒，鼓勵讀者分散閱讀，帶入自己的工作實際情境，慢慢細品，深入思考。當然還有，不要獨攤波爾多，分享給我的朋友、同事們！

　　《軟件測試經驗與教訓》一書，討論的第一個話題，就是關于測試人員的角色定位。我對這個話題討論的個人理解是：清晰認識自己的角色定位，能夠幫助測試人員明確對自己工作目標的預期。而清楚的認識測試人員的角色定位，對于公司、項目的其他成員來說，可以使他們對于測試工作的“期待”更加恰當，即使是“指責”，也更恰如其分。關于這個話題，以下是對于書中部分經驗的理解或討論。

　　“測試員是前燈”

　　研發經理和開發人員或許正開著一輛吉普，行進在盤山公路上，測試人員的職責就是做好探路的前燈，哪里是懸崖，哪里有險情，前方的路面情況如何……而產品或者項目的關鍵決策，都是基于這些信息的。測試人員的職責是將關于這一切的盡可能詳細的信息告知公司或項目的其他成員。

　　是這樣的角色：全面搜集、整理、報告信息

　　不是這樣的角色：決策者

　　“迅速找出重要的程序問題”

　　測試人員很重要的一條使命就是“迅速找出重要的程序問題”。如何做好這點，書中給出了幾條建議。他們看上去很簡單，很質樸，似乎每個人都知道，但是在實際工作方法中有經常性地提醒自己或者潛意識中就使用這幾條建議么？所謂大道至簡。

　　*首先測試經過變更的部分，修改和更新都意味著新的風險

　　*首先測試核心功能，測試產品所完成的關鍵和常用功能，測試完成產品基本任務的功能

　　*首先測試能力，即每個基本功能是否能用，然后測試可靠性，即深入檢查每個功能在不同條件下的表現

　　*首先測試常見情況，使用常用的數據和使用情境。然后測試特殊情況。

　　*首先測試影響重大的問題

　　*優先測試最需要的部分--對團隊其他成員有重要意義的任何部分的任何問題

　　*測試人員對產品、相關軟硬件、產品的最終用戶越了解，就越可能更快地找出重要問題。

　　“Follow 開發人員”

　　為開發人員提供支持，這也是測試人員的一項重要使命。盡可能建立最短、最快的反饋環路--開發人員交付產品時，馬上進行測試；開發人員修改變更代碼后，馬上測試變更的內容（trunk版本的測試即是此種情況）。在書中，幾位測試大師認為，最理想的情況是，開發人員為了修改測試人員發現的缺陷而忙得團團轉，是開發人員，而不是測試人員，成為項目的瓶頸。當然，老板可能不會認為這個情況理想：）

　　“詢問一切，但不一定外露”

　　多提問。做測試時，遇到的情況千變萬化，不可能不遇到問題。如果真的連續地進行測試工作，而沒有任何問題可提，那么不妨暫停一下手上的測試工作，留給自己一些思考的空間，還是那個論斷，不可能沒有問題。

　　書中提到提問的方法，認為直白的提問就如一劑猛藥，會刺激到別人，所以盡量減低劑量，或與米飯同吃（結合其他溝通形式）。這個的確是個不錯的經驗建議，在面對開發人員、產品需求設計人員、實施人員等同事時，可以盡量采用這樣的提問方式。當然，在面對測試部門同事、主管時，個人覺得，直接提問會更有效率。