A high-level best practice guide to User Acceptance Testing

Once development on your no-code/Intelastel application is near completion, you will need to perform a cycle of user acceptance testing for your product, before you can release it to your end user base.

The best way to approach this is with a testing plan.

There are many approaches to creating a testing plan, but any good plan should always address the following:

• Does it meet the business needs?
• Does the functionality meet the agreed acceptance criteria as set out in the design brief?
• Does each function or feature work in such a way that the user can perform a task using the application, and get the result they would expect?
• Is it user friendly enough?
• Does any part need documentation? – Are there any steps or processes that should be described or illustrated?

Steps

• Get the team together: You’ll need at least each one of the following:
  • Software tester (this may be you)
  • Business or Product owner (this may also be you)
  • Test users whose roles are similar to each of your product’s user personae
  • These testers will need to be within your business, with the appropriate business roles

Any third party you bring in for testing must have signed an Non-Disclosure Agreement (NDA). These users should only have access to a testing environment which does not hold any sensitive or personal information 

Do not expose any sensitive or personal information without permission from the owner of said data

• A no-code developer (this may be you, the no-code developer)
• Refer your list of original requirements from your design document
  • Analyse it per requirement, per user role

“As a User I want to be able to…”

• Form questions for your testing group to answer, based on each requirement

“As a User am I able to…?”

• Analyse each requirement, and consider how each feature or function of your application serves to meet that requirement. 
  • How does this present itself to the end user?
  • Can the end user find the tooling they need with ease?

Testing methods

• • Focussed testing
    • Each user tests the application against a set of functions related to their role – to mimic everyday use of the application
  • Exhaustive testing
    • Each user goes through the steps of using each feature of your application on a case by case basis, to ensure that each requirement has been met – this will ensure: 
      • users report on being able to do everything they should be able to do
      • anything they cannot do
      • anything they ought not to be able to do
      • confirm permission levels are set as expected for each user Role within the system

Feedback: Have all users feed back to you with the outcomes of each test

• • Ensure that more than one person tests each requirement – the outcomes may have a subjective element due to human nature, and having multiple testers should help to reduce bias
  • Have your software tester come up with some potential out-of-use-case scenarios to test against – these are cases that a user of type <role> should never be able to do/access

E.g. A non-admin user attempts to access the configuration; a non-admin user tries to edit records that they should have read-only access to

Identify edge case scenarios and ensure system behaviour is as expected

Scenarios that are unlikely to affect many users or occur infrequently – For example, can records be created for the 29th February only in leap years?

Collect the feedback and triage it into the three categories:

• Bugs – to be fixed and retested
• Issues – to be analysed, documented or redesigned
• Feature and change requests – to be added to the product development backlog
• You should repeat this process every time you are ready to launch a major new feature or functional upgrade 

This guide is intended as advice only, seek legal advice where necessary for the treatment of your confidential data

This tutorial is available to download as a handy guide: No-Code UAT Guide.pdf