User Acceptance Testing

User acceptance testing would involve testing from an end user point of view to determine if you "ACCEPT" the software or not. Usually, acceptance is done by or on behalf of an end user or end customer for whom you are developing software. Sometimes, a development organization may ask a small group of users who have deep knowledge of the business requirements to do acceptance testing as well. In any case, it should be done from the end user point of view for stories or use cases that they would execute frequently.

If you want to do User Acceptance Testing (UAT) for an insurance portal, what would be the top scenarios that a user would do on the portal. For example, some user stories that we have run across in our experience with acceptance testing include:

1. Notification to insured – An insured receives notification through their email that they have a message, invoice or other information regarding their policy.

2. Look up To-Do List – An insured goes into the portal and checks their to-do list for any recent audits to enter payroll or bills to be paid.

3. API test results - though not from an insured point of view, data from various systems needs to get into the portal for the insured to access. This could include invoices, policy documents, claims information and any other information captured.

4. Input or update billing information - An insured must enter or update their credit card or bank account information for automatic payments.

5. Correspondence – review policy documents, invoices, and any email messages.

6. Cancel or schedule automatic payments – Insured's often need to cancel or edit and reschedule a payment.

7. Review Loss Run – An insured may review loss run reports for loss prevention that may affect various departments within the business.

Going through typical scenarios such as those listed above would constitute the User Acceptance Testing for an insured portal. Special attention is needed when considering the end user. Sometimes it is the insured, broker, or employee. Each has different usage. As you can see, there are many variations that need to be tested as well.

Back to Blog Home