很多企業(yè)在進行新產(chǎn)品開發(fā)時，產(chǎn)品需求的確定，仿佛只是產(chǎn)品經(jīng)理和市場人員的事，他們確定產(chǎn)品該做成什么樣子，寫成產(chǎn)品規(guī)格說明書或者需求文檔，然后給研發(fā)的系統(tǒng)工程師評審，確定在技術(shù)上是可行的，就可以啟動一個項目，投入資源進行開發(fā)了。然而在這個過程中，很容易出現(xiàn)需求描述不清晰、不詳細，導(dǎo)致開發(fā)人員開發(fā)出不符合客戶真正需要的產(chǎn)品。為了解決這個問題，企業(yè)會要求產(chǎn)品經(jīng)理和客戶進行前期的需求確認，要求他們將需求文檔寫得更加詳細，要求開發(fā)人員參與評審，確?？蛻簟a(chǎn)品、研發(fā)三方對需求達成一致的理解。
在這個過程中，測試很少參與。有幾方面原因：一是測試不負責產(chǎn)品的實現(xiàn)過程，因此在可實現(xiàn)性上沒有發(fā)言機會；二是企業(yè)招聘測試工程師的時候只強調(diào)用例設(shè)計能力，不要求他們具有對需求的評審技能。企業(yè)普遍認為需求階段沒有測試啥事兒，但結(jié)果往往是產(chǎn)品開發(fā)出來了，測試才發(fā)現(xiàn)有需求上的問題，才發(fā)現(xiàn)有些功能需要另外開發(fā)一些輔助接口才能對其驗證，妨礙了項目按期完成。少數(shù)正規(guī)化做得比較好的企業(yè)，會讓測試人員參與到需求評審中來，就可測試性需求提出意見。可即使我們這樣去做了，效果卻不見得好，為什么？
在確定產(chǎn)品需求這件事上，產(chǎn)品經(jīng)理、系統(tǒng)工程師和測試工程師的著眼點是不一樣的：產(chǎn)品經(jīng)理會著力于將產(chǎn)品的賣點描述清楚，至于產(chǎn)品的這些賣點在技術(shù)上是不是可行的，一般就交給研發(fā)系統(tǒng)工程師來確定了；系統(tǒng)工程師會更多地考慮如何將產(chǎn)品做出來，而這些考慮，一般會體現(xiàn)在設(shè)計文檔中，對于需求文檔，他們只會提出和設(shè)計相矛盾的地方；測試工程師按照流程要求，會檢查需求描述中是否存在前后矛盾的地方，會考慮自己怎么去測試這些需求，順帶提出新的可測試性需求。
在需求評審的這個過程中，你會發(fā)現(xiàn)，并沒有人對需求文檔的完成標準負責：是不是將產(chǎn)品方方面面都描述清楚，使得這些需求在邏輯上順理成章了？
這樣的需求會使開發(fā)在實現(xiàn)產(chǎn)品、測試在驗證產(chǎn)品時出現(xiàn)很多需要腦補的環(huán)節(jié)。這些腦補的內(nèi)容是沒有經(jīng)過評審的，很容易出現(xiàn)問題。也有人問過這個問題，“只做黑盒測試可以保證產(chǎn)品測試充分嗎？”針對這個問題，有一個看似完美的假設(shè)--只要需求寫得很充分、很詳細，沒有未描述的空白地帶，測試只要按照需求說明一一驗證到位了，就不會有漏測。然而事實卻是，哪怕這個假設(shè)成立，在實際中也是不可行的，因為這對產(chǎn)品經(jīng)理要求太高了，極少有產(chǎn)品經(jīng)理能夠?qū)懗鋈缜八霭恪巴昝馈钡男枨笳f明。
為了解決需求不夠詳細這個問題，企業(yè)會將需求分階段表現(xiàn)，先用市場需求（MRD）描述產(chǎn)品的賣點和市場空間之類的信息，信息傳到產(chǎn)品部的時候用產(chǎn)品需求（PRD）描述更接近研發(fā)理解的產(chǎn)品各個功能和性能需求點，最后研發(fā)再用產(chǎn)品詳細規(guī)格（SyRS）描述各個功能點需要滿足的要求，一步一步地細化，最終讓需求變得足夠詳細。這樣做是可以達到目的的，只要研發(fā)能夠投入資源去做產(chǎn)品詳細規(guī)格書，一般能滿足“需求足夠詳細”這個要求。但你會發(fā)現(xiàn)，這中間還是沒有測試啥事情。
實際上，測試工程師是整個團隊中最擅長將需求變得足夠詳細的人，因為他的工作需要將產(chǎn)品實際運行的每一個細節(jié)都表述清楚。執(zhí)行測試的時候，不將每個細節(jié)都檢查一遍是不可能的。但是，我們招聘測試工程師的時候，是不要求他具有寫需求的能力的，在實際工作中，也不要求他們寫需求，因此，他們也很樂意將需求文檔這一最決定他們工作質(zhì)量的交付物的完成情況交給別人去負責。
在敏捷項目中，每次客戶更新需求的時候，測試都得參與，第一時間構(gòu)思這些需求該怎么驗證，雖然沒有形成什么文檔，但完善需求這個過程是切切實實地在測試工程師的腦海中跑了一遍的。因此，測試是有能力做這個事情的，只是需要鍛煉而已。
在項目結(jié)束之前，需要完善用戶文檔，并對用戶文檔進行驗證。前者是文檔工程師的工作，后者則是由測試工程師負責的。在人員配備沒有這么“豪華”的企業(yè)，沒有文檔工程師，開發(fā)人員會被指定去寫用戶手冊，有些企業(yè)也會讓測試工程師去寫。相較而言，測試工程師去做這件事情會更合理，因為他們是從客戶的角度出發(fā)來對產(chǎn)品進行驗證的，測試工程師更能夠?qū)懗龇峡蛻羲季S習(xí)慣和使用習(xí)慣的使用手冊。
當測試工程師能夠承擔起撰寫用戶手冊這個任務(wù)之后，就可以承擔需求文檔完善的工作了。需求文檔和用戶手冊的要求不一樣，賣點、特性等這些關(guān)鍵信息的描述不能出現(xiàn)任何偏差，這些可以讓產(chǎn)品經(jīng)理按照原有要求出需求文檔，測試在此基礎(chǔ)上進行完善，使需求文檔滿足詳細、完備、邏輯順暢的要求。
這種做法在需求階段增加了工作量，并且同一個交付物由不同角色的人員合作完成，可能會帶來職責不清的問題，這是缺點；但測試人員參與完善需求的工作，保證了他們在需求階段就充分投入去了解產(chǎn)品應(yīng)該做成什么樣子，為后續(xù)的用例設(shè)計打下良好的基礎(chǔ)，同時，可測試性需求這些內(nèi)容會自然而然地體現(xiàn)在需求里面，減少后續(xù)需求更改的次數(shù)。這些好處是能夠彌補前面所提到的缺點所帶來的代價的。
