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