也許我們想要尋找像伯牙與子期的那種高山流水般知音境界還有些遙遠，但是就像文學創作者期待讀者的共鳴那樣，其實測試人員也一樣需要找到類似這樣的“共鳴”。
以我自己的親身經歷爲例，話說前些日子在參與一個項目的測試過程中，我提的一條“bug”被開發人員置爲了“invalid”，投身測試工作近3年，提出的bug無效可是頭一次，於是仔細看了開發人員的評註，他說uc中沒有明確該項需求，於是我興師動衆的拖着開發一起找來PD進行理論，可是萬萬沒有想到PD認可了開發，他認爲目前系統的實現可以滿足他對產品的要求，而當時的我雖然強烈的表達了自己的意見，但是無奈孤掌難鳴，這個無效bug就這麼留在了項目的缺陷庫中。
如果事情就這樣結束那麼可能過些日子我也會忘記，偏偏產品上線不到1個月，就接到系統的改進測試任務，而在諸多修改需求當中，竟然包括了我這條無效的bug內容，私下跟開發溝通，他說有些不好意思當年給我invalid，我說其實bug是否無效並不重要，產品的質量OK纔是關鍵，可是一條PD都認爲不是問題的問題卻變成了問題，那這就變成了一個值得我們去思考的問題。後來跟自在聊起這件事，他問我爲何當時沒有跟其他測試人員溝通來評估這條bug的無效和有效？真是一語驚醒夢中人。
我們常常說團隊，也經常覺得團隊的協作非常不錯，可是仔細想想團隊的意義，其實所謂團隊，並不只是湊在一起的時候纔是團隊，也並不只是共同去做同一件事的時候纔是團隊，而是無論何時何地何種情況，當你需要幫助和支持的時候，就會有這樣的力量存在，團隊的一個重要意義就在於讓我們團隊中每一個人都不做孤獨的測試者，讓測試的迴音更響徹。
如果再遠一點看，其實對一個產品有意見，並不應該只侷限於根據PD的意見，因爲誰都有可能犯錯，當然也會包括測試人員以及PD，產品經理規劃產品，但並不是真正的需求方，如果當時我能想到藉助測試團隊的評估，或者找到真正的需求方進行評估，我相信結果可能會是另外一番。所以，不做孤獨的測試者，爲自己發出的聲音努力尋找回音，這也是我們軟件測試人員的責任和使命。