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