在敏捷软件开发中工作时,您经常会看到接受标准的引用。虽然这句话听起来可能不必要地令人困惑,但实际上很简单。尽管并非每个团队都使用它,但这对于成功的发布可能至关重要。那么什么是接受标准?

接受标准定义

接受标准的技术定义是,软件产品必须满足的条件必须被用户,客户或系统级功能(消耗系统)所接受的条件。与开发人员和测试人员查看标志的接受标准列表

简而言之,接受标准是有关新软件功能如何工作/外观的详细信息(也称为要求)的列表。这确保了:

  • 该功能设计得很好。否则,可能会忽略一个重要或有用的方面 - 直到最后才注意到任何人。
  • 它按照预期的方式工作。如果描述模糊,开发人员可能必须对每个区域的工作方式做出假设。有了接受标准,开发人员确切知道预期的设计和功能。
  • 质量保证知道在测试过程中会发生什么。即使功能没有打破,它也可能无法像产品经理想要的那样起作用。如果没有接受标准,则测试人员将无法报告此类问题。

尽管接受标准适用于软件,但通过想象建造房屋可能会更容易理解。在这种情况下,门的接受标准可能是:

  • 用户应该能够穿过门
  • 用户应该能够通过轮椅进入门
  • 门应该有四个侧面
  • 门应该高7英尺,四英尺宽
  • 门的颜色应该是夏威夷·威廉姆斯直接绿色油漆阴影
  • 如果门关门,用户需要一个键来输入

良好的接受标准应该易于理解,但是有足够的细节以确保它不太模糊。它并不总是“一种尺寸适合所有人”。

手机显示带门的房子但是,它应该始终提供足够的信息供开发人员构建该功能,并供QA对其进行测试。这并不意味着在此期间不会提出问题软件开发过程。但是一般功能应该是可以理解的。

想象一下,是否提供了以下信息来建造房屋入口:

它应该有一扇锁定的门。

当第一次想到房屋入口需要什么时,可能会想到的。但是,在将其与上一个列表进行比较时,您可以看到即使是直接功能如何需要接受标准。

接受标准格式/布局/模板

接受标准有两种主要类型,基于方案和基于规则:

  • 基于方案的接受标准使用模板来详细说明涉及的确切用户行为/流程。
  • 基于规则的接受标准更多地是该功能外观/工作方式的简单列表。

基于方案的接受标准

基于方案的接受标准遵循“给定/何时/随后”格式。(该格式的灵感来自行为驱动的发展”,尽管您不需要了解BDD即可使用此类验收标准)。

“给定/何时/随时”模板看起来像这样:

给出[与用户行为有关的一些方面]

什么时候[用户采取一定的动作]

然后[某个结果将发生]

如果需要涵盖多个不同方面,在同一情况下,它也可以包括“和”以继续流动(在给定/何时/何时/inth语句之间)。例如:

给出[与用户行为有关的一些方面]网站上基于方案的接受评论列表与团队观察

[还有其他一些条件正在发生]

什么时候[用户采取一定的动作]

[用户执行另一个动作]

然后[某个结果将发生]

[另一个结果将发生]

(对于基于真实功能的情况示例,请查看下面的示例部分。)

基于规则的接受标准

另一方面,基于规则的接受标准不需要将信息纳入模板中。相反,这是有关该功能应如何外观/工作的简单列表。

例如,基于规则的列表格式可能包括:

  • 所有按钮都应该是一定的颜色
  • 登录按钮应将用户带到某个部分
  • 注册按钮应位于某些区域
  • 如果未满足某些要求

还有很多。尽管基于规则的标准具有更简单的格式,但没有理由仍然不会长时间详细。请继续阅读特定的真实示例。

接受标准示例

以下是使用基本登录页面的几个示例,具有基于方案和基于规则的格式。

使用给定/何时/随时使用的示例(基于方案):

给出用户在登录页面上输入有效的注册电子邮件和密码

什么时候用户点击登录按钮

然后用户应被带到他们的帐户仪表板页面

使用清单(基于规则)的示例:

  • 电子邮件字段需要有效的注册电子邮件
  • 密码字段需要有效的密码
  • 登录按钮应为蓝绿色
  • 登录按钮需要用户来帐户仪表板页面

如您所见,两种类型都可以涵盖相同的基本方面。

团队编写网站的接受标准

谁写接受标准?

通常,多人或团队参与创建接受标准。但是,它主要由产品经理(或“产品主”)撰写。

开发人员负责使功能功能功能,QA负责确认其功能可用性。但是,接受标准是由负责决定添加哪些新功能的人员或团队创建的(无论是哪种类型的应用程序或网站)。

从接受标准编写测试案例

当质量保证有接受标准时,写作要容易得多测试用例。有几个原因:

1。关于该功能应该如何工作,还有更明显的。没有接受标准,质量保证可能必须猜测该功能应如何表现。例如,想象一个新功能,允许应用程序的用户相互发送消息。质量保证可能会编写测试用例,以确保用户可以在所有类型的方案中发送消息。但是,如果接受标准将包括:“用户不能将消息发送给其朋友列表以外的任何人”?没有这些额外的细节,测试用例可能无法准确涵盖对该功能的期望。

2。测试人员可以使用接受标准作为测试用例的框架。接受标准的每一行可以通过测试用例扩展,以涵盖所有可能的用户场景。例如,如果一部分接受标准是“密码字段需要有效的密码”,则可以将其扩展到以下测试用例:

  • 密码字段应该是案例敏感的
  • 输入无效密码后,如果用户单击“登录”,则应出现错误消息
  • 如果用户更改密码,则旧密码不再工作
  • 如果用户更改密码,则新密码应起作用
  • 等等

但是,尽管这并不总是那么容易,但如果需要,您仍然可以在没有接受条件的情况下编写测试案例。在我们的指南中了解更多编写无需要求的测试案例

敏捷Scrum的接受标准敏捷开发Scrum徽标

很大的一部分敏捷涉及随着项目的发展进行更改。那么接受标准可以在冲刺中间改变吗?答案是:“这取决于。”

如果Sprint已经开始,但是开发人员尚未完成该功能,那么更改要求可能会很好。但是,始终先与开发人员联系,并将其他人(例如QA)保存在循环中很重要。

测试人员可能已经书面的测试用例,这些测试用例在更改后不再适用。此外,对于开发人员而言,新的工作可能太多了。

用户故事与接受标准

用户故事和接受标准齐头并进。用户故事描述了新功能的基本目的 - 有关如何帮助用户的概述。接受标准列出了该功能应从技术角度使用的方式。这是门票的常见(例如吉拉或Trello)列出顶部的用户故事,然后是接受标准。

完成的定义

为了将票证(或功能)视为“完成”,所有标准都应工作。例如,假设一个用户的故事是:

作为用户,我希望能够登录以访问我的帐户仪表板。

如上所述,用户可能可以登录以访问其帐户仪表板。但是,如果门票也有包括:

登录按钮应为蓝绿色

实际的登录按钮为黄色。

有时,一个团队即使有少量差异也会决定启动功能。因此,即使没有所有标准,他们也可能将一张机票标记为已完成的机票(或创建单独的票以解决其余方面)。但是就技术定义而言,除非所有接受标准都通过,否则它不是“完成”的。