When writing user story acceptance criteria, many small partners are entangled in whether they are writing acceptance criteria and what level of detail to write. They are confused about the relationship between acceptance criteria, acceptance tests , and test cases . Today I will share my experience. You are also welcome to leave a message in the comment area to add your opinion.
Acceptance Criteria
1. What is the acceptance criteria
Acceptance criteria for a user story are specific criteria or specifications that describe the completion of the user story. It refers to the criteria and test conditions for verifying that a particular user story meets customer expectations, and it contains measurable, explicit, and verifiable user story conditions to ensure that the customer's needs and expectations are fully met when the user story is completed . Acceptance criteria should be acceptable, testable, understandable, and part of a recognized agreement with stakeholders.
Acceptance criteria are usually documented in user stories as criteria for determining whether a particular user story is complete or not, and help the development team and stakeholders to ensure that the software being developed simultaneously meets the needs and expectations of users.
A good acceptance criteria should have the following characteristics:
1. Testability: Acceptance criteria must describe a testable condition, so that it is clear to the development team and other stakeholders whether the functionality has been successfully implemented.
2. Clear and specific: Each acceptance criterion must be very clear and specific to avoid any situation of ambiguity, ambiguity or misunderstanding, thereby reducing the difficulties or mistakes that the development team may encounter when implementing the feature.
3. Measurable and Verifiable: Acceptance criteria must be measurable and verifiable, so that after a feature is implemented, the development team can quickly verify that the feature meets customer and user expectations.
4. Acceptability: The acceptance criteria must represent the consensus reached with the customers or users of the product or service, so that the development team can maximize the satisfaction of customers and users' expectations when implementing the function.
5. Understandability: Acceptance criteria should be easily understood and shared by the development team and other stakeholders in order to reduce communication barriers and errors of understanding.
2. Examples
User story:
As an online shopper, I want to search and filter the items for sale so that I can quickly find what I need.
Three possible acceptance criteria for this user story are listed below:
1. Users can enter keywords in the search box and see all matching results.
2. Users can further filter the search results by using the advanced filtering function, such as filtering by multiple dimensions such as price, brand, and color.
3. Users can click on each search result to view detailed information about the product they are interested in, including information such as price, quantity, description, and reviews related to the product.
Acceptance Test
1. What is acceptance testing
Acceptance testing, as a testing method, is a test performed in the later stage of software development . It is a testing process used to verify that a software system meets acceptance criteria. In acceptance testing, testers define test cases based on acceptance criteria to verify that the software system meets the expected quality standards and customer expectations. If the software system passes the acceptance testing, the software meets the acceptance criteria and meets the needs of the customer or business user; otherwise, the system needs to continue to be tested and modified to ensure that the system meets the acceptance criteria.
2. The relationship between acceptance testing and acceptance criteria
Acceptance criteria and acceptance tests are complementary and inseparable. Acceptance criteria are to determine the requirements that the software needs to meet, while acceptance testing is to verify that the software actually meets these requirements. Only when both acceptance criteria and acceptance tests are given sufficient attention and treatment can it be ensured that the software system finally meets the user's expectations and quality standards.
An acceptance criterion can correspond to one or more acceptance tests, depending on the test requirements and test scope. Often, a large or complex acceptance criterion may require multiple acceptance tests to be tested to verify the functionality of various aspects of the system. On the other hand, a smaller or simpler acceptance criterion may require only one test case, covering the corresponding test requirements.
3. Examples
For the second acceptance criterion above:
Users can further filter the search results by using the advanced filtering function, such as filtering by multiple dimensions such as price, brand, and color.
We write three possible acceptance tests as follows:
1. Verify a single dimension for advanced filtering: Select any dimension that can be advanced filtered (such as price), and verify that users can correctly filter out relevant search results by selecting the corresponding filtering conditions. If the result set is correct, the acceptance test passes.
2. Verify the multi-dimensional filtering capabilities of advanced filtering: Select two or more dimensions that can be advanced filtering (such as brand and color), and verify that users can correctly select multiple criteria to filter out the corresponding set of search results. The acceptance test passes if the result set is accurate and as expected.
3. Verify the performance of advanced filtering: Try using advanced filtering to filter and sort large amounts of data and verify that search results load quickly. The acceptance test passes if the result set loads quickly without any errors or exceptions.
test case
1. What is a test case
A test case is a document that provides the detailed steps and data inputs of how a tester performs a test, as well as the expected output and results. Usually, a test case is composed of test case numbers, test items, test input data, operation steps, expected results, and actual results.
2. The relationship between test cases and acceptance tests
There is a close relationship between test cases and acceptance tests. During acceptance testing, test cases are the primary means of assessing whether the software satisfies the stated requirements. By running test cases, testers can check whether various functions of the software operate as expected, and whether the required results meet the standards and specifications. Therefore, test cases are an important part of the acceptance testing process.
An acceptance test can include one or more test cases, because an acceptance test may need to test multiple functions or multiple operations. Each test case is the steps and data input, expected output and result required to test a specific function or operation, so the cooperation of multiple test cases is usually required in an acceptance test to complete the entire testing process. Conversely, a test case usually only tests one or a group of related functions.
3. Examples
For the second acceptance test above:
Verify the multi-dimensional filtering capabilities of advanced filtering: Select two or more dimensions that can be advanced filtering (such as brand and color), and verify that users can correctly select multiple criteria to filter the corresponding set of search results. The acceptance test passes if the result set is accurate and as expected.
We can write the following three test cases:
Test case 1:
Test purpose: Verify that the multi-dimensional filtering function of the brand and color filters is correct.
Test steps:
1. Enter the advanced filter menu.
2. Select " Apple " as the brand and "Blue" as the color, and click the search button.
3. Check that the search result set is as expected.
Expected result: The search result set contains only products with brand "apple" and color "blue".
Test case 2:
Test purpose: Verify that the filtering effect of at least three dimensions is as expected.
Test steps:
1. Enter the advanced filter menu.
2. Select the brand as " Samsung ", the color as "White", and the price as "500-1000 RMB", and then click the search button.
3. Check that the search result set is as expected.
Expected results: The search result set only includes products with the brand "Samsung", the color "white", and the price "500-1000 yuan".
Test case 3:
Purpose of the test: To verify whether the system can correctly process when an invalid filter condition is selected.
Test steps:
1. Enter the advanced filter menu.
2. Select "Apple" and " Huawei " in the "Brand" option , select "Black" in the "Color" option, and click the search button.
3. Check that the search result set is as expected.
Expected result: The system should return the search results normally, which does not contain any products with the brand "Huawei", and all returned products should be black.
Summarize
In the actual process of writing user stories, everyone writes various acceptance criteria, some of which are more abstract and careless;
I think these are all acceptable. It doesn't make much sense to worry about whether we write the so-called "acceptance criteria", "acceptance tests" or "test cases", as long as it works and suits your own team.
For teams with low maturity, the acceptance criteria should be written in more detail, so that everyone’s work will not deviate too much, and save time for later repair and rework. Of course, the disadvantage may be that it takes a lot of time to write acceptance criteria , and may also limit the emergence of optimal solutions.
For a more mature team, the acceptance criteria are written in a rough and careless way so that there will not be too much bias, because everyone may have worked together for a long time, whether it is the degree of understanding of domain knowledge or everyone's understanding of many things The degree of consistency has a very high level, and relatively basic operations and cognition do not need to waste ink. The advantage of this is that it saves time and works efficiently. At the same time, it also provides more space for various roles to play.
To what extent the acceptance criteria are written, the key is to choose the plan that maximizes the benefits according to the actual situation of your team.
Finally, I would like to thank everyone who has read my article carefully. Reciprocity is always necessary. Although it is not a very valuable thing, you can take it away if you need it:
These materials should be the most comprehensive and complete preparation warehouse for [software testing] friends. This warehouse has also accompanied tens of thousands of test engineers through the most difficult journey, and I hope it can help you! Partners can click the small card below to receive