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