Skip to content

Acceptance Testing: What, Why and How

  • strict warning: Non-static method view::load() should not be called statically in /home/artemmarchenko/ on line 823.
  • strict warning: Declaration of views_plugin_display::options_validate() should be compatible with views_plugin::options_validate(&$form, &$form_state) in /home/artemmarchenko/ on line 1684.
  • strict warning: Declaration of views_plugin_display_page::options_submit() should be compatible with views_plugin_display::options_submit(&$form, &$form_state) in /home/artemmarchenko/ on line 457.
  • strict warning: Declaration of views_plugin_display_block::options_submit() should be compatible with views_plugin_display::options_submit(&$form, &$form_state) in /home/artemmarchenko/ on line 184.
  • strict warning: Declaration of views_handler_field_broken::ui_name() should be compatible with views_handler::ui_name($short = false) in /home/artemmarchenko/ on line 243.
  • strict warning: Declaration of views_handler_sort_broken::ui_name() should be compatible with views_handler::ui_name($short = false) in /home/artemmarchenko/ on line 82.
  • strict warning: Declaration of views_handler_filter::options_validate() should be compatible with views_handler::options_validate($form, &$form_state) in /home/artemmarchenko/ on line 584.
  • strict warning: Declaration of views_handler_filter::options_submit() should be compatible with views_handler::options_submit($form, &$form_state) in /home/artemmarchenko/ on line 584.
  • strict warning: Declaration of views_handler_filter_broken::ui_name() should be compatible with views_handler::ui_name($short = false) in /home/artemmarchenko/ on line 608.
  • strict warning: Declaration of views_plugin_row::options_validate() should be compatible with views_plugin::options_validate(&$form, &$form_state) in /home/artemmarchenko/ on line 61.
  • strict warning: Declaration of views_plugin_row::options_submit() should be compatible with views_plugin::options_submit(&$form, &$form_state) in /home/artemmarchenko/ on line 61.

October 11, 2007 by Vaibhav

What is acceptance testing?

Acceptance testing is a black-box testing performed on a software prior to its delivery. It involves running a suite of tests on a completed system (ref: Wikipedia). These test suites are made up of multiple tests or test cases. Each test case consists of a sequence of steps to perform which emulate the use case that is being tested; it also contains input data (if required) as well as the expected output. The result of a test case is either a pass or a fail.


Although acceptance testing traditionally takes place at the end of development or major milestones, in agile software development acceptance testing needs to be performed at the user story level. There are several reasons for why this is important:

  • A passed test case becomes a measure of completeness of a user story; that is, a user story cannot be considered complete till it has passed all acceptance tests associated with it.
  • Even though there is thorough unit testing performed, this is not enough. Unit tests, by their nature, test for a localized used case and are not concerned about the overall system.
  • When we have iterations longer than a couple of weeks, it becomes easy to loose focus on initial agreements; acceptance test cases made for each story at the beginning of each iteration help the developers to keep things within the expectations.
  • Acceptance test cases can serve as an excellent guide to developers to better interpret the requirements from a user story

The Acceptance Test Case

An acceptance test case has the following primary objectives:

  • The Product Owner should be able to verify and validate that the user story has been implemented as it was supposed to.
  • The developers should be able to check if what they have developed is in accordance with the requirements.
  • We do no development that cannot be verified.

An acceptance test case is a human level test which determines whether the product meets the expectations of the end user.


When creating acceptance test cases, the following points (some obvious) should be covered:

  • All scenarios of the User Story should be covered in the test cases, and the expected outcome mentioned so that a tester can verify each function and use case.
  • The acceptance test case needs to be at a broad overview level and not have details such as field validations, etc. because those will be covered by unit test cases.
  • The test cases should precisely define the steps and their sequence that the tester should take; the inputs; and the expected outputs.
  • When testing a non-UI based module, an acceptance test case can be an automated test case which also records the response. This will allow you to examine the output and see if it is acceptable.
  • The acceptance test cases need to be reviewed and approved by the Product Owner in order to ensure that the coverage is complete.

Once test cases are created and approved, they should be given to the developer prior to start of development work. This allows the developers to get better understanding of the requirements as compared to what they might otherwise understand from just the User Story. This implies that the test cases need to be made before the actual development starts.

There are some tools for running these kind of test cases automatically, but it is very common to have a group of testers run these manually. How do you manage acceptance testing? What tools and best practices do you use?

About the Author:


Actually, the test cases

December 18, 2008 by Vaibhav, 7 years 40 weeks ago
Comment id: 2133

Actually, the test cases should be written as soon as we have user stories available. This can be an ongoing exercise as the Product Backlog is filled up.

Even if you don't do that, the developers can 'begin' their work and consult the test case part of the way into their development. It doesn't take too long to write an acceptance test case for a typical story.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.

Best of