So…. you have to improve the system performance, the rules, meet new demands on the call center, move to architecture faster and more automated than the legacy systems….
Performance testing is a great way to take a look at the whole system before you begin even a legacy lift.
I say this because in order to prepare for a robust performance testing program, the whole system should be ‘decomposed‘ and analyzed from the final end point of Delivery of Services all the way back to the input of information at the beginning of the system. This type of ‘backing through the system’ ensures that each workflow, each touchpoint (SOAP-service, MQ, etc.), each system, and process to support a given line of business has been assessed and evaluated.
In this process, many important metrics are discovered: Response times based on normal and peak usage of a given worktype, workflow, call center, or actual system, as well as E2E coherency. This process is effective whether performance testing has ever been done in the organization or not. Often it is limited to only a short throw of a specific system’s performance. With expanding technology, the system designed even 5 years ago can easliy be out of date. So, a full E2E Performance Testing of a given system has merit, especially if upgrading the platform. Such as a new Claims processing platform/application, Loan Application Process, Policy Management system, or even a workflow management system.
So, in a way, Performance Testing is the elephant in the corner, because it reveals system weaknesses and needs, broken processes, antiquated code, antiquated data, rules revisions, risks/dependencies, and of course costs to shore up or replace hardware, monitoring tools, or review of process efficiencies or inefficiencies. All of these items can be confrontive and require capitalization.
With that said, Performance Testing in the best of lights, is mostly preparation, analysis, education, and a great investment into system fluency. The information gained in this process alone, will provide the following benefits: general health check on the system, prioritization of system needs based upon risk and cost, planning for implementation of needed changes to applications, hardware, processes and product output.
So when I hear “let’s bring in Performance Testing at the end, after everything is built”, you might say I have some concerns. Did you do a system analysis, or did you just build another project/product to operate on the same system without assessing the impact on present load and operations, or what impact this product will bring in the next year or two, or five.
What are the plans to begin ongoing monitoring and assessment of system capability to handle the growing needs and market demands?
Just a few thoughts in case a new system lift, upgrade, transformation, or product release is being considered. Consider Performance Testing the same as an Insurance Policy, and the reviews of your portfolio to have sufficient coverage if you have a loss. Without regular checkups, your ‘policy’ could be out of date, ‘out of force’, or non-renewed.
One last thought. Trying to cram it in at the last minute to use remaining budget for the year, is highly risky. In the past few months, I have seen just that in several cases. Performance Testing is not a fix, rather it is a validation of what you have. If what you have at the last minute is insufficient, going to production will be risky and costly.
Sorry for the bad news, but it is better to do these things FIRST to prepare the way for a successful launch.
A posting from my Linked-In Article with the same Title