如何使用声明性验收测试来捕获需求？ [英] How do you capture requirements with declarative acceptance tests?

问题描述

背景

我想帮助我的团队组织一个新的移动应用项目。我们选择遵循 BDD （另请参阅 BDD定义），以捕获形成每个用户故事的利益相关者和开发者之间的合同的明文英语要求。

我们使用验收测试来记录每个用户故事的要求。验收测试是在冲刺计划之前编写的。

我们将接受条件定义为规则列表（例如：输入验证，默认值，等）和验收测试作为黄瓜方案的列表。我们计划使用 Calabash 进行移动测试。

我感觉验收标准/测试更敏捷，因此更好地解决更正式的需求文档。

我觉得我找到了一个有效的解决方案fo，但我想了解

有一个辩论在黄瓜社区的命令式与声明性测试步骤。我倾向于命令式的，因为开发人员必须知道一个可交付的用户故事是什么样子。

我不觉得UI耦合简单的测试是一个问题。有一些方法可以将UI从测试中分离出来（例如：页面对象）。我也不觉得有详细的步骤，使非技术利益相关者难以理解（除非他们不知道如何使用网络浏览器或移动设备，但这是一个单独的问题）。

我可能盗用了验收测试 。在我使用中，验收测试与单元测试的范围不同。我将验收测试视为高级集成测试。

示例

• 作为客人


• 我要登录


• 访问应用功能

命令性测试

• 情况：有效的登录
  
  
  
  • login屏幕
  
  
  • 在email中输入[e-mail]时
    
    
    
    • inpassword
    
    
    • 然后点击登录
    
    
  
  

声明性测试

b
$ b

• 情况：有效的登录
  
  
  
  • 由于我有一个有效的帐户
  
  
  • 然后我可以登录
  
  

后者更短，但它不说如果我可以用用户名，电子邮件或Facebook / twitter /谷歌/等帐户登录。

如何做到这一点

解决方案

很好的问题！

如何使用声明式
步骤来获取要素的功能？

<

因此，在您的命令式示例中：

 在email中输入[e-mail]时
在password中输入password1
然后点击登录
 

这可以通过重写为：

 由于我使用有效凭证登录
  

导航到有效帐户（即，实现定义什么有效意味着的接受标准）然后可以在该场景声明的步骤定义中实现。相同的情况适用于相反的情形，即

 由于我使用无效的凭据登录
  
 
 
 
同样，实现这种情况的步骤满足验收标准，可以在底层步骤定义中实现。
 
 
 
采用这种声明式方法意味着您会失去功能的（命令式）要求（即需要执行什么确切步骤），使业务难以准确地查看这些场景只是从读取功能文件。然而，你获得的是测试变得不那么脆弱，因为实现任务的具体步骤记录在步骤定义中，并且这个步骤定义可以在许多功能之间共享。
 
 
 
在我的公司，我们努力解决同样的问题，我们发现在某些情况下，最好使用命令式而不是声明式，反之亦然。例如，在你的情况下，组成给定我有一个有效的帐户的步骤可能用于许多功能，所以使其声明是理性的。然而，如果你有一个特性，其中输入了许多不同的字符串值，那么在这种情况下最好是强制写它们。
 
 
 
 马的课程！ 
 
 
 
这将是非常有趣的看到其他来自SO社群的此问题的答案。
 
Background

I am trying to help my team organize for a new mobile app project. We have chosen to follow BDD (see also BDD definition) in order to capture plain English requirements that form a contract between stakeholders and developers for each individual user story.

We use the acceptance tests to document each user story's requirements. Acceptance tests are written before sprint planning. Developers refine and add to the tests during sprint planning.

We define Acceptance Criteria as a list of rules (eg: input validation, default values, etc) and Acceptance Tests as a list of Cucumber scenarios. We plan on using Calabash for mobile testing.

I feel acceptance criteria/tests are a more agile and therefore better solution to more formal requirements documents.

I feel I have found an effective solution fo, but I would like to understand how others are collecting requirements and writing acceptance tests.

Problem

There is a debate in the Cucumber community of imperative vs declarative test steps. I lean toward imperative, because a developer must know what a deliverable user story looks like.

I do not feel UI coupling aka brittle tests is an issue. There are ways to decouple the UI from the test (eg: page objects). I also do not feel that having detailed steps make it hard for a non-technical stakeholder to understand (unless they don't know how to use a web browser or mobile device, but that's a separate issue).

I may be misappropriating the term "Acceptance Test". In my use, an acceptance test is not on the same level of scope as a unit test. I view an acceptance test as a high level integration test.

The Example


As a guest
I want to login
to access app functionality


Imperative Test


Scenario: Valid login

Given I am on the "login" screen
When I enter "[e-mail]" in "email"

And I enter "password1" in "password"
And I tap "login"

Then I see "login successful"



Declarative Test


Scenario: Valid login

Given I have a valid account
Then I can login



These both can cover the same functionality and the latter is shorter, but it does not say if I can login with a username, email or facebook/twitter/google/etc account. It's just not enough to actually code a solution

The Question

How do you capture the requirements for a feature with declarative steps?
解决方案
Nicely written question!

  
How do you capture the requirements for a feature with declarative
  steps?
The requirements for a feature are recorded in the step definitions.

Hence in your imperative example:
When I enter "[e-mail]" in "email"
And I enter "password1" in "password"
And I tap "login"
this could be made declarative by re-writing it as:
Given I login using valid credentials
The steps to navigate to a valid account (i.e. implementing the acceptance criteria which defines what "valid" means) can then be implemented in the step definition for this scenario statement. The same will apply for the opposite scenario i.e.
Given I login using invalid credentials
Again, the steps to implement this scenario which satisfy the acceptance criteria can be implemented in the underlying step definition.

Taking this declarative approach means that you lose the (imperative) requirements from the feature (i.e. what exact steps need to be performed), making it harder for the business to see exactly what these scenarios are doing from just reading the feature file. However, what you gain is that the tests become less brittle, as the specific steps to achieve a task are recorded in the step definition, and this step definition can be shared amongst many features.

At my company we wrestle with the same concerns, and we find that in some cases it's better to use imperative rather than declarative, and vice versa. For example, in your case the steps which make up "Given I have a valid account" may be used in many features, so making it declarative is rational. However if you have a feature where many different string values are inputted, then in that case it's probably best to write them imperatively.

"Horses for courses!"

It'll be very interesting to see other answers to this question from the SO community.

                        
这篇关于如何使用声明性验收测试来捕获需求？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！