What is acceptance test driven development
Before you are ready to implement a feature or feature, the team first needs to define the desired quality standards and acceptance rules to drive developer TDD practices and test script development for testers with a clear and consensual acceptance test plan that includes a series of test scenarios.
Note: Testers must be part of the team and play a key and controlling role in the ATDD process.
The typical ATDD development process is:
Step 1: The product owner explains the user stories to testers and developers to clarify their questions;
Step 2:
A. Testers list all test scenarios that are validated by the acceptance of the function, and each test scenario is usually a summary and a clear word;
B. At the same time, developers to find and analyze existing relevant design, code and unit testing, clear development strategy;
Step 3: Testers and developers work together to review and adjust the test scenario list, reach a consensus, seek the participation and validation of the product owner when necessary, and make sure that the scenarios have unit tests;
Step 4:
A. Based on a list of test scenarios through review and approval, testers begin to create detailed acceptance test cases for each test scenario, prepare test scripts and test data;
B. At the same time, based on the same test scenario list, the developer starts adding unit test cases and driving the business implementation in TDD mode;
Step 5: Before the developer deploys the completed functionality and delivers the tester to execute the test, conduct a code review and quickly verify the functionality that you have completed based on the test scenario list, or even invite testers to observe;
Step 6: Once the completed functionality is built and deployed to the test environment, the tester immediately starts executing the test script;
Step 7: Any defects found in testers ' tests should be recorded to the tools and tracked, immediately fed back to the developer for resolution, or otherwise properly handled;
Step 8: Finally, at the end of the iteration, team members demonstrate the functionality to the product owner and customer. The actual presentation of those scenarios can be determined at step 3.
This shows that ATDD and TDD, based on unit testing, also fully embodies the characteristics of agile development "business-driven", always from the user's business value; for the development team, ATDD is an externally-oriented, multi-party intervention, based on the pull strategy, parallel development test method To ensure that all delivered products have been adequately tested.
Benefits of ATDD:
1. Improve the quality of delivery products-because of the driver's early intervention, to ensure that all deliverables are tested and to improve the coverage and accuracy of the tests;
2. Improve TDD quality-testers and developers work together to define a list of test scenarios, and are reviewed and revised to help developers write high quality, covering complete unit test cases. Helps address the first limitation of the TDD approach mentioned above;
3. Regression testing-good definition and coverage of the complete unit test and Acceptance test script will help in the future regression test;
4. Eliminate waste-to ATDD, meet and pass all acceptance test scenarios is the primary goal of development, to avoid the team to do some of the customer's worthless work, reduce waste
In the implementation of ATDD, the most important changes and challenges lie in the way testers work and their processes, and these challenges are presented to testers:
* Role Transition-a traditional project, testers are usually an independent QA team, with less collaboration with development teams, and testers work with developers completing development and deployment as a starting point; in agile development, especially in ATDD teams, testers are necessarily members of the development team, And is an important member of the dominant role. Testers can not continue to be passive, but with their own results to drive the development of implementation;
* Communication Skills-traditional project testing is usually based on a complete and detailed requirements document; However, in agile development, the requirements are defined in the simplified form of the user story, testers to list accurate and complete test scenarios, he needs more and product owners, developers to communicate, work closely together every day, Any problems or changes can be immediately feedback to other members of the team;
* Exploratory testing-due to the simplicity of agile user stories, while ATDD develops test scripts based on predefined test scenario lists, and some test scenarios have automated unit tests that no longer require duplicate manual test scripts, the test scripts in ATDD do not necessarily cover all logical and quality standards, so " Exploratory testing "becomes a new hot topic. That is, beyond the established test scripts, perform exploratory testing of current and related functions, trying to discover hidden, unknown errors, or some imperfections. This should be a working habit of testers. Exploratory testing seems random, and there are some ways to follow, such as selling points, breaking tests, extreme tests, shenxiang tests, etc.