It is necessary to have a clear big picture of the business domain, associated IT landscape, non-functional requirements, and client expectations in terms of their business growth aspirations will help in framing a comprehensive performance test strategy.
Depending on the appetite of the customer – decide whether you want to put together a detailed strategy in a word document or a powerpoint document – see what works well for the customer and will make the review easier for all the stakeholders involved. This might sound trivial to many, but it goes a long way in making the customer comfortable, and thus garnering their full co-operation.
Your performance test strategy should clearly call out the scope of the work, right to the level of – type of tests and user flows / transactions /jobs/ APIs involved, what sort of performance test requirements will be tested, what parameters will be monitored and what will not. Setting this boundary clearly is going to be the biggest contributing success factor in execution of the performance test strategy.
Your strategy document can enlist the key stakeholders – business, product owners, product architects, technical architects, development team members, infrastructure support team, performance test lead/manager, performance test team and their associated responsibilities neatly marked in a RACI matrix. It is important to tie this clearly with governance, so that every relevant stakeholder in the party knows their role and what is expected out of them.
The next success factor would be, the need to put together a nice detailed but crisp test approach of how you are going to test the performance requirements, what are the goals, what would be the pre-requisites/entry criteria for these tests, what types of test will be executed, how every test type would be conducted, what would be measured and what are the SLAs or KPIs against which these test results will be evaluated.
There are multiple aspects to be factored in the test approach depending on the product life stage and the time at which the performance test team is engaged. Let us first consider the scenario where the application/platform is being ideated or built from scratch. To get a good gist of what needs to be done about the requirements gathering, click here “unlocking key to successful cloud migration“.
Once the requirements are made available, you should factor in the anticipated business usage patterns encompassing different roles, transaction flows, APIs, batch jobs that might be involved. While the applications are built from scratch, we usually get to see that a workload model is being built to mimic real-life peak user usage as close to reality as possible. You might need to factor for background noise simulation where there would be other traffic in the system that might add to the processing and utilization.
