What do I need to think about when testing an application after a major upgrade (mostly UI)?

Soon we will be implementing a major upgrade to our Identity & Access Management application. The upgrade is mostly around the UI, but more than likely there may be other underlying changes.

I’d like to take the most pragmatic approach I can while performing the upgrade testing, and I’m interested to hear about what test approaches you have used and what things I need to consider/test and how you document the tests/coverage.

Also, talking about things that didn’t work is always useful. :slight_smile:

Ensure the existing functions are still accessible on the new interface unless decisions made to remove or hide it.

Ensure any flow changes are properly highlighted if not yet by others.

Ensure the new UI is still intuitive enough for the users.

Performance and security to be checked ensure it follows acceptable standard by the org.

Accessibility guidelines followed as much as possible.

Get users involved earlier if possible. Have them to come up with scenarios they normally used system for. DO NOT forget about scenarios which may only happen once a year or a few years.

2 Likes

Luke’s hit a lot of the major points. For me, security, performance, and accessibility would all be high on the agenda of areas to test.

One other thing that I’ve come to learn is with any change to the UI, make sure you cover cross-browser testing. If you’ve access to some usage metrics I’d be looking at what are the top browsers being used by your customers to access the application and use that as a starting point to pick what browsers you should test with, and to what extent.

Ideally, some form of automated checks to validate across different browsers would be great, but I’m hazarding a guess that even if you have that, it’s entirely possible that the UI upgrade would have broken a lot of them.

Of course, YMMV :wink:

2 Likes