Whether you are building software systems for others, or someone is building them for you, it is imperative that the software does what the end users need it to do. While the requirements are intended to say precisely what is needed, software can comply with every letter of the documented requirements and still be inappropriate for use in the real world. User Acceptance Testing (also known as UAT) prevents these unhappy surprises by ensuring that people have real knowledge of how the software will be used evaluate it against the actual business needs before it is ever deployed. This course will guide you in making UAT truly effective on your projects. It will identify the people who should be involved, the things those people should be doing, and when and how those activities should be done. If you are a member of a development team, this course will help you to make the best possible use of UAT in your development projects. If you are a Customer or End User, it will equip you to be an effective User Acceptance Tester.
Who Can Benefit
- End Users - To equip you to perform Acceptance Testing
- Customers - To enable you to formalize your acceptance of software systems
- Product Owners on Agile teams - To fortify your Sprint Reviews
- Project Managers - To enable you to make the best use of UAT in your projects
- Business Analysts - To prepare you to plan for and collaborate with UAT
- Software Testers - To enable you to participate in and support UAT
I. What UAT Is and Is Not
We will begin by describing how UAT differs from other software testing and how it fits into various software development lifecycles (including Waterfall and Agile). Along the way, we'll define a variety of key terms and identify the players.
II. Understanding the Business Need
Business Need has many dimensions from correct computations to ease of use. We will explore each of those dimensions so you can ensure that your UAT addresses each of them in an appropriate way.
III. What Could Go Wrong?
Of all the things we could test, which should we focus on? We will apply Risk-Based testing to focus our UAT where it will be most valuable.
IV. "U" is for User
Effective UAT includes testing from the standpoint of all of the users (both active and passive ones). We will discuss ways to identify all of the users and ensure that their viewpoints are included in our UAT.
V. Incremental UAT
UAT is usually the final gate before deployment, but any problems found at that point in the project can be costly and time-consuming to correct. So we will introduce an incremental approach to UAT that can be integrated into any software development lifecycle (even Waterfall). This incremental approach enables you to identify issues earlier (when they are easier to fix), and reduces the likelihood of unpleasant surprises at the project's end.
VI. Preparing Test Data
Good tests require appropriate test data. We will discuss how to identify and prepare test data that will enable good Acceptance Testing. Along the way we will discuss the limitations, dangers and (in some cases) illegality of using production data for testing, and we will look at options for addressing those issues.
VII. The Acceptance Test Plan
As the old adage says, "Fail to plan; plan to fail." The plans for UAT will be different from those for other testing activities. We will provide guidance for UAT plans, including how to find the "sweet spot" of providing enough guidance to ensure effective and repeatable tests, while enabling the testers to exercise the system as they will use it after it is deployed.
VIII. Performing UAT
Testing is more than just using a computer. We will provide guidance for how Acceptance Testers should operate while performing UAT. We will discuss following UAT plans as well as going beyond them to explore how the system works. We will also discuss evaluating test results, reporting issues and raising questions.
IX. "A" is For Acceptance
We will finish with a discussion of deciding if the system is acceptable or not. We will explore this both from each tester's perspective, and for UAT as a whole. Along the way, we will talk about "minor" defects, unresolved issues, and what it means for the system to be "good enough" in a particular context.