Changes for page Acceptance Tests

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -8,11 +8,11 @@
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 test code** and can contain **business test code**. The business test code is written in English and in natural language and, when executed, they run the technical 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 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.
12	12
13	13	### Sample Acceptance Test
14	14
15		-Below is the business test code of a "Login Scenario" written in the "Gherkin" language, which is used, for example, by the Cucumber acceptance testing framework:
	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	17	```cucumber
18	18	Feature: User Login
...	...	@@ -27,13 +27,13 @@
27	27	Then I should see my dashboard
28	28	```
29	29
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 test code should always be available to stakeholders.
	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
33	33
34	34	Larger software teams in particular have distinct roles for people writing acceptance tests. All testers collaborate with the developers to ensure that the acceptance tests are technically meaningful.
35	35
36		-* **Business Analysts (BA)**: Works with customers to gain an accurate understanding of the requirements and translates this into 'happy path' tests, which assume the ideal sequence of events where everything works as expected. For example, all user inputs are correct, software is being used as intended by the developers, etc. The workflow is usually that the business writes the business test code for the acceptance tests. The business analyst then automates the tests by writing the technical test code.
37		-* **Quality Assurance (QA)**: Writes acceptance tests for the 'unhappy path', i.e. everything that could possibly go wrong. For example, invalid user input, unintended use of the software, etc. QA usually requires more resources, as there are much more test cases to cover. QA should be technically experienced, to have a good eye for triggering bugs. Because the business does not see these unhappy path tests, no business test code is required, reducing overhead.
	36	+* **Business Analysts (BA)**: Works with customers to gain an accurate understanding of the requirements and translates this into 'happy path' tests, which assume the ideal sequence of events where everything works as expected. For example, all user inputs are correct, software is being used as intended by the developers, etc. The usual workflow is that the business and the BA write the business acceptance test code for the acceptance tests together. The business analyst then automates the tests by writing the technical acceptance test code on his own.
	37	+* **Quality Assurance (QA)**: Writes acceptance tests for the 'unhappy path', i.e. everything that could possibly go wrong. For example, invalid user input, unintended use of the software, etc. QA usually requires more resources, as there are much more test cases to cover. QA should be technically experienced, to have a good eye for triggering bugs. Because the business does not see these unhappy path tests, no business acceptance test code is required, reducing implementation effort.
38	38
39	39	While BA's provide more of a late feedback to check if a feature works as expected at the end of story implementation, QA's need to collaborate with developers early because in case problems are found by the unhappy path tests, the developers need enough time to fix the issues.