I’m a member of a LinkedIn group called “Performance Testing“. This morning a member of the group from BlazeMeter posted a link to their blog article about how much detail to put into a performance test report.
Historically I’ve always put large amounts of detail into performance test reports, but over the last 12 months or so I’ve started to reduce the amount of content. This allows me to produce what the customer generally wants in a shorter time frame.
In most performance tests customers tend to want to know the answer to one question:
Will my application perform well under expected user load?
This can generally be answered with “yes” or “no”, although occasionally the answer is “maybe”. (I tend to use traffic lights to show this at a high level.)
Often much more information than this is simply wasting time. In the last year or so I’ve started to produce reports in Powerpoint that can be easily referred to in conference calls or webinars, be presented to clients at their site and can be re-used internally by my client’s project managers when they want to pass on information to their own internal customers.
I have found that by including less high-level detail and including embedded spreadsheets, charts or other documents allowing technical readers to “drill down” to the detail; I can keep all the potential readers of my reports happy.
I’ve attached a PDF “mock up” of a performance test report based on a test that I ran for a client earlier this year. I’d be interested to hear any comments from other testers about what works for them.