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