User Acceptance Testing is a vital but often overlooked aspect of software development. It can seem redundant, and no one wants to hear about software bugs from a frantic email from an end user. But developers and end users may not always have the same understanding of the requirements, and it’s better to know about any potential issues or misalignments before the software goes live rather than afterward.
In this article, I cover some User Acceptance Testing best practices to ensure your application is thoroughly tested, bugs get resolved before launch, and clients are successful and happy.
Create Detailed Test Cases
Clear test cases speed up testing and give clarity during the development process. They provide insight into what the requirements are meant to do in practice and allow the developer a chance to fix any edge cases before checking in their code.
Be Specific
Test cases need to be as thorough and specific as possible. Specify what buttons to click, what account to use, what data to enter, and what results the user should see. They should also cover how new functionality fits in with existing pieces. For example, when the update is to the View Cart page of your application, include test cases in which the user completes the purchase, abandons the purchase, or leaves and comes back later.
Include Negative Test Cases
Test cases need to include negative test cases – that is, what should not happen. Too often, test cases only look at the best-case scenario: go to this page, click this button, and a success message appears. But what happens if a user does something unexpected? Ideally, test cases should specify everything a user can do with the new piece of development and what should happen as a result. For example, if you have a new phone number field, what happens if someone enters their number in a strange format, enters a letter instead of a number, or leaves it blank? Checking these negative test cases prevents having to create numerous patches in the future.
Don’t Let Developers Participate in the Test
Before any actual testing starts, define who will do the testing. The development team should not participate in the user test: their job is only to view test results and squash any bugs that surfaced. If the application is internal, the actual users should test it, as they are best suited to know what functionality they need and what the business logic should be. If the application faces external end users, designate a team member familiar with it to test on their .
Test the “Untestable”
Sometimes, new functionality can be difficult to test. Applications may have functions that are only triggered by rare events, or that only occur at certain times of the day. In these scenarios, developers must be given time to provide what I call “tester helpers.” In most cases, these are web pages visible to only certain users that provide them with the ability to trigger certain events. Here’s an example: An application has a function that checks if jobs are past their expiration date, and marks them “expired” if they are. However, this function is only triggered at midnight each night, making testing inconvenient and inefficient. So, I set up a hidden “helper” page that has a button to trigger the job at any time. Testing shouldn’t be skipped because something appears to be untestable.
Create Bug Communication Standards
Bugs will be found in any application, and when they are, the way in which they’re communicated can make a big difference in how quickly the issue is resolved. When sending bug data to your development team, be as specific as possible. Sending a vague description, such as “I tried saving a customer and it didn’t work,” will result in a lot of additional questions from developers and pushes back the timeline for actually fixing it.
Use Screenshots or Screencasts to Send Bug Data
I recommend sending screenshots or a screencast whenever possible. They answer a lot of questions for a developer – what page it happened on, what data was entered, what error message was seen, and what time it happened at. The time it happened is particularly important. Your application should have error logging, and specifying what time the error occurred helps the developer find what error corresponds to your issue.
Religiously Make a New Ticket for Each New Bug
Also, if you’re using issue tracking software like Jira, make a new ticket for any new bugs you see. If an issue is unrelated to any current tickets, sending bug data through existing tickets will only make the bug harder to find and harder to track. And when you’re setting up your ticket workflow, be sure to include states for UAT Fail and Adjustments, which makes it easier for developers to see what tickets failed testing. And it lets you see what tickets are in the process of being fixed in Adjustments.
By incorporating the outlined user acceptance testing best practices into your workflow, you ensure your software meets user demands in real-world scenarios. You’ll ultimately save development time and money – and reduce anxiety and stress at go-live. Your customers will be impressed with your thoroughness and delighted with the final result.
