测试人员工作的一部分是询问关于产品的问题，而其他人甚至都没有想到过。等到花费大量的编程时间之后才开始提出这些问题——嗯，这对你来说是否明智？

我的一些最好的缺陷（除了我们称之为审查意见）是在编写一行代码之前提出的。在瀑布环境中工作时，如果一个项目来我们这里进行测试，但没有对需求进行静态测试（或执行得不好），我们认为这是高风险的（因为这些项目通常在成本和时间上超支- 如果他们没有先被取消）。在敏捷环境中工作时，我希望能够提出一些问题，这些问题揭示了其他人尚未想到的场景。

是的，这确实意味着测试人员需要分析技能。但是，如果他们没有这些技能，他们将无法设计出好的测试。如果他们只是设计验证性测试来检查需求是否得到满足，而不是对其进行测试——那么他们就不是在进行测试，只是在进行检查。

另一部分是，如果您在需求阶段不让测试人员参与进来，这意味着他们没有及早开始建立对问题空间的理解，这会威胁到他们测试的价值。

一个好的测试人员有可能处理那些刚刚被扔到墙上的东西——有一些策略来处理它。但如果你有选择，那你为什么不早点得到反馈，而不是晚点呢？

除了 QA 和我以前的雇主之外，我还完成了一些 BA，毫无疑问，在我看来，我的测试结果更加彻底。

我没想到的一件事是：开发人员对我编写的需求文档非常着迷，因为我以一种他们可以关联的方式将技术细节与客户的“需求”整合在一起。

虽然已经至少 6 年前了，但我记得他们在我的办公桌前停下来感谢我的这些要求。这种情况多久发生一次？

在我的商店中，测试人员（以及开发人员）正式审查需求。我们提前阅读文件，然后与整个项目团队一起进行审查。

我们发现具有领域知识和不同观点的测试人员可以在多个领域提供见解

• 检查可测试性要求
• 检查清晰度、一致性、完整性
• 试图在设计开始之前确保业务和开发之间的思想会面

我们发现，这种预先关注有助于从一开始就防止错误的发生。预防错误总是比发现错误更好。

因此，如果您考虑这种“测试”，那么您的问题的答案“是否应该反过来也适用于测试人员（更多）参与并执行需求的静态测试？” 那么我的回答是“是”。

您可能想阅读《软件测试的有效方法》一书。它有一些用于检查需求等内容的清单。虽然这本书足够大，可以作为一个门挡，但它也有很多用于测试和 QA 各个阶段的清单。