User Acceptance Testing

What is User Acceptance Testing? User Acceptance testing i testing iss the software testing process where syst em tested for acceptability & vali dates the end to end business flow. Such type of testing executed by client in separate environment (si milar to production environment) & confirms whether system meets the requirements as per requirement specification or not. UAT is performed after System Testing is done and all or most of t he major defects have been fixed. This testing is to be conducted in the final stage of Software Development Life Cycle (SDLC) prior to system being delivered to a live environment. UAT users or end users are concentrating on end to end scenarios & typically involves r unning a suite of tests on t he completed system. The Acceptance testing is “black box” box” tests, means UAT users doesn’t aware doesn’t aware of internal structure of the code, they just specify the input to the system & check whether systems respond with correct result.

Levels of testing – testing – User  User Acceptance Testing User Acceptance testing also testing  also known as Customer Acceptance testing ( CAT), if the system is being built or developed by an external supplier. The CAT or UAT are the final confirmation from the client before the system i s ready for production. The business customers are the primary owners of these UAT tests. These tests are created by business customers and articulated in business domain languages. So ideally it is collaboration between business customers, business analysts, testers and developers. It consists of test suites which involve multiple test cases & each test case contains input data (if required) as well as the expected output. The result of test case is either a pass or fail. Acceptance Testing Definition:  Acceptance Testing is a level of the software testing process where a system is tested for acceptability.

Prerequisites of User Acceptance Testing: Prior to start the UAT following checkpoints to be considered:

 

The Business Requirements should be available. The development of software application should be completed & different levels of testing like Unit Testing, Integration Testing & System Testing is completed.



All High Severity, High Priority defects should be verifie d. No any Showstoppers defects in the system.



Check if all reported defects should be verified prior to UAT starts.



Check if Traceability matrix for all testing should be completed.



Before UAT starts error like cosmetic error are acceptable but should be reported.



After fixing all the defects regressio n Testing should be carried out to c heck fixing of defect not breaking t he other working area.



The separate UAT environment similar to production should be ready to start UAT.



The Sign off should be given by System tes ting team which says that Software application ready fo r UAT execution.

TYPES OF ACCEPTANCE TEST Why Alpha and Beta Testing? The software application may use different users on different way & it impossible to developer or tester to predict what all possible scenarios or test data end user will use & how customer actually use the software application. So most of software venders are use the term like Alpha testing and Beta Testing which help to uncover the errors that may occ urs in the actual test environment. In this testing method the software application release over limited end users rather than testing professionals to get feedback from them. A] Alpha Testing Alpha testing is conducted by Customer at the developer’s site, it is performed by potential users like developer, end usersor organization users before it is released to external customers & report the defects found while Alpha testing. This software product testing is not final version of software application, after fixing all reported bug (after bug triage) the new version of software application will release. Sometimes the Alpha Testing is carried out by clie nt or an outsider with the attendance of developer and tester. The version of the release on which Alpha testing is perf orm is called “Alpha Release”. B] Beta Testing Most if times we have the sense of hearing term “Beta release/version”, so it is linked to Beta Testing. Basically the beta testing is to be carried out without any help of developers at the end user’s site b y the end users &, so it is performed under uncontrolled environment. Beta testing i s also known as Field testing. This is used to get feedback from the market. This testing is conducted by limit ed users & all issues found during this t esting are reported on continuous basis which help s to improve the system. Developers are taking actions on all issues reported in beta testing after bug triage & then the software application is ready for the final release. The version release after beta testing is called “Beta Release“. This is last stage of the testing where product is sent outside the company or for trial offer to download. What to Test in User Acceptance Testing? 

Based on the Requirements definition stage use cases the Test cases are created.



Also the Test cases are created considering the real world scenarios for the application.





The actual testing is to be carried out in environments that copy o f the production environment. So in the type o f testing is concentrating on the exact real world use of application. Test cases are designed such that all area of application is covered during testing t o ensure that an effective User Acceptance Testing.

What are the key deliverable of User Acceptance Testing?

The completion of User Acceptance Testing is the significant milestone for traditional testing method. The following key deliverable of User Acceptance Testing phase: 

Test Plan: This outlines the Testing Strategy



UAT Test cases: The Test cases help the team to effectively test the application in UAT environment.



Test Results and Error Reports: This is a log of all the test cases executed and the actual results.



 

User Acceptance Sign-off : This is the system, documentation, and training material s have passed all tests within acceptable margins. Installation Instructions: This is document which helps to install the system in production environment. Documentation Materials: Tested and updated user documentation and training materials are finalized during user acceptance testing

