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