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