Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I heard that system testing has two types
1)functional Testing
2)Non functional testing
But later in another website i have seen below statements
In the types of functional testing following testing types should be cover:
Unit Testing
Smoke testing
Sanity testing
Integration Testing
Interface Testing
System Testing
Regression Testing
UAT
I am confused, Please clarify me that whether the system testing includes functional or functional testing includes system testing and the sequence of these testings(functional is performed first or system)
Thanks
Functional testing aims to figure out whether given functionality works as specified. System testing aims to figure out whether the whole system fulfills the requirements given to it.
So in functional testing you test that given part of the whole system functions in a specified way. And in system testing you test the system as a whole fulfills the requirements given to it.
For example testing that 1+1=2 tests the plus function and sum function. And thus is a functional test. Testing whether user can calculate correct amount of tip using the calculator or not, is a system test, since it tests a requirement (calculate tip), but not a specific function of the application.
And non-functional testing includes stuff like usability and performance.
Functional testing are based on an analysis of requirements specification of a component or system.
Non-functional testing includes, but is not limited to, performance testing, load testing, stress testing, usability testing, maintainability,reliability, portability. It is the testing o how the system works.
You can call System Testing as a level of Test, instead Functional Testing is a Test Type. And System testing should investigate functional a non-functional areas of the system.
You could find more information on this subject if you read for example "ISQTB - Foundation Level Syllabus".
Non-functional testing would include, for example, performance testing - something unrelated to the actual business requirement.
Functional testing tests the business requirements.
Sometimes there is an overlap between the two.
System Testing includes both Function testing as well as non Function Testing
Functional and non functional testing is done for a particular portion or is done step by step which becomes System testing.
Functional Testing : are based on an Requirement Specification. while you check application as per flow and if u find any bug for that flow then it will functional testing.
System Testing : are test whole application.
Unit Testing : One individual parts of an application, called units, are individually and independently scrutinized for proper operation.
Regression testing : while Dev team change any module and then module not effect another module that is Regression testing.
System testing is a combination of both functional and non-functional testing.
Functional testing, in simple terms, tests the functionality of whether an application is working to requirements or not. (smoke, sanity, retesting, regression, priority based testing, riskbased testing etc.)
Non-functional tests evaluate the non functional parts such as performance, load, stress, volume, usability(userfriendliness), look and feel etc.
Functinal testing comes under System testing (which checks the overall end to end flow of an application).
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
In the context of Agile software development, what's the difference between User Acceptance Test (UAT), Test Case Scenario and Functional Test?
The members of the team I am part of, they consider the three things as different, but I see them as exactly the same thing.
In fact, all of them are designed having the end user in mind
There's a lot of different sorts of testing. Many of them overlap. Many use the same tools. Many are specializations of other more general terms. Often they blur together. People argue about the terminology all the time.
You're correct that they all have the end user in mind, but they are different.
User Acceptance Test
This is a specific form of an acceptance test where a subject-matter expert, ideally the client or their representative, tests the software. This is in addition to functional and acceptance testing done by QA. It's designed to simulate, as closely as possible, an actual end-user using the software; the tester is asked to perform a bunch of common tasks with the new system, but not given specific instructions nor coaching on how to do it.
For example, if you were creating a site for an airline, they might be asked to register, login, book a flight, make a payment, check in, check their flight status, and so on.
Functional Test
This is blackbox testing done by the QA role. It verifies the thing does what it's supposed to do; you give it inputs, you check the outputs. Typically this is testing against the specification and/or requirements document.
"Functional" here doesn't refer to code functions, but that the system functions as expected. Testing specific functions is unit testing.
They can be purely functional, "when I do X I get Y". They can be about resource use, "when I do X it uses no more than Y memory/time". Or about error checking, "when I give it garbage I get a well formed error". Anything that validates it meets the requirements.
Test Case Scenario
Sounds like Scenario Testing: this uses stories, similar to user stories, that help a tester work through a complicated testing scenario. Scenario testing tests complicated combinations of things which might arise during actual use and often cut across multiple systems.
An example of a test scenario might be: "in the middle of processing the system runs out of disk space; verify an admin is notified, that processing resumes once space is cleared, and that no data is lost".
A User Acceptance Test might use Scenario Testing.
These are my rules of thumb:
Unit testing: does this one function work?
Integration testing: do the functions work together?
Functional testing: does it function as required?
Acceptance testing: is it acceptable to the client?
Regression testing: does it still work like it used to?
User Acceptance Testing is having business users trying out your app.
There is also an Acceptance Testing done by QA when they check the new functionality - you can call it a Story Acceptance Testing to distinguish between these. These are not necessarily Functional Tests (could be Security, Performance testing, etc.).
Test Case is a number of steps to check a small piece of functionality. It has Prerequisites, Steps, Expected Result, Actual Result. This is one of the ways of carrying out Functional Testing. Others could be: exploratory testing, checklists.
Test Scenario - steps that cover a bigger picture. Often they cover cases of how real users would use the app. But these are carried out by QA team.
Functional Test - a test that checks the functionality as opposed to e.g. Performance. This can be a unit test as well, but since this terminology is mostly used by QA - when people talk about them they usually mean Functional System Test.
Note, that different authorities may use different definitions of the same terms. Check out Holes in testing terminology: Test Types and Test Levels. Since it's impossible to find the one true terminology it's more important that you use terms consistently within your team even if they are used differently in other companies and teams.
User acceptance testing is a process that obtains confirmation that a system meets agreed customer/product manager requirements.
Functional Testing is actual functionality test of the software there can be many different types of testing but in simple word testing the functionality what is should be expected.
The test scenario is the high level of testing cases when the first classification of module testing then module dividing into a scenario and at last small and specifical test steps with expected result says test cases, so the test scenario is group test cases with limited to specific functionality and module.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
A few years ago I saw this great (PDF) document from Google. The document explained, in a single page, what all the various types of software testing mean (eg. what separates a functional test from an integration test from a unit test from a ...). It was a very handy reference, but of course I didn't save a link to it, and now I can't find it when I google for it (oh the irony of not being able to google a Google document).
Now I know there are great SO answers for exactly this question, but I was specifically looking for a single-page, print-formatted guide that I could hang in the office, rather than an SO answer.
Can anyone point me to either the Google document I'm thinking of, or any other good single-page breakdown of software testing types?
Software Testing Types
Software testing life cycle is the process that explains the flow of the tests that are to be carried on each product. The V- Model i.e Verification and Validation Model is a perfect model which is used in the improvement of the software project. This model contains software development life cycle on one side and software testing life cycle on the other hand side. The checklists for software tester sets a baseline that guides him to carry on the day-to-day activities.
Black Box Testing: It explains the process of giving the input to the system and checking the output, without considering how the system generates the output. It is also known as Behavioral Testing.
Functional Testing: The software is tested for the functional requirements. This checks whether the application is behaving according to the specification.
Performance Testing: This testing checks whether the system is performing properly, according to the user's requirements. Performance testing depends upon the Load and Stress Testing, that is internally or externally applied to the system.
Load Testing: In this type of performance testing, the system is raised beyond the limits in order to check the performance of the system when higher loads are applied.
Stress Testing: In this type of performance testing, the system is tested beyond the normal expectations or operational capacity.
Usability Testing: This is also known as 'Testing for User Friendliness'. It checks the ease of use of an application.
Regression Testing: Regression testing is one of the most important types of testing, which checks whether a small change in any component of the application affects the unchanged components or not. This is done by re-executing the previous versions of the application.
Smoke Testing: It is used to check the testability of the application, and is also called 'Build Verification Testing or Link Testing'. That means, it checks whether the application is ready for further testing and working, without dealing with the finer details.
Sanity Testing: Sanity testing checks for the behavior of the system. This is also called Narrow Regression Testing.
Parallel Testing: Parallel testing is done by comparing results from two different systems like old vs new or manual vs automated.
Recovery Testing: Recovery testing is very necessary to check how fast the system is able to recover against any hardware failure, catastrophic problems or any type of system crash.
Installation Testing: This type of software testing identifies the ways in which installation procedure leads to incorrect results.
Compatibility Testing: Compatibility testing determines if an application under supported configurations performs as expected, with various combinations of hardware and software packages.
Configuration Testing: This testing is done to test for compatibility issues. It determines minimal and optimal configuration of hardware and software, and determines the effect of adding or modifying resources such as memory, disk drives, and CPU.
Compliance Testing: This checks whether the system was developed in accordance with standards, procedures, and guidelines.
Error-Handling Testing: This determines the ability of the system to properly process erroneous transactions.
Manual-Support Testing: This type of software testing is an interface between people and application system.
Inter-Systems Testing: This method is an interface between two or more application systems.
Exploratory Testing: Exploratory testing is similar to ad-hoc testing, and is performed to explore the software features.
Volume Testing: This testing is done when huge amount of data is processed through the application.
Scenario Testing: Scenario testing provides a more realistic and meaningful combination of functions, rather than artificial combinations that are obtained through domain or combinatorial test design.
User Interface Testing: This type of testing is performed to check, how user-friendly the application is. The user should be able to use the application, without any assistance by the system personnel.
System Testing: This testing conducted on a complete, integrated system, to evaluate the system's compliance with the specified requirements. This is done to check if the system meets its functional and non-functional requirements and is also intended to test beyond the bounds defined in the software / hardware requirement specifications.
User Acceptance Testing: Acceptance testing is performed to verify that the product is acceptable to the customer and if it's fulfilling the specified requirements of that customer. This testing includes Alpha and Beta testing.
Alpha Testing: Alpha testing is performed at the developer's site by the customer in a closed environment. This is done after the system testing.
Beta Testing: This is done at the customer's site by the customer in the open environment. The presence of the developer, while performing these tests, is not mandatory. This is considered to be the last step in the software development life cycle as the product is almost ready.
White Box Testing: It is the process of giving the input to the system and checking, how the system processes the input to generate the output. It is mandatory for a tester to have the knowledge of the source code.
Unit Testing: Unit testing is done at the developer's site to check whether a particular piece / unit of code is working fine. It tests the unit of the program as a whole.
Static and Dynamic Analysis: In static analysis, it is required to go through the code in order to find out any possible defect in the code. Whereas, in dynamic analysis, the code is executed and analyzed for the output.
Statement Coverage: It assures that the code is executed in such a way that every statement of the application is executed at least once.
Decision Coverage: This helps in making decision by executing the application, at least once to judge whether it results in true or false.
Condition Coverage: In this type of software testing, each and every condition is executed by making it true and false, in each of the ways, at least once.
Path Coverage: Each and every path within the code is executed at least once to get a full path coverage, which is one of the important parts of the white box testing.
Integration Testing: Integration testing is performed when various modules are integrated with each other to form a sub-system or a system. This mostly focuses in the design and construction of the software architecture. This is further classified into Bottom-Up Integration and Top-Down Integration testing.
Bottom-Up Integration Testing: Here the lowest level components are tested first and then the testing of higher level components is done using 'Drivers'. The entire process is repeated till the time all the higher level components are tested.
Top-Down Integration Testing: This is totally opposite to bottom-up approach, as it tests the top level modules and the branch of the modules are tested step by step using 'Stubs', until the related module comes to an end.
Security Testing: Testing that confirms, how well a system protects itself against unauthorized internal or external, or willful damage of code; means security testing of the system. Security testing assures that the program is accessed by the authorized personnel only.
Mutation Testing: In mutation testing, the application is tested for the code that was modified after fixing a particular bug/defect.
use the following link for getting the printed format
Types of Software Testing
May be following can help you.
http://www.kostcare.com/pdf/Testing%20at%20Different%20Phase%20of%20Software%20Development%20Life%20Cycle.pdf
http://ijcsi.org/papers/7-3-1-11-16.pdf
http://www.softwaretestinghelp.com/types-of-software-testing/
http://rajeevprabhakaran.wordpress.com/2008/11/20/different-types-of-testing/
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 4 years ago.
Improve this question
What is exactly PAT, When we will do the pre acceptance testing?
I don't think it's a widely-used term or part of a standard. Therefore, what exactly it means is organization-specific and should be defined in a glossary somewhere. More likely though you'll just have to ask people what it means.
Any testing done before acceptance testing.
This would include:
Unit tests
Stress tests
Integration tests
Performance tests
There's no standardised meaning for the term - often it depends on your process- be it Agile or Extreme Programming etc.
Generally however, there are a number of tests done by developers or testing in a developer test environment. This can be unit tests, developer tests, sanity regression tests, performance tests - ie tests that the QA team wants done before they'll even look at it. At a bare minimum, it might be just testing that the software builds (although it's frightening how often I've had a developer fail to even check this).
Well I would like to share something which everyone may not agree to but this is what I feel Pre-Acceptance testing would be:
The testing done to perform that the system under test functions as per the designed requirements to cover the customer's business areas before entering the User Acceptance Test phase where users from the customer's side are invited to perform the testing at the vendor's location where development team assistance is available when any flaw occurs in the expected business flow. This will be called as Alpha Test. Please feel free to correct me if I have said something wrong.
Acceptance testing is a testing technique performed to determine whether or not the software system has met the requirement specifications. In SDLC, acceptance testing fit as follows:
Requirement Analysis - Acceptance Testing
High Level Design - System Testing
Low Level Design - Integration Testing
Coding - Unit Testing
Simply put, PAT is any test done before acceptance testing. There are various forms of acceptance testing such as User acceptance testing, business acceptance testing, alpha testing and beta testing.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
The community reviewed whether to reopen this question 6 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
Are functional testing and integration testing the same?
You begin your testing through unit testing, then after completing unit testing you go for integration testing where you test the system as a whole. Is functional testing the same as integration testing? You still taking the system as a whole and testing it for functionality conformance.
Integration testing is when you test more than one component and how they function together. For instance, how another system interacts with your system, or the database interacts with your data abstraction layer. Usually, this requires a fully installed system, although in its purest forms it does not.
Functional testing is when you test the system against the functional requirements of the product. Product/Project management usually writes these up and QA formalizes the process of what a user should see and experience, and what the end result of those processes should be. Depending on the product, this can be automated or not.
Functional Testing:
Yes, we are testing the product or software as a whole functionally whether it is functionally working properly or not (testing buttons, links etc.)
For example: Login page.
you provide the username and password, you test whether it is taking you to home page or not.
Integration Testing:
Yes, you test the integrated software only but you test where the data flow is happening and is there any changes happening in the database.
For example: Sending e-mail
You send one mail to someone, there is a data flow and also change in database (the sent table increases value by 1)
Remember - clicking links and images is not integration testing. Hope you understood why, because there is no change in database by just clicking on a link.
Hope this helped you.
Functional Testing: It is a process of testing where each and every component of the module is tested. Eg: If a web page contains text field, radio botton, Buttons and Drop down etc components needed to be checked.
Integration Testing: Process where the dataflow between 2 modules are checked.
This is an important distinction, but unfortunately you will never find agreement. The problem is that most developers define these from their own point of view. It's very similar to the debate over Pluto. (If it were closer to the Sun, would it be a planet?)
Unit testing is easy to define. It tests the CUT (Code Under Test) and nothing else. (Well, as little else as possible.) That means mocks, fakes, and fixtures.
At the other end of the spectrum there is what many people call system integration testing. That's testing as much as possible, but still looking for bugs in your own CUT.
But what about the vast expanse between?
For example, what if you test just a little bit more than the CUT? What if you include a Fibonacci function, instead of using a fixture which you had injected? I would call that functional testing, but the world disagrees with me.
What if you include time() or rand()? Or what if you call http://google.com? I would call that system testing, but again, I am alone.
Why does this matter? Because system-tests are unreliable. They are necessary, but they will sometimes fail for reasons beyond your control. On the other hand, functional tests should always pass, not fail randomly; if they are fast, they might as well be used from the start in order to use Test-Driven Development without writing too many tests for your internal implementation. In other words, I think that unit-tests can be more trouble than they are worth, and I have good company.
I put tests on 3 axes, with all their zeroes at unit-testing:
Functional-testing: using real code deeper and deeper down your call-stack.
Integration-testing: higher and higher up your call-stack; in other words, testing your CUT by running the code which would use it.
System-testing: more and more unrepeatable operations (O/S scheduler, clock, network, etc.)
A test can easily be all 3, to varying degrees.
I would say that both are tightly linked to each other and very tough to distinguish between them.
In my view, Integration testing is a subset of functional testing.
Functionality testing is based on the initial requirements you receive. You will test the application behaviour is as expected with the requirements.
When it comes to integration testing, it is the interaction between modules. If A module sends an input, B module able to process it or not.
Integration testing - Integration testing is nothing but the testing of different modules. You have to test relationship between modules. For ex you open facebook then you see login page after entering login id and password you can see home page of facebook hence login page is one module and home page is another module. you have to check only relationship between them means when you logged in then only home page must be open not message box or anything else. There are 2 main types of integration testing TOP-DOWN approach and BOTTOM UP approach.
Functional Testing - In functional testing you have to only think about input and output. In this case you have to think like a actual user. Testing of What input you gave and what output you got is Functional testing. you have to only observe output. In functional testing you don't need to test coding of application or software.
In a Functional testing tester focuses only Functionality and sub functionality of application. Functionality of app should be working properly or not.
In integration testing tester have to check dependency between modules or sub-modules.Example for modules records should be fetching and displayed correctly in another module.
Integration Test:-
When Unit testing is done and issues are resolved to the related components then all the required components need to integrate under the one system so that it can perform an operation.
After combining the components of the system,To test that whether the system is working properly or not,this kind of testing is called as Integration Testing.
Functional Testing:-
The Testing is mainly divided into two categories as
1.Functional Testing
2.Non-Functional Testing
**Functional Testing:-
To test that whether the software is working according to the requirements of the user or not.
**Non-Functional Testing:-
To test that whether the software satisfies the quality criteria like Stress Test,Security test etc.
Usually,Customer will provide the requirements for Functional Test only and for Non Functional test,Requirements should not be mentioned but the application necessarily perform those activity.
Integration testing It can be seen as how the different modules of the system work together.
We mostly refers to the integrated functionality of the different modules, rather different components of the system.
For any system or software product to work efficiently, every component has to be in sync with each other.
Most of the time tool we used for integration testing will be chosen that we used for unit testing.
It is used in complex situations, when unit testing proves to be insufficient to test the system.
Functional Testing
It can be defined as testing the individual functionality of modules.
It refers to testing the software product at an individual level, to check its functionality.
Test cases are developed to check the software for expected and unexpected results.
This type of testing is carried out more from a user perspective. That is to say, it considers the expectation of the user for a type of input.
It is also referred as black-box testing as well as close-box testing
Checking the functionality of the application is generally known as functional testing, where as the integration testing is to check the flow of data from one module to other.
Lets take example of money transfer app.Suppose we have page in which we enter all the credentials and if we press transfer button and after that if we getting any success, Then this is functional testing. But in same example if we verify the amount transfer then it is integration testing.
Authors diverge a lot on this. I don't believe there is "the" correct interpretation for this. It really depends.
For example: most Rails developers consider unit tests as model tests, functional tests as controller tests and integration tests as those using something like Capybara to explore the application from a final user's perspective - that is, navigating through the page's generated HTML, using the DOM to check for expectations.
There is also acceptance tests, which in turn are a "live" documentation of the system (usually they use Gherkin to make it possible to write those in natural language), describing all of the application's features through multiple scenarios, which are in turn automated by a developer. Those, IMHO, could be also considered as both, functional tests and integration tests.
Once you understand the key concept behind each of those, you get to be more flexible regarding the right or wrong. So, again IMHO, a functional test could also be considered an integration test. For the integration test, depending on the kind of integration it's exercising, it may not be considerate a functional test - but you generally have some requirements in mind when you are writing an integration test, so most of the time it can be also considerate as a functional test.
What is the real difference between acceptance tests and functional tests?
What are the highlights or aims of each? Everywhere I read they are ambiguously similar.
In my world, we use the terms as follows:
functional testing: This is a verification activity; did we build a correctly working product? 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.
Scalability: 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.
This is by no means standard, and I don't think there is a "standard" definition, as the conflicting answers here demonstrate. The most important thing for your organization is that you define these terms precisely, and stick to them.
I like the answer of Patrick Cuff. What I like to add is the distinction between a test level and a test type which was for me an eye opener.
test levels
Test level is easy to explain using V-model, an example:
Each test level has its corresponding development level. It has a typical time characteristic, they're executed at certain phase in the development life cycle.
component/unit testing => verifying detailed design
component/unit integration testing => verifying global design
system testing => verifying system requirements
system integration testing => verifying system requirements
acceptance testing => validating user requirements
test types
A test type is a characteristics, it focuses on a specific test objective. Test types emphasize your quality aspects, also known as technical or non-functional aspects. Test types can be executed at any test level. I like to use as test types the quality characteristics mentioned in ISO/IEC 25010:2011.
functional testing
reliability testing
performance testing
operability testing
security testing
compatibility testing
maintainability testing
transferability testing
To make it complete. There's also something called regression testing. This an extra classification next to test level and test type. A regression test is a test you want to repeat because it touches something critical in your product. It's in fact a subset of tests you defined for each test level. If a there's a small bug fix in your product, one doesn't always have the time to repeat all tests. Regression testing is an answer to that.
The difference is between testing the problem and the solution. Software is a solution to a problem, both can be tested.
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).
The answer is opinion. I worked in a lot of projects and being testmanager and issuemanager and all different roles and the descriptions in various books differ so here is my variation:
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.
As I said this is my viewpoint and experience. The functional-testing is systematic and the acceptance-testing is rather the business department testing the thing.
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.
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).
Functional Testing: Application of test data derived from the specified functional
requirements without regard to the final program structure. Also known as
black-box testing.
Acceptance Testing: Formal testing conducted to determine whether or not a system satisfies its acceptance criteria—enables an end user to determine whether or not to
accept the system.
In my view the main difference is who says if the tests succeed or fail.
A functional test tests that the system meets predefined requirements. It is carried out and checked by the people responsible for developing the system.
An acceptance test is signed off by the users. Ideally the users will say what they want to test but in practice it is likely to be a sunset of a functional test as users don't invest enough time. Note that this view is from the business users I deal with other sets of users e.g. aviation and other safety critical might well not have this difference,
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 my 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.
Acceptance testing is just testing carried out by the client, and includes other kinds of testing:
Functional testing: "this button doesn't work"
Non-functional testing: "this page works but is too slow"
For functional testing vs non-functional testing (their subtypes) - see my answer to this SO question.
The relationship between the two:
Acceptance test usually includes functional testing, but it may include additional tests. For example checking the labeling/documentation requirements.
Functional testing is when the product under test is placed into a test environment which can produce variety of stimulation (within the scope of the test) what the target environment typically produces or even beyond, while examining the response of the device under test.
For a physical product (not software) there are two major kind of Acceptance tests: design tests and manufacturing tests. Design tests typically use large number of product samples, which have passed manufacturing test. Different consumers may test the design different ways.
Acceptance tests are referred as verification when design is tested against product specification, and acceptance tests are referred as validation, when the product is placed in the consumer's real environment.
They are the same thing.
Acceptance testing is performed on the completed system in as identical as possible to the real production/deployement environment before the system is deployed or delivered.
You can do acceptance testing in an automated manner, or manually.