Skip to Content

Changes for page Acceptance Tests

Last modified by chrisby on 2024/05/11 08:20
From version 2.14
edited by chrisby
on 2023/12/07 22:02
Change comment: There is no comment for this version
To version 2.16
edited by chrisby
on 2024/05/11 08:17
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -8,25 +8,23 @@
8 8  * **Implementation Timing**: Stories should not wait for acceptance tests to be completed. Ideally, acceptance tests should be started to be written in the previous iteration, but no later than after the IPM, so that they are completed before the story they verify. Since it is not possible to know with certainty which stories will be implemented in the next iteration, testers can ask stakeholders which stories are likely to come next. If acceptance testing is consistently late, QA will need to hire more people. QA and developers should communicate and negotiate the test structure, perhaps even pair programming, instead of the "eat or die" tactic of writing tests without consulting the developer.
9 9  * **Level of Detail**: The business should specify the requirements at a level of detail that is specific enough for the developers to know what to do, but still short and vague enough not to contain details. Acceptance tests are story specification.
10 10  * **Requirement Automation**: Wherever practically feasible, requirements should be written as automated tests.
11 -* **Acceptance Test Anatomy**: Acceptance tests consist of **technical acceptance test code** and can contain **business acceptance test code**. The business acceptance test code is written in English and in natural language and, when executed, they run the technical acceptance test code written in a programming language. Acceptance tests are the link between easy-to-understand business requirements and test automation.
11 +* **Acceptance Test Anatomy**: Acceptance tests consist of **technical acceptance test code** and can contain **business acceptance test code**. The business acceptance test code is written in natural language (English) and, when executed, they run the technical acceptance test code written in a programming language. Acceptance tests are the link between easy-to-understand business requirements and test automation.
12 12  
13 13  ### Sample Acceptance Test
14 14  
15 15  Below is the business acceptance test code of a "Login Scenario" written in the "Gherkin" language, which is used, for example, by the Cucumber acceptance testing framework:
16 16  
17 -```cucumber
18 -Feature: User Login
19 - In order to access my account
20 - As a user
21 - I want to be able to log in using my credentials
17 + Feature: User Login
18 + In order to access my account
19 + As a user
20 + I want to be able to log in using my credentials
21 +
22 + Scenario: Successful login
23 + Given I am on the login page
24 + When I enter a valid username and password
25 + And I click the login button
26 + Then I should see my dashboard
22 22  
23 - Scenario: Successful login
24 - Given I am on the login page
25 - When I enter a valid username and password
26 - And I click the login button
27 - Then I should see my dashboard
28 -```
29 -
30 30  * **Ease of Comprehension**: As shown above, the technical keywords in business test code are replaced with easy-to-understand ones that allow business people to read and write executable tests. Business acceptance test code should always be available to stakeholders.
31 31  
32 32  ### Tester Roles