7 Major Challenges of Successful User Acceptance Testing (UAT) and How You Can Overcome These What is User Acceptance Testing (UAT)? UAT is final testing performed when functional, system and regression testing is completed. The main purpose of UAT is to validate the software against the business requirements. This vali dation is carried out by end users who are familiar with the business requirements. UAT, alpha and beta testing are different types of acceptance testing. As user acceptance testing is the last testing carried out before the software goes live, obviously this is the last chance for the customer to test the software and measure if it’s fit for the purpose. Need of User Acceptance Testing Developers and functional testers are technical people who validate the software against thefunctional specifications. They interpret the requirements according to t heir knowledge and develop/test the software (here is the importance of domain knowledge). This software is complete according to the functional specifications but there are some business requirements and processes which are known to end users only are either missed to communicate or misinterpreted. UAT plays an important role in validating if all the business requirements are fulfilled or not before releasing software for the market use. Use of live data and real use cases make UAT testing an important part of the release cycle. Many businesses who suffered big losses due to post-release issues know the importance of successful UAT. The cost of fixing defects after release is many times greater than fixing it before. Who should be part of the UAT team? Mainly end users of the software should be i nvolved in UAT. The team can be comprised of beta tes ters or customer should select UAT members internally from every group of organization so that each and every user role can be tested. 7 major challenges of UAT and mitigation plan to overcome these It doesn’t matter if you are part o f a billion dollar release or a startup team, you should overcome these UAT challenges for delivering successful software for the end user. 1) UAT environment setup and deployment process Carrying out UAT on same environment used by functional test team will certainly end up overlook ing real world use cases. Also crucial testing activities like performance testing can’t be carried out on test environment with incompletetest data. Separate production like environment should be s etup for UAT.

Once the UAT environment is separated from test environment you need to control the release cycle effectively. Uncontrolled release cycle may leads to differ ent software versions on test and UAT environment. Valuable UAT time is wasted by not testing software on latest v ersion. Not to mention the time r equired for issue tracking on incorrect software version. 2) UAT test planning UAT should be planned with clear acceptance test plan in re quirement analysis and design phase. In strate gy planning, set of real world use cases should be identified for execution. It is very important to define test objectives for UAT testing as complete test execution for large application i s not possible in UAT phase. Testing should be carried o ut by prioritizing critical business objectives first. UAT is carried out at the end of the testing cycle. Obviously it is the most critical period for the software release. Delay in any of the previous stages of development a nd testing eat up UAT time. Improper te st planning, in worst cases, leads to overlap between system testing and UAT. Due to less t ime for UAT and pressure to meet deadlines, soft ware is deployed to UAT environment even though functional testing is not completed. UAT goals can’t be achieved in such situations. UAT test plan (template) should be prepared and communicated to team well before beginning UAT. This will help them for test planning, writing test cases and test scripts and creating UAT environment. 3) Handling new business requirements as incidents/defects Ambiguities in requirements get caught in UAT phase. UAT testers find issues arising due to ambiguous requirements (by looking at the complete UI which wasn’t available during requirement gat hering phase) and log it as a defect. Customer expects these to be fixed in current release without considering the time for change requests. If timely decision is not taken by project management on these last-minute changes this could lead to the release failure. 4) Unskilled testers or testers without business knowledge If there is no permanent UAT test team, company select UAT staff from various internal departments. Even if this staff is well familiar with business needs, if they are not trained for the new r equirements being developed they can’t perform effective UAT. Also non-technical business team might face many technical difficulties executing UAT test cases. Also assigning testers at the end of the UAT cycle do not add any value t o the project. Little time to train UAT staff can significantly increase the chances of UAT success. 5) Improper Communication channel Communication between remote development, testing and UAT team is more difficult. Email communication is often very difficult when you have an offshore tech team. A small ambiguity in incident reports can delay its fix for a day. Proper planning and effective communication are critical to effective team collaboration. Project teams should use web based tool to log defects and questions. This will help to distribute work load evenly and avoid reporting duplicate issues. 6) Asking functional test team to perform UAT There is no worse situation than asking functional t est team to perfo rm UAT. Customers offload their responsibility to test team due to lack of resources. The whole purpose of UAT gets compromised in such cases. Once the software goes live, end users will quickly spot the issues which are not considered as real world scenarios by functional testers. Solution to this is to assign UAT to dedicated and skilled testers having business knowledge. 7) The blame game Sometimes business users just try to fi nd reasons to reject the software. It might be their selfdom to show how superior they are or blame the development and t esting team to get respect in business team. This is very rare but happens in teams with internal politics. It’s very difficult to deal with such situations. Building positive relationship with business team would definitely help to avoid blame game.