Detailed Execution Plan - Performance Engineering
When you create your comprehensive performance test plan, are you including a Detailed Execution Plan?
Performance Testing can be as much art as science. It's much like war: You can have a great battle plan, but as soon as the bullets start flying, you have to change it. As soon as you begin to load your system with virtual users and data, your schedule often must deviate. A 20% nominal load test may find the performance knee, necessitating triage, for example.
So how is it possible to actually plan how long it will take to flush out performance and scalability defects? Glad you asked. If you could accurately answer that question before you begin testing, you probably wouldn't need to test.
Let's ask another question: Given my project timeline, what can I test? The answer to that question is much more achievable. First, you need to carve out manageable test cycles of two to four weeks each. When planning out your schedule, be sure to leave room between cycles for remediation, new builds/transports and for data refreshes.
Finally, a detailed execution plan, complete with daytime and nighttime activities should be created. The detailed test plan should include what batches should run when. Your daytime activities often include sales order and supply chain-related activity. Your afternoon/evening activities may include items like delivery due, pick-pack-ship, vendor data exports, etc. Your overnight activities should run based on your batch schedule. However, you may have input to that schedule, depending on your test results.
Though a true DITL (day-in-the-life) test would run 24 hours a day, you can divide up your test scope items into manageable blocks of 2-4 hours (daytime peak, afternoon/evening activity, nighttime peak). Some enterprises are better suited than others for around the clock testing in pre-prod / staging.
The key here is to plan what is achievable, socialize your plan with all stakeholders and then be ready to flex your plan as soon as results begin to roll in.
Brian repeatedly created, updated, and socialized performance execution plans with DITL time blocks for us successfully in an environment where the timeline was fixed and the scope often increased.