How to Interpret and Report Your Performance Test Results (so People Actually Read Them)

I recently attended STPCon in San Francisco. It was a good software testing conference, and STP continues to welcome performance testing in a way most other testing conferences do not. I led a tutorial called Interpreting and Reporting Performance Test Results, which I want to share in blog form today. (My slides are embedded at the bottom of this post, if you’d like to check them out, too.)

What Is a Performance Test?

Performance tests try to reduce the risks of downtime or outages on a multi-user systems by conducting experiments that use load to reveal limitations and errors in the system. Testing is usually assessing the performance and capacity of systems that were expensive and time-consuming to build.

Very few software projects are delivered early – and it’s never happened in my experience – so there are usually significant time pressures. The findings of a performance test inform tactical and strategic decisions that have even more at stake; the wrong decision about going live with a website or application could damage the financial results, brand, or even viability of the company.

The Stakes for Performance Testing Are Almost Always Pretty High

In a short period of time, we need to gather information to help us advise our stakeholders on making decisions that will affect businesses and potentially, careers. As the performance tester, we have a responsibility to report reliable information about the systems we test, and be willing to not only risk our credibility, but to ask others to stake theirs on our word, too.

All of the steps in performance testing matter to successful projects and making good decisions. These steps include (but aren’t limited to):

• discovery,
• modeling,
• developing scripts, and
• executing tests.

These are all steps where skill and experience are necessary to getting it right, always at the peril of asking the wrong questions and getting information that is not predictive about the production load the system will face.

Properly interpreting that information and reporting it is where even the right test can fail to deliver value – or worse, mislead by being wrong. Interpreting these results and reporting them properly is where the value of an experienced performance engineer is proven. 

Data Needs Analysis to Become Information

This is the place that my tutorial started. After running a performance test, there will be barrels full of numbers.

So what’s next?

The answer is definitely not to generate and send a canned report from your testing tool. Results interpretation and reporting is where a performance tester earns their stripes.

Visualizing data with graphs is the most commonly used method for analyzing load testing results

Most load testing tools have some graphing capability, but you should not mistake graphs for reports. Graphs are just a tool. The person operating the tool has to interpret the data that graphs help visualize, determine what matters and what doesn’t, and present actionable information in a way that stakeholders can consume.

As an aside, here’s an example of a graph showing how averages lie. Good visualizations help expose how data can be misleading.

The performance tester should form hypotheses, draw tentative conclusions, determine what information is needed to confirm or disprove them, and prepare key visualizations that both give insight on system performance and bottlenecks and support the narrative of the report.

Some of the skills necessary for doing this are foundational technical skills, understanding things like:

• architecture,
• hard and soft resources,
• garbage collection algorithms,
• database performance,
• message bus characteristics, and
• other components of complex systems.

Understanding that a system slows down at a certain load is of some value. Understanding the reason for the system slowing down: the limiting resource, the scalability characteristics of the system – this information is actionable. This knowledge and experience recognizing patterns can take years to acquire, and that learning is ongoing.

Other Skills Are Socio-Political in Nature

We need to know what stakeholders want to hear, because that reveals what information they are looking for:

• Who needs to know these results?
• What do they need to know?
• How do they want to be told?
• How can we form and share the narrative so that everyone on the team can make good decisions that will help us all succeed?

It is our job to be the headlights of a project, revealing information about what reality is. We want to tell the truth, but we can guide our team with actionable feedback to turn findings into a plan, not just a series of complaints.

It Might Seem Daunting to Imagine Growing All of These Skills

The good news is that you don’t have to do this all by yourself. The subject matter experts you are working with – Developers, Operations, DBAs, help desk techs, business stakeholders, and your other teammates — all have information that can help you unlock the full value of a performance test.

This is a complex process, full of tacit knowledge and difficult to teach. In describing how to do this, my former consulting partner and mentor Dan Downing came up with a six-step process called CAVIAR:

1. Collecting
2. Aggregating
3. Visualizing
4. Interpreting
5. Analyzing
6. Reporting

1. Collecting is gathering all results from test that can help gain confidence in results validity.

Are there errors? What kind, and when? What are the patterns? Can you get error logs from the application?

One important component of collecting is granularity. Measurements from every few seconds can help you spot trends and transient conditions. One tutorial attendee shared how he asked for access to monitor servers during a test, and was instead sent resource data with five minute granularity.

