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