Changes for page Acceptance Tests

Summary

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

Details

Page properties

Content

...	...	@@ -2,7 +2,7 @@
2	2
3	3	Acceptance Tests provide an unambiguous completion criteria for stories, the **Definition of Done**. A story is done when its associated acceptance tests have passed, along with all other existing tests. Only then can the estimated points of a story be added to the charts at the end of an iteration.
4	4
5		-* **Integration Of All Components**: Acceptance testing is the ultimate test of whether a feature works or not. To check this, the software must be deployed in production mode and then tested from the user's point of view; if there is a GUI, this is usually done by interacting with it. Common tools used to simulate such user interactions are Cypress and Selenium.
	5	+* **Integration Of All Components**: Acceptance testing is the ultimate test of whether a feature works or not. To check this, the software must be deployed in production mode and then tested from the user's point of view; if there is a GUI, this is usually done by interacting with it. A common tool used to simulate such user interactions is Cypress.
6	6	* **Always Production Ready**: Acceptance testing ensures the stability of the software by proving that it works correctly if it passes the tests. This prevents developers from inadvertently breaking features by changing the code. Therefore, software functionality cannot evolve backwards. However, this does not prevent code from technically rotting under the surface, so code should also be kept clean, not just functional.
7	7	* **Execution Frequency**: Since running all acceptance tests can take a very long time, it is common to schedule an automated run once a day at midnight. If bugs occur, they are addressed immediately the next day.
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.