I’ve seen the wikipedia article but it seems a bit technical. What exactly is user acceptance testing and why do we need it?
Geeks who create systems and geeks who implement them should quite good at testing the technical aspects of a system, but aren’t necessarily all that good at testing whether a system works well in real-world scenarios - because they are unlikely to be as intimately familiar with the ins and outs of those scenarios - so it’s necessary to get representatives of the users to test and verify that the system does in fact do what they want it to, the way they want it to, not just on paper.
You basically get a number of test subjects to try out your software, and then look for signs of frustration. A lot of it is “how many clicks does it take to get from X to Y”, “can the user figure out how to do Z”, etc. It’s not technical at all, but when it gets written up it’s full of jargon trying to make it sound like only an expert can do it.
When you are implementing a change to a process, the developer is only inclined to test with a very narrow focus the area that has been changed. To locate any unintended features introduced by the change it is necessary for someone who uses the process day to day to have a run through, ensuring that a) the change requested has been successfully implemented & b) that the process still works end to end.
You don’t want to work in an environemtn where errors are discovered on the production system and dealt with as an emergency on the fly.
To go slightly further with this, I work with SAP. As is standard practice we have 3 servers
a development server
this is where coding and configuration changes are prototyped to meet the requirement. The developer would do some basic testing to be sure things work as intended.
Once this step is complete the changes would be promoted to
The integration server
This is where you get a real user of the process impacted by the change to test that all is well, both with the change and the surrounding functionality.
Once user sign off is achieved the changes are then promoted to
The productive system
The reason for all this is to minimise crashes of tyhe productive system, which cost the business time and money.
So is User Acceptance Testing the same as “Acceptance Testing?”
Haven’t really heard the term minus the word User, but I would guess so. Testing by the developer is Unit testing, by the user is Acceptance testing.
UAT is just elaborate version of “customer approval process.”
For example, you could have a tailor custom design and sew a suit jacket & slacks or evening gown. Before you pay, you go in for final fitting to make sure everything looks right. This is “user acceptance testing.”
Or you remodel your house and you hire a contractor to install a new door. Before you pay the invoice, you test out the door… open it, close it, play with the locks, etc. If you’re satisfied (“user acceptance tested”), you pay.
In the business world, we have a tendency to use fancier terminology because the contracts are million$ of dollars to install a complicated system (software to run company payroll) involving coordination of more people.
(There’s an unwritten rule: The more money involved, the more syllables are required in the terminology. Since govt contracts are billions of $$$ instead of millions, I’m guessing they have jargon with more syllables than UAT. :p)
That’s because it’s typical consultant-speak mumbo jumbo. If you can write like that, you’re prime material for six-figure salaries.
Your example are helpful. I notice that the real problem with the wikipedia article, other than the jargon, is that I don’t see a single example provided of “UAT” being used in real life; without examples, there is no context and nobody can truly understand a word of it.
How ironic; the article on user acceptance testing itself lacks it.
“Acceptance Testing” is one of those broad brush strokes. The nature of the “acceptance test” is spelled out in the project or process document, and can be (for example):
-
QA Acceptance. That is, a set of tests that the software has to pass before being considered for further testing. This is sometimes called a “smoke test”, from the days of electrical/electronic engineering when you would look to see if the device was on fire when you first turned it on.
-
User Acceptance. This is a set of tests on some major chunk of the product to verify that the user can use it for the intended purpose. These tests are typically performed by representatives of the end user community, rather than software engineers. These testers work closely with the engineering department. User Acceptance Testing is done with a small number of users who are domain experts in the field for which the tool was written.
Example: Imagine some software that schedules news snippets on a website. That is, some lucky editor-type person picks several short blurbs from a list, and using my software, determines which story will be shown when and in what order.
I write the code and perform unit testing on it (do the bits work?).
Someone runs the code through the QA Acceptance Test (which includes things like “have the unit tests been run?” and tests the basic functionality (“is there enough here to test?”)
QA then runs their suite of integration and system tests – does my software work, does it break other things… does the system do what it was meant to?
In parallel with this testing, but slightly delayed, we run User Acceptance Testing. A bunch of actual editors (who have used the old tools or who have done the job some other way) sit down with this new piece of software and try it. They want to see if they can use the tool to do their job – regardless of how “good” it is as a piece of engineering, can you use the tool to pick blurbs, sequence them, resequence them… do you have the information you need, does it make life easier? Or do you find yourself writing on Post-Its and entering data repeatedly???
I work for a large software company (no, not that one) and we do a lot of hiring/interviewing. Recently we were rolling out a new tool to aid in tracking recruiting, interviewing, hiring etc of candidates.
I was one of the User Acceptance Testers. We were given access to a test version of the tool, with much dummy data. I had to use this new tool to:
- open a new job requisition and get it approved
- identify which of several candidates in the pack were of interest to me
- work with an HR specialist to schedule phone screens
- record data from the phone-screen
- view feedback from other managers on this candidate
- dispose of the candidate (recommend for interview, reject, pass off to another group)
- track what had happened to “my” candidates.
We (a small subset of the people who do this work) spent about a month using this tool for an hour or so a day, keeping track of what was happening and where we were. We did find the occasional bug (“I couldn’t enter an international phone number”, “my list of candidates is missing three of them”…) but our added value was in reporting how well the tool performed in day-to-day work, and how well it compared to what we were doing before.
After a User Acceptance Test, the tool was reworked a little and then opened up to a wider audience (a “Beta Test”) with live data.
If you find the article confusing or lacking context, leave a message on its talk page. Wikipedia is written collaboratively by a large community of editors. Eventually someone with the requisite knowledge and writing skills should come across your comment and try to fix the article.
Note that in the IT world - users exist to put a test load on the system.
I’ve been in software testing for over a decade now. I’ve found that testing terminology differs from company to company. So what I outline here may not jive with what other people think.
That said:
Sub-System Testing - usually used for large complex systems. There is usually a group of developers working on small part of a large program, for example, one team at MS might just work on the UI. They don’t care about file systems, kernels, protocols or anything like that. Their testing group would be similarly focused on that one area of the application.
Integration Testing - If you have a bunch of sub systems developed individually, you need to make sure they all play well together before putting the app through its paces.
Smoke Testing (sometimes called Sanity Testing, making sure the software didn’t do anything crazy)- running through the basic workflows of an application to make sure it doesn’t massively fail. Usually done as a precursor to further in depth testing. For example, you can’t test MS Word’s features if you can’t open a new document. The smoke test would find that you can’t open a new document and kick it back to the programmers to fix.
System Testing - This is where the testing group makes sure that all parts of the application function to user/client specs. This is usually where most testing time is spent since there can be a lot to get through.
User Acceptance Testing - typically the salespeople gather what the client(s) wants and send that over to Project Management which develops docs for the developers (programmers) to write code from. Testers use these docs to design and run their tests. Usually from the time the salesperson writes up the order to the time the software is done, the client really doesn’t know what’s going on. Usually there are demos and such, but the client doesn’t get it’s hands on the software until UAT. Then the client can verify that everything it paid for is there and is working successfully. Also, throughout previous stages of testing, a lot of code is built up on the test machines. UAT also provides for a very clean install to verify all the proper code was included in the install files.
I hope that answers a lot of questions about the testing phase of the software development cycle. Again, not every software development shop is run this way. I worked at one company that only had a System Test team, did very little documentation and did no UAT to speak of, yet they were the leader in their industry.
I really disagree with this. A unit test tests a very small piece of functionality in isolation to confirm that it meets its contract. I certainly wouldn’t say that a system-wide test is a unit test just because it is run by a developer.
where did i say otherwise? I certainly didn’t intend to. I was just hashing out the testing life cycle as I am used to it. In the company I work for the unit test os what the developer would do to satisfy themselves that the required changes were working at a basic level. The program would then be returned to the requestor who would do their own testing - I would usually refer to this as regression testing, making sure that the introduced changes have not impacted other areas of the process involved, but YMMV. After all this, the UAT would then be arranged.
One important reason for UAT is monetary: on many contracts, once the customer signs off that the software is running acceptably, any changes are additional cost. Even fixes to make the software work to the original design are chargeable. Be sure to test well before signing the contract, as this Dilbert so aptly illustrates.
When I did technical writing, you have to realize you have to start writing instructions for products long before the product is ever finished as well. When I had my own business this was great money for a bit. I would get as much as 50¢/word, though it was more like 20¢ on average.
Now that technical writing has been largely exported to India, where they pay 10¢ A PAGE