Outside of the computer running the software, user acceptance testing can be very low tech, only requiring a spreadsheet and a stopwatch. The stopwatch is kind of an exaggeration, but if the user journey takes too long, you lose the user.

So you do want to keep performance in mind incase it becomes a barrier for the user in completing the steps. The spreadsheet is the checklist where each test sequence is laid out. A collection of test scenarios is called a test suite.

Example of User Acceptance Testing (UAT)

An example of a test scenario might be as follows:

• Navigate to the homepage.
• Click “contact us” link.
• Observe contact page loads.
• Fill out contact form completely.
• Submit form.
• Verify no errors are present and thank you message displays.

Each point starts with a verb followed by some element of the website. You’ll notice that these steps are pretty simple and a lot of this can be automated for extra testing coverage.

However, you don’t want to skip the human powered UAT because it will be an avenue for reporting unexpected issues and behaviors in the software.

Who can conduct UAT?

Anyone.

User acceptance testing can be done by anyone on the team. It can also be a great task for anyone working adjacent to the project team looking to get involved.

There are arguments to be made that the tester probably should not be the developer, mainly due to blind spots. You can always have more than one person conducting UAT. The more eyes on a project, the more bugs that can be surfaced.

When should UAT be conducted?

After an update has been pushed to an environment.

UAT is a safety check to make sure the expected high level functionality of the site is still intact. A safety check to ensure the site is still useable to the user.

The Importance of UAT

User acceptance testing is the most important testing because it ensures your website and its purpose for existing is still intact. If you spend hundreds or thousands of hours developing software that is unusable to the end user, its basically worthless.

The downside to UAT is that it doesn’t provide the developer with a lot of details about where the issue is occurring. In our example test scenario above, there can be many reasons why the user could be unable to submit a contact form.

It could be a backend issue keeping the whole page from displaying or a frontend bug that is displaying the form incorrectly. This is why it’s important to make informative bug ticket once you do find a bug.

Bug Reporting

Here are some best practices for creating a bug ticket. Ultimately you want a ticket to be useful to the developer and the person who will be testing once the fix is complete.

The first thing the developer is going to do is try and reproduce the issue. Your ticket needs to provide all the necessary information for them to do that. For website testing it makes sense to include the following:

• Consistent title formats
  • An example could look like, “Homepage – Image carousel not rotating”
• A description of the issue
  • It can help to include which step you were on when the failure occurred.
• A link to the page where the issue is occurring
• A screenshot of the issue
• Mention the device/OS/browser being used when issues seen.
  • Macbook/MacOS/Safari

Things to avoid:

• Nesting multiple issues in one ticket
• Creating multiple tickets for the same issue

Conclusion

By implementing user acceptance testing, you can save yourself from a lot of headaches later. Hopefully now, you understand the importance of it. Contact WebDevStudios when you want a team to test the performance of your website.

The post User Acceptance Testing appeared first on WebDevStudios.