Talk:Acceptance testing
This is the talk page for discussing improvements to the Acceptance testing article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Please review and comment or edit.
Rsutherland 07:07, 7 June 2006 (UTC) I don't think these are the same. I design production functional test and test systems all the time, and I consider it to be a black box test method (hardware). For example a functional test is not a bata test, however a bata test may be functional or a white box method. Can we nuke this entire page and start over without trapping all the links to it?
The Reality Is
Rsutherland: All of these terms have been used in lieue of "acceptance test' at one time or other. Any test the sponsor is willing to sign off on is, by definition, an "acceptance test." If you want to add or extend the definition of any of these terms on this or another page, please do so. I see no reason to nuke the definition. You object precisely to— what? In practice, there are no clean definitions of anything— would it were not so! ⇒ normxxx| talk ⇒ email 05:50, 9 June 2006 (UTC)
Rsutherland 16:54, 10 June 2006 (UTC) kk, No nukes! I want to try some more ping's: I have always thought functional test methods were used for all sorts of things from reverse engineering, to checking scientific theory's. Any thoughts on that? I mostly work with electronic hardware (analog, power, and micro-controllers). To test these types of products there is a few consistent methods that may (or not) be nice to have in an encyclopedia, is this a good place?
Stephiee01 18:03, 16 August 2006 (UTC) As this relates to software testing environments, as previously stated, any test that can be used as an official sign off can be considered an acceptance test. Another key point to an acceptance test is that its execution is in a controlled environment, whereas, if a developer was running the same tests on his workstation, it would not be considered as an official sign off. Acceptance tests are typically run against customer/SRS type configurations that have been approved for the release for validation of its ability to run/function correctly in the pre-determined environment(s).
In terms of hardware engineering testing practices, I would add a section to the Acceptance Test page labeled as such, and link it to more relevant pages that talk about hardware engineering testing practices, should any exist.
Merge from User Acceptance Test
I think the two articles are covering the same subject matter. --Chris Pickett 06:09, 4 December 2006 (UTC)
The term "user" was added to acceptance test to differentiate this type of acceptance test from earlier types of acceptance test that did not involve the direct participation of users. In it's purest form, the "user" develops the test scenarios with little or no help from developers before development begins (the coding phases, that is) and the "user" acceptance test is executed by the "users" also with little or no developer intervention. Therefore the term "user" prepended to the term "acceptance test" really does refer to a different method of testing, and not just philosophical either. Bmoscoe 23:08, 20 April 2007 (UTC)
In our corporate environment there are three kinds of acceptance tests - UAT, OAT and RAT. User Acceptance Testing you know. Operational Acceptance Testing is testing by the various different production support teams (Databases, Storage, Platforms, etc. etc.) that the system works with the DR solution, doesn't violate the security model, etc. Release Acceptance Testing is as below - i.e. that the release will deploy (and backout) without error or damage to the current production system. Helvetius 15:43, 14 May 2007 (UTC)
- UATs are a different concept from Acceptance tests. --Walter Görlitz 03:17, 15 May 2007 (UTC)
ITIL Uses the term Release Acceptance
Release Acceptance -- ( a sub process of Release Management) -- The Activity responsible for testing a Release, and its implementation and Back-out Plans, to ensure they meet the agreed Business and IT Operations Requirements. --Liftoph 22:53, 4 December 2006 (UTC)
- So go ahead and edit the main page to document this. I think the best name for the article is actually Acceptance testing, since it is in line with unit testing, integration testing, and system testing. (Unit testing is just a redirect to unit test at the moment.) --Chris Pickett 23:06, 4 December 2006 (UTC)
Mechanical, Chemical Engineering etc. may have product lots/batches that need acceptance testing
426 Reliability. (Crosslisted with Stat) Irr.; 3 cr (N-A). Engineering reliability, analysis of failure data, esti-mates of hazard rates and failure distributions for the reliability of components and/or systems, acceptance sampling plans for quality control. P: Stat 224 or cons inst. Reference: http://www.wisc.edu/pubs/ug/07engineering/mecheng.html --Liftoph 00:12, 5 December 2006 (UTC)
- Sure, but it's still black box testing; maybe the black box testing page needs fixing. Also, can you put the citation in the article? --Chris Pickett 00:34, 5 December 2006 (UTC)
future scope
what is the future scope for acceptance testing? —The preceding unsigned comment was added by 61.95.167.91 (talk) 04:41, 16 January 2007 (UTC).
Functional tests
I was trying to figure out what the differences between a "unit test" and a "functional test" (in the context of software engineering) were and was redirected here, to Acceptance Testing. It appears that the answer is that a unit test is for testing an object sans environment, while a functional test tests the object within its environment. Within the context of software engineering at least, it would appear that "functional tests" should not be equated with "acceptance testing" as one in the same. Inanutshellus 21:59, 24 January 2007 (UTC)
DataWare House Testing
Any one help me to create test senorios,Test cases for UAT in DataWare House testing. —The preceding unsigned comment was added by 203.99.195.2 (talk) 05:35, 26 February 2007 (UTC).