%% date:: [[2022-10-27]] %% # [[Reporting load testing results]] Communicating the [[Analyzing load testing results|load testing results]] is almost as important as running the test itself because a good report can sometimes determine whether your findings are actually addressed or whether your testing becomes just a “check-the-box” activity that gets forgotten. You’ll likely need to come up with at least two reports based on the expertise of the stakeholders you’re giving reports to. ## The Management Report The management report is one that you intend to give to an audience that is not necessarily technical, so you’ll need to tailor the results you show accordingly. ## The Executive Summary This summary should explain in simple terms what you did, why you did it (your goal), how the application behaved, and what you can recommend that would improve performance. This is the highest level of report and, depending on the experience of the manager you’re giving this to, may be the only thing that some people read. So make it easy to read, as free of technical jargon as possible, and with very simple tables. If possible, put findings in bullet points. If your report is a book, the executive summary should be the CliffsNotes version: enough to understand the gist of testing even if you don’t get into any of the specifics. For the rest of the management report, you can then back up a bit and then go into slightly more detail about each point: - Nonfunctional requirements: what were they? - Test scenario: what tool did you use for the test? What were the key transactions that you identified? How many times did you run the test, and for how long? Did you run different kinds of tests (load, peak, stress, etc)? How many users did you run? - Results: what were the response times of the key transactions? Include the top five or ten transactions with the highest response times. - Fixes: What issues did you find on the application servers? Were there any things that were addressed as part of testing in order to improve testing? Show a before-and-after graph of chart of response times with the differences highlighted. - Recommendations: What server configuration does your testing suggest is optimal? How did this release compare to other releases in terms of performance (if applicable)? If you had more time to test, what kind of tests would you run, and are there any tests that you would recommend adding to the standard suite of tests in the future? If appropriate for your role, this is also where you make a GO/NO GO recommendation, along with reasons for that decision. ## The Technical Report While the management report prioritises readability and comprehensibility above precision, the technical report will be geared towards the developers or other technical testers on your team, so you can go ahead and add more detail. This is where you’ll go through ALL of the results, but don’t forget that you’re still telling a story— don’t just copy and paste graphs; explain what they mean. While in the management report you should tend to go for average response times, you can expand on this a bit in the technical report and include some more statistics, such as percentiles, standard deviation, and other ways to display the same data. You can also include data here that is not necessarily significant — for instance, if the resource utilisation on the load generators was healthy, you will not want to include graphs in the management report, but you should include it in the technical report to anticipate those questions. ## [[Principles for reporting results]]