很多企业在（zài）进行（háng）新产品开发时，产品（pǐn）需（xū）求的确定，仿佛只是产品经（jīng）理和市场人员的事，他们（men）确（què）定产品（pǐn）该做成什么样子，写成产品规格说（shuō）明书或者需（xū）求文（wén）档，然后给研（yán）发的系统（tǒng）工程师（shī）评审，确定在技术上是（shì）可行的（de），就（jiù）可以启（qǐ）动一个项目，投入资源进行开发（fā）了。然而在（zài）这个过程（chéng）中，很（hěn）容易出现需求描述不清晰、不（bú）详细，导致开发人员开发出不符（fú）合客户真正需要的产品。为了解决这个问（wèn）题，企业会要求产品经理和客户进（jìn）行前期的需求确认（rèn），要求他（tā）们将需求文档（dàng）写得更加详细，要求开发人员参（cān）与评审，确保客户、产品（pǐn）、研发三方（fāng）对需（xū）求达成（chéng）一致的（de）理（lǐ）解。
在这个过程中，测试很少参与。有几方（fāng）面原因：一是测（cè）试不负责产品的实现（xiàn）过程，因此在可实（shí）现性上没（méi）有发言机（jī）会（huì）；二是企（qǐ）业招聘测试工程师的时候只强（qiáng）调用例设计能力，不要求他们具有对需（xū）求的（de）评（píng）审技能。企业普遍认（rèn）为需求（qiú）阶段没（méi）有测试啥事儿，但结果（guǒ）往往是产（chǎn）品（pǐn）开发出（chū）来了，测试才发现有需（xū）求上的问（wèn）题，才发现有些功能需要另外开发（fā）一些辅助接（jiē）口才（cái）能对其验证，妨（fáng）碍（ài）了项目按期完成。少数正规化做得比较好（hǎo）的企业，会（huì）让测试人（rén）员参（cān）与到（dào）需求（qiú）评审中（zhōng）来（lái），就可（kě）测试性需求提出意见。可即（jí）使我们这（zhè）样（yàng）去做了，效果却不见得好，为什么？
在确定产品需求这件（jiàn）事上，产品经（jīng）理（lǐ）、系统工（gōng）程师和测（cè）试工程师（shī）的着眼（yǎn）点是不一样的：产品经理会着力于将产品的卖点描（miáo）述清楚，至于产品的这些卖点（diǎn）在技（jì）术上是不是可行（háng）的，一般就（jiù）交给研发系统工程师（shī）来确定了；系（xì）统工程师会更多（duō）地考虑（lǜ）如（rú）何将产（chǎn）品（pǐn）做出来，而这些（xiē）考虑，一（yī）般（bān）会体现在设（shè）计文档中，对于需求文档，他们只会提出和设计相矛（máo）盾（dùn）的地方；测试工程师（shī）按（àn）照流程（chéng）要求，会检查需求描述中是否存在前后矛盾的地方，会（huì）考虑自己怎（zěn）么去测试这些需求，顺带提出新的可测（cè）试性需求（qiú）。
在需（xū）求评审的这（zhè）个过程中，你（nǐ）会发（fā）现（xiàn），并（bìng）没有人对需（xū）求文档的完成标准负责：是不（bú）是将产品方方面面（miàn）都描述清楚，使得这些需求（qiú）在逻辑上顺理成章了？
这样的需求（qiú）会使开发在实现（xiàn）产品、测（cè）试在验（yàn）证产品时出（chū）现很多需要脑补（bǔ）的环节（jiē）。这些脑补的内（nèi）容是没有经过（guò）评审的，很容易出现问题。也有人问过（guò）这个问题，“只做黑盒（hé）测试可以（yǐ）保证（zhèng）产品（pǐn）测试充分吗？”针对这个问（wèn）题，有一个看似完美的假（jiǎ）设（shè）--只要需（xū）求写得很充分、很详细，没（méi）有未描述（shù）的空（kōng）白地（dì）带，测试只（zhī）要按（àn）照需（xū）求说（shuō）明一一验（yàn）证（zhèng）到位了（le），就不会有漏测。然而事实却是（shì），哪怕（pà）这个假设成立，在实（shí）际中也是（shì）不可行的，因为这对产品经（jīng）理要求太高了，极少有（yǒu）产品经（jīng）理能够写出（chū）如（rú）前所述般“完美”的需求（qiú）说明。
为（wéi）了解决需求不够（gòu）详细这个问题，企业会将（jiāng）需求分阶段（duàn）表现，先用市场需求（MRD）描（miáo）述产品的卖（mài）点和市场（chǎng）空间之类（lèi）的信息，信息传（chuán）到产品（pǐn）部的时候用产品需求（qiú）（PRD）描述更接（jiē）近研发（fā）理（lǐ）解的产（chǎn）品各个功能和性能需求点，最后研发再（zài）用产品详（xiáng）细规（guī）格（gé）（SyRS）描述各个功（gōng）能点需要满足的要求，一步一步地细化，最终让需求变得足够（gòu）详细（xì）。这样做是可以达到目的的，只（zhī）要研发能够投入资（zī）源去做产品详细规格书（shū），一般（bān）能满足“需求足够详细（xì）”这个要求（qiú）。但你会发现，这中间还是没（méi）有测试啥事情。
实际上，测试工程师是整个团队中最擅长将需求变得足够详细的人，因为他的工作需要将产品实际（jì）运（yùn）行的每一个细节都表述清楚。执行测试的时候，不将每个（gè）细节都检查一遍是不可能的。但是，我们招聘测（cè）试（shì）工程师（shī）的（de）时候，是（shì）不要求他具（jù）有写需求的能力的，在实际工（gōng）作中，也不要求他们写（xiě）需求，因此，他们也很（hěn）乐意将需求文档这一最（zuì）决定他（tā）们工作质量（liàng）的交付物的（de）完成情况交给（gěi）别人去负责。
在敏（mǐn）捷项目中（zhōng），每次客户更新（xīn）需求的时候，测试都得参（cān）与，第一（yī）时（shí）间构思（sī）这（zhè）些（xiē）需求该怎（zěn）么验证，虽然（rán）没有（yǒu）形成什么文档，但完善需求这个过（guò）程是切（qiē）切实实地在（zài）测试工程（chéng）师的脑海中跑了（le）一遍的（de）。因此，测试是有能力做（zuò）这（zhè）个事情的，只是需要锻炼（liàn）而已（yǐ）。
在项目结束之前，需要（yào）完善（shàn）用户文档，并对（duì）用户文档（dàng）进行验证。前者是文档工程师（shī）的工作（zuò），后者则是（shì）由测试工程师负责（zé）的。在人员（yuán）配备没有这么“豪华”的企业，没有文（wén）档工程师，开发人员会被指（zhǐ）定去写用户手册，有些企业也会让（ràng）测试工程师去（qù）写。相较而言，测（cè）试（shì）工（gōng）程师（shī）去（qù）做这（zhè）件（jiàn）事情会（huì）更合理，因为他们是从客户的角（jiǎo）度出（chū）发（fā）来对产品进行（háng）验（yàn）证的（de），测试工程师更能够写出符（fú）合（hé）客户思维（wéi）习惯和使（shǐ）用习惯（guàn）的使用手册。
当测试工程师能够承担起撰（zhuàn）写用（yòng）户手册这个任务之后（hòu），就可（kě）以承担需（xū）求文档完善的工作了。需求文档和用户手册（cè）的要（yào）求不一样，卖（mài）点、特性等这些关键信息的描述不能出现（xiàn）任何偏差，这些（xiē）可以让产品经理（lǐ）按照原（yuán）有要求出需求（qiú）文档，测试在此基础上进行完善，使需求文档满足详细、完（wán）备、逻辑（jí）顺畅的要求（qiú）。
这种（zhǒng）做法在需求阶段增加了（le）工作量，并且同一（yī）个交付物由不（bú）同角色的人员（yuán）合作完成，可能（néng）会带来职责不清的问题，这是（shì）缺（quē）点（diǎn）；但测试人员参与完善需求的工作，保证了（le）他（tā）们在（zài）需求阶段（duàn）就充分（fèn）投入去了（le）解产品应该做成什么样子，为后续的用（yòng）例设计打（dǎ）下良好的基础，同时（shí），可（kě）测试性（xìng）需求这些内容会自然而（ér）然地体现（xiàn）在需（xū）求里面（miàn），减少后续需求更改的次数。这些好处是能够（gòu）弥补前面所提到（dào）的缺（quē）点所带来的（de）代价的。
