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