QA测试人员应该如何参与到需求定义流程中？

在需求定义流程中，审查是更适合质量保证（QA）测试人员的角色，而不是定义；但QA测试人员需要学习如何高效执行审查。对于QA测试人员来主产，在于需求定义审查中成功获得支持关键在于，找到对于其它参与人员重要的问题，这就意味着找出需求内容相关的问题，避免投入过多的精力在形式和可测试性上。在我的书中，或相关的讨论坛中，我描述了许多方法来识别需求问题——包括清晰度和可测试性——以及如何使用强大的方法来检测出错误和疏忽的内容。

有些组织让业务分析师负责定义需求和开发测试，从而证明需求已经达到要求。这类双重角色常常会因为测试方法和知识的不足，而导致测试被忽略掉。另外，分析师的测试不可能显示他们需求问题。这类弱点也还会更严重，当开发人员是定义需求和测试的人时。

因此，让具备独立技能的测试人员定义和执行需求测试是有道理的。

让他们，与资深的分析师一同参与到需求发现行动中，如面试的利益相关者，这又是另外一回事了。

如果QA测试在需求和设计流程中参与的早的话，测试人员可以准备更多的测试，且当代码到来时，准备好开始执行他们。早期的参与者帮助确保需求是可测试的，并帮助QA测试人员更好地理解测试什么，然后编写更好的测试。

我已经警告过，仅仅取得接近需求的权利往往会事与愿违。更常见的是，QA测试人员在第一次尝试中并没有准备好做出高效地贡献。其它人也发现他们并有什么帮助，更糟的甚至他们有点碍事，然后把他们排除在需求审查之外。此外，这种不好的经验阻断了第二次返回的机会。主要原因是我称之为的“可测试性陷阱”；具有讽刺性的是，它是来自于QA测试权威的口中，他们说需求的主要问题是缺乏可测试性，进而在很大程度上是由于缺乏清晰度。

这样，当他们参与到需求审查流程时，QA测试人员更倾向于停留在引用他们认为所缺乏的可测试性的需求，然后期望分析师们重写它们，使之更加可测试性。分析师鲜少有时间，也很少有兴趣重做他们的工作；而其它审查者常常认为这类对可测试性的抱怨是无关紧要的。它们也被忽略了，这些参与者不仅没有增加价值，还干扰了有用的评论。