2. Aggregating is summarizing measurements using various levels of granularity to provide tree and forest views, but using consistent granularities to enable accurate correlation.

Another component is meaningful statistics: scatter, min-max range, variance, percentiles, and other ways of examining the distribution of data. Use multiple metrics to “triangulate”” — that is, confirm (or invalidate) hypotheses

3. Visualizing is about graphing key indicators to help understand what occurred during the test.

Here are some key graphs to start with:

• Errors over load (“results valid?”)
• Bandwidth throughput over load (“system bottleneck?”)
• Response time over load (“how does system scale?”)
  • Business process end-to-end
  • Page level (min-avg-max-SD-90th percentile)
• System resources (“how’s the infrastructure capacity?”)
  • Server cpu over load
  • JVM heap memory/GC
  • DB lock contention, I/O Latency

4. Interpreting is making sense of what you see, or to be scientific, drawing conclusions from observations and hypotheses.

Some of the steps here:

• Make objective, quantitative observations from graphs / data: “I observe that…”; no evaluation at this point!
• Correlate / triangulate graphs / data: “Comparing graph A to graph B…” – relate observations to each other
• Develop hypotheses from correlated observations
• Test hypotheses and achieve consensus among tech teams: “It appears as though…” – test these with extended team; corroborate with other information (anecdotal observations, manual tests)
• Turn validated hypotheses into conclusions: “From observations a, b, c, corroborated by d, I conclude that…”

5. Assessing is checking where we met our objectives, and deciding what action we should take as a result.

Determine remediation options at appropriate level – business, middleware, application, infrastructure, network. Perform agreed-to remediation, and retest.

Generate recommendations at this stage. Recommendations should be specific and actionable at a business or technical level. Discuss findings with technical team members: “What does this look like to you?” Your findings should be reviewed (and if possible, supported) by the teams that need to perform the actions. Nobody likes surprises.

Recommendations should quantify the benefit, if possible the cost, and the risk of not doing it. Remember that a tester illuminates and describes the situation. The final outcome is up to the judgment of your stakeholders, not you. If you provide good information and well-supported recommendations, you’ve done your job.

6. Reporting is last.

Note the “-ing”. We’re not talking about dropping a massive report into an email and walking away.

This includes the written report, presentation of results, email summaries, and even oral reports. The narrative, the short 30-second elevator summary, the three paragraph email – these are the report formats that the most people will consume, so it is worth spending time on getting these right, instead of trying to write a great treatise that no one will read. Author the narrative yourself, instead of letting others interpret your work for you.

Good reporting conveys recommendations in stakeholders’ terms. You should identify the audience(s) for the report, and write and talk in their language. What are the three things you need to convey? What information is needed to support these three things?

How to Write a Test Report

A written report is still usually the key deliverable, even if most people won’t read it (and fewer will read the whole report).

One way to construct the written report might be like this:

1. Executive summary (3 pages max, 2 is better)

• The primary audience is usually executive sponsors and the business; write the summary at the front of the report for them.
• Pay close attention to language, acronyms, and jargon. In other words, either explain it or leave it out.
• Be careful about the appropriate level of detail.
• Try to make a correlation to business objectives.
• Summarize objectives, approach, target load, acceptance criteria.
• Cite factual observations.
• Draw conclusions based on observations.
• Make actionable recommendations.

2. Supporting detail

• Rich technical detail here. Include observations and annotated graphs.
• Include feedback from technical teams. Quote accurately.
• Test parameters (date/time executed, business processes, load ramp, think-times, system tested (hardware configuration, software versions/builds).
• Consider sections for errors, throughput, scalability, and capacity.
• In each section: annotated graphs, observations, conclusions, recommendations.

3. Associated docs (if appropriate)

Full set of graphs, workflow detail, scripts, test assets, at the end of the report to document what was done.

Note this is not pressing “Print” of tool’s default Report. Who is the audience? Why would they want to see 50 graphs and 20 tables? What will they be able to see?

Remember: Data + Analysis = INFORMATION

The Last Step: Present the Results

Make 5-10 slides, schedule a meeting with all the stakeholders, and deliver the key findings. Explain your recommendations, describe the risks, and suggest the solutions.

Caveats and Takeaways

This methodology isn’t appropriate for every context. Your project may be small, or you may have a charter to run a single test and report to only a technical audience. There are other reasons to decide to do things differently in your project, and that’s OK. Keep in mind that your expertise as a performance tester is what turns numbers into actionable information.

Original article by Eric Proegler