问题描述
我们正在开发一个包含许多不同组件的巨大产品。用户故事由 BA 团队编写，验收标准由 Gherkin 编写。验收标准定义明确，但水平很高，QA 团队将编写更多其他自动化测试用例以及手动测试。 QA 团队是否应该使用这些 BDD 验收标准作为基线来编写回归测试套件并维护回归套件？或者 QA 应该使用 Cucumber 等 BDD 工具并开发自动化测试用例？
解决方法
没有正确答案，根据我的经验，所有回归和冒烟套件都是由 QA 团队编写的。您不能将手动测试和自动化测试分开而只依赖其中之一。 BDD 方法适用于经理会阅读 Cucumber 测试以阐明要测试的内容和应该测试的内容的公司，否则就是浪费时间。我建议 QA TL 与 PM 开会并澄清那些时刻，然后您将为您的团队选择最佳方法。
,我一直在为一个大型项目提供咨询，该项目大量使用 BDD。我们有与您上面提到的类似的要求。 BA 定义了具有良好验收标准的用户故事。根据我的经验，推出 BDD 的关键是：
- 协作
- 编写有效的场景
- 自动化
您可以使用这些用户故事与 3 位朋友合作，推导出使用 Gherkin 编写的场景并达成一致。为了使场景有效，请考虑使用特定领域的真实世界示例。您可以考虑使用 OOPSI 等协作技术使其更有效（请查看此博客，其中我已经解释了 OOPSI https://blog.nocodebdd.com/bdd-unit-testing/）
一旦定义了场景，您应该与团队合作来决定哪些场景应该自动化，哪些场景应该像手动测试一样保留。 IMO，属于探索性条件的场景应保留用于手动测试，所有其他场景应自动化。尽管自动化听起来可能很昂贵，但从长远来看，它总是值得的。
简而言之：
- 使用用户故事进行协作并衍生场景
- 使用真实世界的例子编写有效的场景
- 尽可能自动化
最后，BDD 不仅仅是一个 QA 工具。这是整个团队都遵循的过程。