I’ve been involved in a number of migrations across a wide range of customers. And one common theme always stands out – application testing. Many of the businesses are running functional testing, however this is often performed in live server environments with little or no user experience or load testing.
I therefore thought it would be useful to explore the reasons why businesses are focussing on application testing and highlight the important role it plays in any successful cloud migration.
Why test any application?
Quite simply applications are living entities. They are born into a business driven by a requirement. As a result, they will grow with the businesses’ changing demands, be upgraded, patched and as part of a full system lifecycle may be retired when a newer service is available. During the application lifecycle, many elements of the system will change, including underlying infrastructure. Internal support teams need to ensure a consistent level of service throughout, tracking ongoing business value against its original investment and measuring improvements as they are delivered.
What core elements need to be tested?
- Functionality of the application – do all the current tasks still work & does new functionality work as expected?
- Performance of the application – do all core functions continue to run at the same or faster speed than before the change?
- User experience improvement – this covers a couple of areas: cosmetic (what the user sees) and perception (how the user feels). Has anything been moved, added or deleted? Does the user think it takes the same time or longer to login & load new pages?
More importantly, you need to run these tests on your current application landscape to create a baseline which can be used for comparison moving forward. If you’re running separate application environments, these tests may be broken down to align with the appropriate infrastructure.
Where do the pitfalls lie?
Even when a rigorous testing regime is implemented, it is important to remember the underlying infrastructure limitations. If tests are being run on 5 year old & highly utilised hardware, it is possible you will receive distorted results caused by an underlying limitation, rather than a maximum application performance. For example, a database may be performance limited by the underlying storage system. If migrated to a newer environment, the potential for improved performance could be realised – but be aware of any provider charges for using all the available storage performance.
Regular testing cycles will allow support staff to document gradual decline in application performance as capacity limits are reached. This information can then be fed back into your business allowing strategic decisions to be made about upgrades which may be required now or in the future. This is where using a Cloud Service Provider can drive real benefit: additional resources can be added without long lead time, and similarly if they do not deliver the expected benefit they can be removed again.
Don’t forget user perception. Today’s application users expect quick responses and timely operations – in the business domain as it is in their personal computing experiences.
Acceptable responses 5 years ago would leave today’s end users frustrated, as we become more intolerant of delays in an increasingly instant digital world.