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 |
This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||
|
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 beta test, however a beta 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?
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.
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)
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)
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)
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).
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)
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).
This stub seems a bit weak to me. I'm not in the industry, but I doubt that, as purported by the article, the consumer either knows or cares about this testing process. It may be important from the marketing prospective of the company, but the gist here seems to be that the test is used and valued by the end user in general. Is this true? Maybe I'm only thinking about mass market products and this is related to unique, or custom ordered production. If so, I think that detail should be included in the description. --Bookandcoffee 21:04, 16 January 2005 (UTC)
I also disagree with definition of a show stopper. A real show stopper has more to do with process and resources (or lack of them) than with buggy code. A crash is no big deal and happens thousands of times during the development lifecycle. However, trying to integrate with systems that haven't been designed yet, that will really set you back. --66.248.222.242 19:21, 13 June 2006 (UTC)
Reviewing this from a software test perspective, the information appears inaccurate & misleading. It seems to confuse test approaches (eg Black / white box) and types of tests (eg functional tests) with test phases - eg unit, system, user acceptance and operational acceptance which can all employ functional tests. I would rewrite but was unsure whether I should as the article refers to "Engineering disciplines". Is it acceptable for me to rewrite from the software test perspective? ChrisKeiron ( talk) 11:04, 3 June 2008 (UTC)
I have removed a lot of the "citation needed" tags from the first paragraph and replaced them with a single tag after the sentence as I felt the repeated superscript links were making the text difficult to read, and that my solution makes the same point adequately. 62.25.109.195 ( talk) 12:19, 18 February 2009 (UTC)
I cannot help asking for those citations to be re-emphasised. There appears to be a very very specific interpretation of acceptance testing definitions that are certainly not universally accepted. I'm guessing someone with a Microsoft bent. Site acceptance testing is missing and User Acceptance Tests are not necessarily factory tests. Furthermore, software isn't the only thing AT-ed, but systems more completely, such as hardware-software integrated systems. That said, I would prefer to not start re-doing this whole article in favour of my particular experiences. 218.185.60.3 ( talk) 03:58, 2 March 2011 (UTC)
Much of this article relates to systems and software topics. Acceptance testing is a much broader subject and involves many other branches of engineering. Either this article should be given a restrictive title or it should be opened up to other aspects of acceptance testing. Rlsheehan ( talk) 21:54, 30 August 2011 (UTC)
Acceptance Trials of Computer Systems for Government Use (1961) -- 89.25.210.104 ( talk) 23:12, 14 June 2018 (UTC)