The steps in creating User Acceptance Testing.
User Acceptance Testing, or UAT, is the final step in the application development cycle. Before UAT begins; unit, integration and system testing will have already been completed. User acceptance testing allows the soon-to-be users to test the application before accepting the final deliverable.
As developers and testers create the application they iron out and fix the bugs that they come across. The developers determine what areas need to be fixed and how. This is usually determined by the development team and only addresses specific areas to make sure the code works properly.
The testing team finds ways to break the application. They will create intricate test cases to verify that the application won’t break when the user does certain things. Between the testing and development teams the application will go through a vigorous array of testing cycles. The end user, however, is a different animal.
The end user does not know how the code should work. They don’t run testing’s test cases; they should be their own team that performs their own tests for their own company. When dealing with Internet apps, a lot of this is handled during the Beta phase. Before releasing the product the company should have a “test server” to allow the community to run the application and report bugs.
During the Requirements Definitions phase of the project a list of requirements are outlined. There will also be a list of possible add-ons. The add-ons are not requirements but more of a wish list. If the developers have time to add them then the client will be happy. However, in many cases the wish list items will be added into the application at a later release date. The first thing to do is read this requirements list. These requirements are what “need” to be tested. These requirements have already been tested thoroughly, but the UAT testing team should give it a once over to verify the application is meeting the standard requirements. These should be retested every time the development fixes a bug to make sure nothing was broken.
Create a User Acceptance Strategy. Using the defined requirements determine what kind of team you will need. You will need to know how many people you will need and what kind of knowledge they will bring to the table. This strategy will also have test cases, execution of test cases, bug tracking, resolution of bugs and a Sign Off stage.
Create UAT Test Cases. These test cases are designed around the requirements and will involve input from the Business Analysis team, Project Management team and Developer team, but should be created by the UAT test team, not from the company that developed the product.. The test cases are viewed from a user-friendly point of view. Try to break the application as a user would. The key here is to not follow the directions of the development team. They will send directions on how everything is supposed to work. The user will be lost and do things they are not supposed to, you can bet on it. This is the thing you are trying to test for.
The testing is strictly black-box testing. All white-box testing should have been performed before this stage.
Test cases should be prepared for each window that appears. So, the test case for looking for misspellings should appear on each test case for each window. Not stated once at the beginning of the project.
Begin the user acceptance testing by selecting all the members of the team that should be added. It is best to get people that have not worked on the application. They will have new eyes and will not know how the application ‘should’ work.
Perform the user acceptance testing. The team will follow the test cases and try to 'break' the application.
Record any defects or bugs found during the execution phase. The user acceptance testing team will record any and all bugs found by them.
Developers will now fix the bugs found by the user acceptance team. If bugs are found that are not defined in the User Acceptance Strategy then the development team may choose not to fix them. If this occurs let your testing manager know. If they think it is a bug that needs to be fixed they can contact project management. From there the client will be called to find out what they want to do. If the bug falls into the scope of the requirements then the bug will be fixed. If it does not, then program management and the client will come to an agreement. It will wither not be fixed, fixed for free or an added fee will be charged to fix the bug.
Once all requirements are met then you will enter the Sign Off stage. At this point you tell the client that everything is ready to start production. The client will sign off stating they are happy with your work and you will send all test cases, strategies and procedures to the client. Upon receiving all materials and code the client will pay you in full.