不做孤獨的測試者

　　不做孤獨的測試者  軟件測試　

   　也許我們想要尋找像伯牙與子期的那種高山流水般知音境界還有些遙遠，但是就像文學創作者期待讀者的共鳴那樣，其實測試人員也一樣需要找到類似這樣的“共鳴”。

　　以我自己的親身經歷為例，話說前些日子在參與一個項目的測試過程中，我提的一條“bug”被開發人員置為了“invalid”，投身測試工作近3年，提出的bug無效可是頭一次，于是仔細看了開發人員的評注，他說uc中沒有明確該項需求，于是我興師動眾的拖著開發一起找來PD進行理論，可是萬萬沒有想到PD認可了開發，他認為目前系統的實現可以滿足他對產品的要求，而當時的我雖然強烈的表達了自己的意見，但是無奈孤掌難鳴，這個無效bug就這么留在了項目的缺陷庫中。

　　如果事情就這樣結束那么可能過些日子我也會忘記，偏偏產品上線不到1個月，就接到系統的改進測試任務，而在諸多修改需求當中，竟然包括了我這條無效的bug內容，私下跟開發溝通，他說有些不好意思當年給我invalid，我說其實bug是否無效并不重要，產品的質量OK才是關鍵，可是一條PD都認為不是問題的問題卻變成了問題，那這就變成了一個值得我們去思考的問題。后來跟自在聊起這件事，他問我為何當時沒有跟其他測試人員溝通來評估這條bug的無效和有效?真是一語驚醒夢中人。

　　我們常常說團隊，也經常覺得團隊的協作非常不錯，可是仔細想想團隊的意義，其實所謂團隊，并不只是湊在一起的時候才是團隊，也并不只是共同去做同一件事的時候才是團隊，而是無論何時何地何種情況，當你需要幫助和支持的時候，就會有這樣的力量存在，團隊的一個重要意義就在于讓我們團隊中每一個人都不做孤獨的測試者，讓測試的回音更響徹。

　　如果再遠一點看，其實對一個產品有意見，并不應該只局限于根據PD的意見，因為誰都有可能犯錯，當然也會包括測試人員以及PD，產品經理規劃產品，但并不是真正的需求方，如果當時我能想到借助測試團隊的評估，或者找到真正的需求方進行評估，我相信結果可能會是另外一番。所以，不做孤獨的測試者，為自己發出的聲音努力尋找回音，這也是我們測試人員的責任和使命。

原文轉自：http://www.anti-gravitydesign.com