Development Management checklists (14)-agile development-story Acceptance Test

Note: The Development Management Checklists-series of articles are transplanted from my iteye blog. The Development Management checklists column will be updated directly in the future.

Next I will talk about the "estimation Story". After the story estimation is completed, I will begin to consider how to carry out the acceptance test. Only when the story is accepted will the development be completed.

For a story, developers and customers may discuss a lot. The discussion content can be recorded in the form of test cases, which paves the way for the story test, at present, there are two steps to test in Agile development:

 

 1. Record the test points to the back of the agile story card. Any time you find a new test, you can record it to the back of the story card.

2. Change test points to comprehensive tests to demonstrate the correct and complete implementation of the story.

 

The following describes how to write test cases and test methods.

 

Write the test before writing the code

The acceptance test can provide a large amount of useful information for programmers. Regular reading of the acceptance test instructions ensures that programmers do not write code that does not conform to the test instructions,Write the test as follows: 
1. When developers and customers discuss stories and need to record clear details
2. As a specialized task at the beginning of iteration and before code writing
3. New tests are found during development or at any time

You can use the following method to collect test cases: 
1. What else do programmers want to know about this story?
2. What is my idea about how to implement this story?
3. Is there any special situation that will make this story behave differently?
4. When will this story go wrong?
 
Customer defined test 

The customer can work with programmers and testers to create tests, but the customer should at least give us some detailed tests to verify that the implementation of the story is correct.

1. Testing is part of the process

Testing is part of the development process, rather than the work to be done after coding, which is very important to the use of user stories.

2. How many tests are considered too many?

As long as these tests continue to add value to the story and make it clearer, the customer should continue to write the test.

3,Test Type

1. Test user interaction to ensure that all user interaction components work on schedule
2. availability test to ensure that the program is easy to use
3. test the performance of applications under various loads.
4. Stress Testing enables applications to run under the limits of users and things or any other running conditions that put applications under pressure
Acceptance Test Summary

1. acceptance tests can be used to record the work details discussed by customers and developers.
2. Some assumptions about the story are ready for acceptance testing. These assumptions may not have been discussed with developers.
3. Acceptance testing provides basic criteria for checking 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 completed before the program code is written.
6. If the new acceptance test does not help clarify the details of the story
Responsibilities of developers

The team is responsible for automated acceptance testing if they feel they need it.
Consider more acceptance tests when developing a new story
Conducts unit tests for the code so that the acceptance test does not have to estimate every detail of the story.
Customer Responsibilities

Prepares acceptance tests
Responsible for performing acceptance tests

For more information about agile acceptance testing, see user stories and agile methods.

<Development Management checklists> by dylove98 @ Development Management checklists