軟件測試人員應該在合適時間介入軟件開發(fā)流程之中，已經不是一個新鮮的問題。
許多軟件測試前輩或“軟件人”告訴我們，測試人員介入開發(fā)流程越早越好，這樣就能盡早地發(fā)揮測試人員的功能，減少出現(xiàn)軟件缺陷，降低軟件工程后期的成本。
測試人員介入軟件開發(fā)工程，多早是早，多早為好呢？現(xiàn)成的答案：即從需求開始，從整體設計開始。總之，早早介入就是想讓測試人員直接參與其中，以測試的視角，超前發(fā)現(xiàn)問題，并協(xié)助各干系人，將軟件缺陷解決在萌芽狀態(tài)。如此，可收到“未雨綢繆”“防患于未然”之功效。
目的已明確，節(jié)點瞅準，具體應該如何操作呢？從多年的項目經歷中，我總結出一套行之有效的做法，我把它稱為“談心式”軟件測試法。
不論在任何開發(fā)模式下的項目組，都會有日例會、周例會或月例會，以及各種各樣的例會。有的例會是為了發(fā)布什么消息，有的例會是安排當下的工作，有的例會是討論某個問題（有時是需求問題，有時是開發(fā)問題，有時也可能是測試問題），有的例會是各種評審。我發(fā)現(xiàn)，就某些實際問題而召開的例會，大多數情況下是沒有什么結果的，而這些問題往往是在會后、少數人參與的局部討論中，則尋求到了答案。
這是為什么呢？我從多年的工作經歷中，歸納出這么兩個比較突出的原因：
1、時間問題
例會的時間常常比較短暫，尤其是在快節(jié)奏的開發(fā)模式（如敏捷模式）下的例會。因為整個項目開發(fā)周期短，任務緊，會議時間就十分有限。在例會上，每每是大家的思想還沒有或剛剛撞出一星火花兒時，會議就結束了。
2、與會人員的性格問題
有很多與會人員，并不適應在會議上，面對眾多人員的環(huán)境下暢談自己的觀點，而在會下人比較少的情況下，反而能暢所欲言。由此，這就嚴重阻礙了參會人員的思想交流。還有一些人，對跟自己沒多大關系的問題，經常持一種不置可否的態(tài)度，這也會阻礙相互之間的思想交流。
由此，我摸索出來的“談心式”軟件測試法就有了用武之地。
一、針對開發(fā)設計人員
在項目的每一個迭代階段初始，閱讀或分析需求是測試人員必須做的步驟。只有熟悉了需求，測試人員才能更好地參與到需求評審或設計評審中。在這個階段，我會做兩件事：
1、分析、思考如何制定相關的測試策略和計劃；
2、盡可能地發(fā)現(xiàn)需求中的問題。
這個所謂的需求中的問題有兩種：一種是自己不太明白的點；另一種是需求本身可能存在的問題。
測試人員在做這些工作的時候，開發(fā)設計人員大多數也處在閱讀分析需求階段。這時，我就會帶著自己的問題，對癥下藥，針對不同的性格和喜好的開發(fā)設計人員，采用不同的方式去和他們“談心，以求各個“擊破”。對待喜歡直接談話交流的人，我會選擇面談；對待不喜歡這種交流方式的人，我會選擇用一個文檔或郵件的形式進行溝通。
不管用什么方式，“談心”的目的無非這么幾個：
（1）表露自己對這個需求的看法、對新功能或功能改動的測試思路，針對這些思路，詢問開發(fā)設計人員的看法；
（2）針對已經發(fā)現(xiàn)需求本身存在的問題，首先尋求開發(fā)設計人員的幫助（因為，每個人的經歷、閱歷和能力有差異，對同一個問題的理解是不一樣的）。如果開發(fā)人員也已發(fā)現(xiàn)了這個問題，或是經你提醒，確認這確實是個問題，而彼此眼下，都還沒有較好的解釋或答案時，可以聯(lián)名向需求人員或客戶直接提出，以尋求進一步的確認和答復；
（3）根據測試人員對開發(fā)設計人員工作習慣或“毛病”的了解，可用一種善意的方式，提醒他不要再犯以前曾經出現(xiàn)過的問題（即有可能是粗心或對需求不正確的理解所導致的問題）。
通過這樣的“談心”交流，有時可以拓展自己在制定測試計劃或測試用例時的思路，有時可以解決開發(fā)設計時的需求理解問題，甚至可以避免因開發(fā)人員的人為因素而造成的缺陷發(fā)生。
我一直覺得，測試驅動開發(fā)，是一種測試“驅動”開發(fā)方式。測試人員主動參與設計，誠摯跟設計、開發(fā)人員“談心”，不僅可以幫助他們從測試的角度去看待一些問題，還可以使測試人員本身的思路更加清晰，而且，開發(fā)人員也可以拓展測試人員的思維。更為實在的是大大提升了工作效率，縮短了開發(fā)周期，降低了公司和客戶的成本。共享多贏，何樂而不為？
二、針對需求制作人員
起初，我僅僅把“談心式”軟件測試法應用到了開發(fā)設計人員層面。后來，我發(fā)現(xiàn)這個方法不僅可以應用到與開發(fā)設計人員的溝通上，也可以用在需求制作人員的身上。
需求制作人員在制作需求文檔的時候，經常要從兩個角度出發(fā)，一是從客戶的角度出發(fā)，因為他們要制作出客戶滿意的需求來。二是從軟件開發(fā)角度，他們要思考功能實現(xiàn)的可能和成本。
不管怎么說，需求人員在對客戶需求做二次加工的時候，就會自然而然地注入其個人的觀點或意愿。測試人員在閱讀、分析需求文檔的時候，如果發(fā)現(xiàn)什么疑問，比如說新需求和軟件系統(tǒng)以往的風格有出入，或功能點描述模糊，或其他一些問題，測試人員就可以直接與相關需求人員溝通，尋求問題的確認和幫助。這樣的“談心”，不僅僅是對需求的一定評審，同時也是對自己的測試工作的幫助。最為主要的是與需求制作人員多交流，多溝通，致使對需求更加明確無誤，以免多走彎路，影響工期，增加成本。
三、針對客戶
隨著閱歷的拓寬和實踐經驗的積累，現(xiàn)在的我已不滿足和需求人員、設計開發(fā)人員“談心”，有時也會與客戶直接“談心”。
在敏捷開發(fā)模式或其他快速開發(fā)模式下，項目組成員和客戶的直接交流已成為可能，而且變得越來越頻繁，越來越重要（比如我們現(xiàn)在的項目組）。
“測試從客戶的原始需求開始”，已經是我的一種工作方式。
在遇到需求制作人員也無法給予答案的問題時，我就會直接和客戶“談心”。毋庸諱言，有很多時候，客戶的需求是模棱兩可的，甚或是想當然的。有時他們提供的原始計算方法或運算流程（在很多軟件項目，客戶所用到的計算方法或公式是很專業(yè)的，所以必須由客戶直接提供）是不正確的。在這種狀況下，如果測試人員發(fā)現(xiàn)了這方面先天不足的問題，并及時與客戶“談心”溝通，將之扼殺在萌芽狀態(tài)下，必然會避免項目組寶貴時間的浪費，挽回客戶相當的損失。
“談心”不僅可以發(fā)現(xiàn)問題，解決問題，“談心”還可以讓測試人員更多地了解現(xiàn)在開發(fā)的軟件所涉及的行業(yè)規(guī)范及其他知識。同時，也能為測試人員更好地測試當前軟件、系統(tǒng)或產品提供準確的知識背景；能讓測試人員制定出更符合此軟件的測試用例；能有針對性地發(fā)現(xiàn)更多不符合行業(yè)規(guī)范或要求的軟件缺陷。多年的經驗告訴我，對于一個前沿的測試人，對當前系統(tǒng)所涉及到的行業(yè)、領域知識，在一定程度上，比測試技能（測試方法的應用、測試工具的使用）更為重要。
測試人員直接與客戶“談心”，似乎有“越俎代庖”之嫌，倘若遇到多慮的需求制作人員，有時難免會造成一些誤會，生出一些不必要的嫌隙。在此值得一贊的是，我比較慶幸自己加入了一支奮發(fā)向上、相互尊重、團結和諧的團隊。只要是有利于項目開發(fā)，有利于客戶需求，我們這個團隊，從不過多計較所謂的“規(guī)矩禮數”。
其實，測試人員不僅僅可以和文中所提及的這三類人員“談心”。只要是項目干系人，均可用“談心”的方式去直接或間接地對軟件進行測試。測試人員可以把思路打開，不要僅盯著軟件、系統(tǒng)本身。整個項目組從人員、到流程，都可以成為測試人員的測試對象。套一句時髦概念，此可稱為“大測試”理論。
版權聲明：本文出自 shan0310223 的51Testing軟件測試博客：http://www.51testing.com/?624630
原創(chuàng)作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。