测试人员如何参与需求定义过程？

How should QA testers participate in the requirements definition process?
质量测试人员如何参与需求定义过程？

说明：在本文中为了尊重作者的原文，所以将 QA testers 翻译为测试人员。尽管这个翻译看起来比较别扭。
有一些组织/公司会将测试者归结到SQA部门，但是在大多数组织中会严格区分SQA、SQC和Tester的角色。本质上，SQA、SQC和Tester所从事的工作内容是不同的。（译者注）

Reviewing – rather than defining – is the appropriate role for quality assurance (QA) testers in the requirements definition process, but QA testers need to learn to perform reviews productively. For QA testers, the key to winning support for their involvement in requirements definition reviews is to find problems that are important to other participants, which means finding concerns with the requirements’ content and avoiding too much focus on form and testability. In my book and related seminars, I describe many ways to identify problems with requirements – including clarity and testability – as well as how to use powerful methods to detect wrong and overlooked content.
评审–而不是定义，是测试人员在需求定义过程中适合的角色，但测试人员需要学习进行高效的评审技术。对于测试人员，他们在参与需求定义评审时要赢得其他人支持的关键是要找到问题，找到那些对于其他参与者来说是重要的问题，这意味着应该关注需求的内容和避免过多地关注形式和可测试性。在我的书中和相关的研讨会上，我描述了许多方法来识别需求的问题——包括清晰度和可测性——以及如何使用强大的方法来检测错误和被忽视的内容。

Some organizations make business analysts responsible for defining requirements and for developing tests to demonstrate that requirements have been met. Such a dual role often results in tests being neglected, by means of both inadequate attention and testing knowledge. Moreover, analysts’ tests are unlikely to reveal problems with their requirements. Such weaknesses are exacerbated when developers are the ones defining the requirements and tests.
一些组织让软件业务分析师负责定义需求和开发测试，以证明需求已经被满足。这样的双重角色，因为存在测试知识不足和对测试的关注不足这两个弱点，往往导致测试被忽视。此外，软件业务分析师的测试是不可能揭示他们的需求中存在的问题。当开发人员在定义需求和测试的时候，这种缺点会被加剧。

Therefore, there is a rationale for having independent skilled testers define and execute the requirements’ tests.
因此，便有了要求掌握测试技术的人员独立定义和执行需求测试的理由。

Having them participate along with skilled analysts in requirements discovery activities, such as interviewing stakeholders, is a different point, though. Not only does it double the discovery costs and divert scarce QA testers from what usually is too little time for testing, but it’s unlikely to add appreciable value. There’s no reason to assume those focused on QA testing would have business analysis skills that dedicated business analysts lack.
让他们与软件需求分析师一起参与需求发现活动，例如采访利益相关者，这里存在一个不同的观点。它不仅是双重的发现成本和转移稀缺的质量保证测试人员通常是太少的时间进行测试，但它不太可能增加明显的价值。没有理由假设那些专注于测试的测试者有软件分析师缺乏的业务分析技能。

If QA testing is involved early in the requirements and designs process, testers are able to prepare more tests and are ready to begin executing them when the code arrives. Early participation helps ensure requirements are testable and helps the QA testers better understand what to test, resulting in them writing better tests.
如果在需求和设计过程中涉及早期的质量保证测试，测试人员能够编写更多的测试，并准备在代码提交时开始执行它们。尽早的参与有助于确保需求是可测试的，帮助测试人员更好地理解测试，从而更好地测试。

I’ve cautioned that merely gaining access to requirements reviews often backfires. Too frequently, the QA testers are not prepared to contribute productively in the first attempt. Others find them either to be no help, or worse, impediments, and exclude them from requirements reviews thereafter. Moreover, such bad experiences preclude second chances of ever returning. A main cause is what I call the “testability trap,” which ironically results from QA testing pundits saying the main issue with requirements is lack of testability, which in turn is largely due to lack of clarity.
我已经警告说，仅仅获得需求评审常常是事与愿违。太频繁，测试人员不准备在第一次尝试时做出有效的贡献。其他人发现测试人员要么是没有任何帮助，或者使情况更糟糕，产生障碍，此后要求从需求评审中排除他们。此外，这种不好的经验，排除了再次返回的机会。一个主要原因是我所说过的“可测性陷阱”，具有讽刺意义的是测试专家说的主要问题是缺乏可测性，这反过来又很大程度上是由于缺乏明确性。

Thus, when they are involved in the requirements review process, QA testers tend to dwell on citing requirements they consider to lack testability, and expect analysts to rewrite them so they are testable. Analysts seldom have time or inclination to redo their work, and other review participants often consider such yammering about testability to be trivial nitpicking. It’s ignored, and its perpetrators are perceived as not only not adding value, but also interfering with the usefulness of the review.
因此，当他们参与到需求评审过程中，测试人员倾向于考虑他们认为缺乏可测性的要求，并期望软件业务分析师重写这些需求，以便它们是可测试的。而软件业务分析师们很少有时间或意愿重做他们的工作，和其他评审参与者经常考虑这样的唠叨琐碎的挑剔的可测试性。这是被忽视的，它的肇事者被认为不仅没有增加价值，但也干扰了评审的有用性。