Then the "estimate story" said, after the completion of the story estimate will start to consider how to carry out the acceptance test, only the acceptance through the story to calculate the development completed.
For a story, developers and customers may discuss a lot, the content of the discussion can be recorded in the form of test cases, so as to pave the way for our story testing, the current Agile development testing about the following 2 steps
1, record the test points to the back of the Agile story card, any time to find new tests, can be recorded on the back of the story card
2, the test points into a comprehensive test, these tests to demonstrate that the story is correct, complete implementation
Let's talk about when to write test cases and how to test them.
Write tests before writing the code
Acceptance testing can provide a lot of useful information to programmers, often see the acceptance test instructions to ensure that the programmer does not write the code that does not conform to the test instructions, should write the test at the following time
1, developers and customers to discuss the story and need to record clear details
2, at the beginning of the iteration, before writing code as a special task
3. When new tests are found in development or at any time
you can collect test cases using the following method of questioning
1. What do programmers want to know about this story?
2, to how to achieve this story, what is my idea?
3. Are there any special circumstances that will make the story behave differently?
4. What's wrong with this story?
Customer defined Test
The customer can work with the programmer and the tester to create the test, but the customer should at least give us some detailed tests to verify that the story was implemented correctly
1. Testing is part of the process
Testing is part of the development process, not what you do after the coding is done, which is very important for using user stories.
2. How many tests are counted?
As long as these tests continue to add value to the story and it is clearer, customers should continue to write tests.
3. Test Type
1. User interaction test to ensure all user interaction components work as expected
2, usability testing, to ensure the application of good
3, performance testing, testing the application under various load of work state
4, stress testing, so that the application in the user and the limit value of things or any other let the application under pressure to run the situation
Acceptance Test Summary
1. The acceptance test can be used to record the details of the work discussed by the customer and the developer.
2, acceptance test can have some assumptions about the story, these assumptions may not have been discussed with developers
3. Acceptance testing provides the basic criteria to check whether a story is fully implemented
4. The acceptance test should be written by the customer rather than by the developer
5. The acceptance test should be written before the program writes the code.
6, if the new acceptance test to clarify the details of the story of the living intentions without any help, you don't have to write
Responsibilities of the developer
Responsible for automated acceptance testing if the team feels the need
When you start developing a new story, take charge of more acceptance tests
Responsible for unit testing of the code so that the acceptance test does not have to estimate every detail of the story
Customer Responsibilities
Responsible for writing acceptance test
Responsible for performing acceptance tests
For more information on Agile acceptance testing, you can refer to the user stories and agile methods
Agile Development (iv)-story acceptance test