What is the difference between Functionality Test and Acceptance Test?

Some say it might be the same, but it’s not!


functional testing: This is a verification activity; did we build the thing right? Does the software meet the business requirements?

For this type of testing we have test cases that cover all the possible scenarios we can think of, even if that scenario is unlikely to exist “in the real world”. When doing this type of testing, we aim for maximum code coverage. We use any test environment we can grab at the time, it doesn’t have to be “production” caliber, so long as it’s usable.

acceptance testing: This is a validation activity; did we build the right thing? Is this what the customer really needs?

This is usually done in cooperation with the customer, or by an internal customer proxy (product owner). For this type of testing we use test cases that cover the typical scenarios under which we expect the software to be used. This test must be conducted in a “production-like” environment, on hardware that is the same as, or close to, what a customer will use. This is when we test our “ilities”:

  • Reliability, Availability: Validated via a stress test.
  • Scalabilitiy: Validated via a load test.
  • Usability: Validated via an inspection and demonstration to the customer. Is the UI configured to their liking? Did we put the customer branding in all the right places? Do we have all the fields/screens they asked for?
  • Security (aka, Securability, just to fit in): Validated via demonstration. Sometimes a customer will hire an outside firm to do a security audit and/or intrusion testing.
  • Maintainability: Validated via demonstration of how we will deliver software updates/patches.
  • Configurability: Validated via demonstration of how the customer can modify the system to suit their needs.


    Other explanation..

    functional-testing: take the business requirements and test all of it good and thorougly from a functional viewpoint.

    acceptance-testing: the “paying” customer does the testing he likes to do so that he can accept the product delivered. It depends on the customer but usually the tests are not as thorough as the functional-testing especially if it is an in-house project because the stakeholders review and trust the test results done in earlier test phases


    If we differ them based on Audience and Scope, then:

    1. Audience. Functional testing is to assure members of the team producing the software that it does what they expect. Acceptance testing is to assure the consumer that it meets their needs.
    2. Scope. Functional testing only tests the functionality of one component at a time. Acceptance testing covers any aspect of the product that matters to the consumer enough to test before accepting the software (i.e., anything worth the time or money it will take to test it to determine its acceptability).

    Software can pass functional testing, integration testing, and system testing; only to fail acceptance tests when the customer discovers that the features just don’t meet their needs. This would usually imply that someone screwed up on the spec. Software could also fail some functional tests, but pass acceptance testing because the customer is willing to deal with some functional bugs as long as the software does the core things they need acceptably well (beta software will often be accepted by a subset of users before it is completely functional).


    Based on Wikipedia:

    Acceptance Testing:

    … is black-box testing performed on a system (e.g. software, lots of manufactured mechanical parts, or batches of chemical products) prior to its delivery.

    Though this goes on to say:

    It is also known as functional testing, black-box testing, release acceptance, QA testing, application testing, confidence testing, final testing, validation testing, or factory acceptance testing

    with a “citation needed” mark.

    Functional Testing  (which actually redirects to System Testing):

    conducted on a complete, integrated system to evaluate the system’s compliance with its specified requirements. System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic.

    So from this definition they are pretty much the same thing.

    In some experience acceptance test are usually a subset of the functional tests and are used in the formal sign off process by the customer while functional/system tests will be those run by the developer/QA department


    The functional test confirms the software performs a function within the boundaries of how you’ve solved the problem. This is an integral part of developing software, comparable to the testing that is done on mass produced product before it leaves the factory. A functional test verifies that the product actually works as you (the developer) think it does.

    Acceptance tests verify the product actually solves the problem it was made to solve. This can best be done by the user (customer), for instance performing his/her tasks that the software assists with. If the software passes this real world test, it’s accepted to replace the previous solution. This acceptance test can sometimes only be done properly in production, especially if you have anonymous customers (e.g. a website). Thus a new feature will only be accepted after days or weeks of use.

    Functional testing – test the product, verifying that it has the qualities you’ve designed or build (functions, speed, errors, consistency, etc.)

    Acceptance testing – test the product in its context, this requires (simulation of) human interaction, test it has the desired effect on the original problem(s).


    This all answer is different, based on what you really need in the field, based on your application or product, or what you’ve been developing. And the most important here is about Acceptance test, it’s all based on customer/client requirements. Many clients have different requirement, so we can’t generate same thing for different situation and clients.

    Hope this article could help!

    collected from several sources.