Acceptance Testing

"Working" and "Usable" Are Different

While unit tests and functional tests verify "whether the code works correctly," acceptance tests verify "whether the product meets what the business requires." Even if there are no bugs, a release cannot proceed if the behavior differs from the requirements.

Acceptance tests are often written in a format close to natural language. Scenarios are described in terms of user actions and expected outcomes — for example, "When an administrator logs in and opens the employee list, only employees belonging to their own tenant are displayed." The Gherkin (Given-When-Then) syntax is a representative format for this.

Degree of Automation

Some acceptance tests are executed manually, while others are automated using tools such as Playwright. In ATDD (Acceptance Test-Driven Development), acceptance criteria are defined first, implemented as automated tests, and then development begins. Since relying on manual testing tends to reduce execution frequency, automating critical scenarios has become standard practice.

Relationship with Sprint Reviews

In Scrum development, the results of acceptance tests are often reviewed during the Sprint Review. Since these results serve as the basis for the Product Owner to determine "whether this feature is acceptable," it is ideal for the team to agree on test scenarios during Sprint Planning.