Is the acceptance standard a test case?

Agile quality practices advocate testing to the left , Testers should intervene in the requirements stage as soon as possible , The sooner the better . Testers need to focus on the effectiveness of requirements , And in the process of requirements generation and transmission , Whether the delivered value is accurately described 、 Understanding and alignment . In this process, it is easy to encounter a common problem ： Is the acceptance standard to be tested in the acceptance test ？ Whether the acceptance criteria are test cases or not ？ What are the differences and connections between the two ？ The main purpose of this paper is to solve this specific confusion .

Acceptance criteria are the minimum set of requirements to ensure their realization

What are the acceptance criteria

Recall that demand consists of thick 《 Software requirements specifications 》 The process of evolving into a user story card , In this process, we abandoned a lot of details , Highlight the needs of customers who need to be delivered / User value . In the process of requirement delivery , We will always focus on value , On the premise of ensuring value , The implementation method and technical details can be discussed .

So here comes the question , Since many contents can be discussed , How do we determine that a user story has been implemented ？ Acceptance criteria are the touchstone for the completion of user story implementation . It can be said that , Whether a user story can be marked as development completed and entered the testing stage , Largely depends on whether the acceptance criteria are all passed .

Generally speaking , Acceptance criteria are a set of acceptable conditions or business rules , And match and meet with the functions or characteristics , At the same time, it can also be accepted by the product owner and relevant stakeholders .

In agile practice , Behavior driven development is recommended （Behavior-driven development, abbreviation BDD） The way to write acceptance criteria , That is to use GWT Format .

• Given （ Under what circumstances or conditions ）
• When （ What action has been taken ）
• Then （ What is the result ）

for instance ：

• Given （ hypothesis ） I'm in the search interface
• When （ When ） I fill in the city I live in , Choose the time of stay
• Then （ therefore ） I can browse the names and prices of free hotels in the city and in that time period

When preparing acceptance criteria , Focus on user scenarios where requirements can be verified , More forward verification is that the implementation of user requirements is completed , Never write the acceptance criteria as test cases or test points .

When will the acceptance criteria be used

Story start （Story Kickoff）

When the story starts , All roles involved in requirements ： Demand analyst 、 Development 、 test 、 Experience designer , We need to sit together and clarify our needs , Ensure that everyone has a consistent understanding of the requirements , And agree on the acceptance criteria for story acceptance . In the process , Anyone can ask questions about the acceptance criteria , Or add more acceptance scenarios .

Story acceptance （Desk Check）

When the developer completes the code implementation , Do some basic self-test work , And prepare acceptance scenarios and data , You can ask everyone to check the story . At the time of acceptance , It also requires all the roles of requirements design , We all sit together , Listen to the development and implementation details , And demonstrate the acceptance scenarios one by one . If all the acceptance criteria are verified , There are no other questions , This user story can then be marked as development complete , Ready to go into the testing phase .

User acceptance test （User Acceptance Test）

In addition to the testing of the R & D team , Iterative delivery also requires some user acceptance testing . The designer and executor of user acceptance testing is sometimes PO、 Or customers and relevant stakeholders who put forward needs , Sometimes it's a real user in a small-scale test or public test . During the user acceptance test , The executor will also refer to the acceptance criteria to some extent , Check whether the acceptance criteria are complete , Whether it can meet the user's expected verification .

Acceptance criteria are not acceptance tests

From the above discussion , We can conclude that ： Acceptance criteria are the criteria that define the completion of user stories . The acceptance test is divided into two parts , Part of it happens after the user story is developed , It is the internal acceptance of the R & D team , The other part is after the test and before going online , Acceptance by customers or real users . thus it can be seen , Acceptance criteria are not equal to acceptance tests , Acceptance criteria are the minimum set of acceptance criteria , The scope of acceptance testing is wider .

Test cases verify the effectiveness of software functions

What are the test cases

A test case is a set of test inputs prepared for a particular goal 、 Execution conditions and expected results , In order to test a program path or verify that a specific requirement is met . Simply speaking , Test cases are written to describe how to test a test point , And what the expected test results are .

Test cases typically include ： describe 、 priority 、 Prerequisite 、 Execution steps 、 Expected results 、 Information such as actual results and comments . According to the respective characteristics of the project , Test cases contain different information .

When are test cases used

Use case design and review

In the test design phase , The tester will test according to the requirements , Use a variety of design ideas to write test cases , And submit it to the test team or project team for use case review . here , Test cases carry the test points of business requirements , And the verification points of non business requirements identified by testers based on professional experience .

The test execution

In the test execution phase , Testers （ Sometimes it's also the use case writer ） Execute the test case according to the detailed description of the use case , And according to whether the actual implementation results are consistent with the expected results , To determine whether the test case passes the test . Use cases that fail need to analyze the reasons , Report defects or follow up in other ways .

regression testing

Develop and improve the functions related to use cases , Or fix related defects , You need to regress the specified use case , Make sure that the function is not broken , Or the defect is actually fixed . in addition , Sometimes before a major launch , We also need to select a certain number of test cases according to priority for regression testing , To ensure that the main business process functions normally .

Communication test points

Test cases also play an important role , Record the specific implementation details and the test scope of the framed requirements . Multiple iterations passed , When you need to look at historical needs , Maybe the story card is not enough to restore all the implementation details , The test case set can tell you completely at this time ： How is the software implemented , When performing certain operations , What is the performance of the program , And what was the test scope of this requirement at that time . Especially when the context of team members is insufficient , A well-designed and written use case set can perfectly complement this knowledge .

Acceptance criteria are not test cases

Above, we discussed the acceptance criteria and test cases , And at what stage . Easy to come by , Acceptance criteria and test cases are two completely different things , The similarity between the two is that they are decidable user use scenarios , You can judge whether to pass according to the expectation , The difference between the two is reflected in the dimensions in the table below .

In this article, we also discussed that acceptance criteria are not acceptance tests . In terms of coverage only , Acceptance criteria 、 The acceptance test 、 Refer to the following figure for the relationship between test cases ：

• The test case ： Maximum coverage , It should be to ensure that the software functions properly 、 A complete set of tests that meet user expectations
• The acceptance test ： Coverage is smaller than test cases , Only the test cases required for acceptance are covered
• Acceptance criteria ： Coverage is smaller than acceptance testing , Only the test cases that verify the completion of the requirement implementation are covered

Of course , Acceptance criteria and test cases, in addition to the time of use , The difference between the two is also reflected in different responsible persons and scope of use . The person responsible for the acceptance criteria is the requirements analyst , Use... In teamwork , It is the basis of multi role cooperation ; The person responsible for the test case is the tester , Content that belongs to the professional context of testing . But under different organizational structures , There will be some vague boundaries in the definition of roles , therefore ,“ The whole team is responsible for the acceptance and quality of requirements ” It's a recommended idea .

I believe that after the clarification of this article , We have understood the acceptance criteria and test cases . With the development of the industry , To test the left shift , More and more testers will need to understand the requirements ; Corresponding , In order to efficiently produce high-quality demand , There are also more and more requirements analysts who need to understand testing . Requirements analysts and testers work together to create high-quality requirements , It will lay a solid foundation for delivering high-quality and high-value Software .

Recommended reading

1. Test shift left ： Demand related quality assurance
2. How to measure demand quality

---

writing /Thoughtworks Yu Xiaonan

Link to the original text ： https://insights.thoughtworks.cn/acceptance-criteria-testcases/