Acceptance testing

related topics
{system, computer, user}
{company, market, business}
{rate, high, increase}
{law, state, case}
{math, number, function}
{disease, patient, cell}
{film, series, show}
{group, member, jewish}
{service, military, aircraft}
{car, race, vehicle}
{game, team, player}

In engineering and its various subdisciplines, acceptance testing is black-box testing performed on a system (for example: a piece of software, lots of manufactured mechanical parts, or batches of chemical products) prior to its delivery.[1] It is also known as functional testing, black-box testing, QA testing, application testing, confidence testing, final testing, validation testing, or factory acceptance testing.[citation needed]

Software developers often distinguish acceptance testing by the system provider from acceptance testing by the customer (the user or client) prior to accepting transfer of ownership. In the case of software, acceptance testing performed by the customer is known as user acceptance testing (UAT), end-user testing, site (acceptance) testing, or field (acceptance) testing.

A smoke test is used as an acceptance test prior to introducing a build to the main testing process.



Acceptance testing generally involves running a suite of tests on the completed system. Each individual test, known as a case, exercises a particular operating condition of the user's environment or feature of the system, and will result in a pass or fail, or boolean, outcome. There is generally no degree of success or failure. The test environment is usually designed to be identical, or as close as possible, to the anticipated user's environment, including extremes of such. These test cases must each be accompanied by test case input data or a formal description of the operational activities (or both) to be performed—intended to thoroughly exercise the specific case—and a formal description of the expected results.

Acceptance Tests/Criteria (in Agile Software Development) are usually created by business customers and expressed in a business domain language. These are high-level tests to test the completeness of a user story or stories 'played' during any sprint/iteration. These tests are created ideally through collaboration between business customers, business analysts, testers and developers, however the business customers (product owners) are the primary owners of these tests. As the user stories pass their acceptance criteria, the business owners can be sure of the fact that the developers are progressing in the right direction about how the application was envisaged to work and so it's essential that these tests include both business logic tests as well as UI validation elements (if need be).

Full article ▸

related documents
Poqet PC
Internet service provider
Atari Lynx
Timeline of computing 1990–present
Free Lossless Audio Codec
Meiko Scientific
Grade of service
Non-Uniform Memory Access
Unisys ICON
IBM Systems Network Architecture
Mac OS X Server
Dragon 32/64
Apache HTTP Server
Direct distance dialing
Disk storage
Java Platform, Micro Edition