如何为框架API编写用户故事
我需要帮助理解我们为组织的QA部门构建的web测试框架应该是什么样子的用户故事。我们正在尝试使用Scrum来运行这个项目。
该产品将分为三层：
- 实用工具类，使使用底层web自动化工具更容易。
- 一个页面对象API层，它将允许我们的测试人员从我们的web页面提供的服务的角度来编写测试，而不是从web自动化工具的角度。
- 一个声明层，它将允许用英语类型的语言编写测试--也许是类似黄瓜的场景。该层将映射到页对象API层，以便如果不能以声明方式执行测试，则测试作者可以降至页对象API层。
这个框架的最终用户是我们的QA组，他们将在声明级编写测试，或者如果需要的话，编写页面对象API级别的测试。
我的问题是，我们的用户故事应该是什么样子？目前，我们的报道涵盖了网络自动化应该做什么(即。在页面上查找元素，等待元素出现)，但这是不对的。首先，我们可以通过向QA组提供底层的自动化工具来交付这类信息。这些故事显然不值得在sprint回顾中展示。
第二，故事应该表明业务价值，在本例中，业务价值不是在页面上查找元素，而是在：
- 基于最新的、流行的、有效的网络自动化工具进行测试.
- 具有可读性测试
- 将实际测试从驱动它们的web自动化工具中分离出来。
好吧，但是我如何将产品分解成更具体的用户故事呢？
回答 2
Software Engineering用户
发布于 2013-02-26 00:29:44
我建议对故事进行垂直切分，而不是横向分割：
作为QA组成员，我可以使用特定页面的页面API编写测试，单击按钮并验证是否导航到正确的目标页面。
然后实现必要的页面API层和基本层来支持这一点，而不是更多。这是可以证明的，并且具有商业价值:您实际上可以编写测试并运行它。
然后跟进其他垂直切片：
作为QA组成员，我可以编写到特定页面的测试，填写文本框，单击按钮并验证是否导航到正确的目标页面。
和渐进式改进(例如Cuke)
作为QA组的成员，我可以使用像DSL这样的黄瓜编写一个测试，该黄瓜可以转到特定的页面，单击一个按钮并验证我是否导航到了正确的目标页面。
Software Engineering用户
发布于 2013-02-26 00:56:47
这是个危险的案子。Scrum命令跨功能团队，这意味着QA的“用户故事”比开发人员的故事更有意义。QA不是用户，它们是开发过程的一部分，而自动验收测试--假设您真的致力于使用它们--最好是这样反映出来的。
当我们第一次开始在我的团队中做这种测试的时候，它是一个高峰。然后，每项功能都进入“测试”阶段，任何框架级的开发都由各个任务负责。这是有意的；我们想要向管理层反映，测试不再是可选的，推迟测试只会导致其他特性的开发时间更长。
当测试开始变得过于粗糙时，我们将其分解为技术债务，并分配一天甚至一周时间来处理。
我对内部用户故事的体验非常糟糕。你永远无法确定它们何时完成，因为正如你自己所看到的那样，接受标准是可以解释的。
如果您被迫创建用户故事，我建议的是在每个服务/操作中创建一个故事，例如：
作为一名测试人员，我希望能够通过web浏览器自动成功登录，这样我就可以为登录功能编写自动化测试。
这些故事会重复，就像故事经常被不恰当地使用时一样，但是它比在页面上寻找元素的测试要好，正如您所说的，框架已经提供了这些元素。在这种情况下，每个故事(大致)对应一个Gherkin步骤或条件。
您还可以将所有步骤划分为任务，并为整个页面/服务创建一个故事。这取决于你的团队工作的速度。如果您可以在一个周期内对整个页面及其所有服务进行建模，那么就去做吧。如果你不确定，坚持每个服务的故事，或开始一个尖峰，以提高你的估计。
https://softwareengineering.stackexchange.com/questions/188377
复制相似问题
腾讯云开发者
