Blog Feed Post

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.graph: averages lie

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.

Related reading

Download: Understanding Continuous testing in an agile world ebook

Read the original blog entry...

More Stories By SOASTA Blog

The SOASTA platform enables digital business owners to gain unprecedented and continuous performance insights into their real user experience on mobile and web devices in real time and at scale.

Latest Stories
The taxi industry never saw Uber coming. Startups are a threat to incumbents like never before, and a major enabler for startups is that they are instantly “cloud ready.” If innovation moves at the pace of IT, then your company is in trouble. Why? Because your data center will not keep up with frenetic pace AWS, Microsoft and Google are rolling out new capabilities. In his session at 20th Cloud Expo, Don Browning, VP of Cloud Architecture at Turner, posited that disruption is inevitable for comp...
No hype cycles or predictions of zillions of things here. IoT is big. You get it. You know your business and have great ideas for a business transformation strategy. What comes next? Time to make it happen. In his session at @ThingsExpo, Jay Mason, Associate Partner at M&S Consulting, presented a step-by-step plan to develop your technology implementation strategy. He discussed the evaluation of communication standards and IoT messaging protocols, data analytics considerations, edge-to-cloud tec...
"When we talk about cloud without compromise what we're talking about is that when people think about 'I need the flexibility of the cloud' - it's the ability to create applications and run them in a cloud environment that's far more flexible,” explained Matthew Finnie, CTO of Interoute, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
IoT solutions exploit operational data generated by Internet-connected smart “things” for the purpose of gaining operational insight and producing “better outcomes” (for example, create new business models, eliminate unscheduled maintenance, etc.). The explosive proliferation of IoT solutions will result in an exponential growth in the volume of IoT data, precipitating significant Information Governance issues: who owns the IoT data, what are the rights/duties of IoT solutions adopters towards t...
Wooed by the promise of faster innovation, lower TCO, and greater agility, businesses of every shape and size have embraced the cloud at every layer of the IT stack – from apps to file sharing to infrastructure. The typical organization currently uses more than a dozen sanctioned cloud apps and will shift more than half of all workloads to the cloud by 2018. Such cloud investments have delivered measurable benefits. But they’ve also resulted in some unintended side-effects: complexity and risk. ...
It is ironic, but perhaps not unexpected, that many organizations who want the benefits of using an Agile approach to deliver software use a waterfall approach to adopting Agile practices: they form plans, they set milestones, and they measure progress by how many teams they have engaged. Old habits die hard, but like most waterfall software projects, most waterfall-style Agile adoption efforts fail to produce the results desired. The problem is that to get the results they want, they have to ch...
With the introduction of IoT and Smart Living in every aspect of our lives, one question has become relevant: What are the security implications? To answer this, first we have to look and explore the security models of the technologies that IoT is founded upon. In his session at @ThingsExpo, Nevi Kaja, a Research Engineer at Ford Motor Company, discussed some of the security challenges of the IoT infrastructure and related how these aspects impact Smart Living. The material was delivered interac...
In 2014, Amazon announced a new form of compute called Lambda. We didn't know it at the time, but this represented a fundamental shift in what we expect from cloud computing. Now, all of the major cloud computing vendors want to take part in this disruptive technology. In his session at 20th Cloud Expo, Doug Vanderweide, an instructor at Linux Academy, discussed why major players like AWS, Microsoft Azure, IBM Bluemix, and Google Cloud Platform are all trying to sidestep VMs and containers wit...
The Internet giants are fully embracing AI. All the services they offer to their customers are aimed at drawing a map of the world with the data they get. The AIs from these companies are used to build disruptive approaches that cannot be used by established enterprises, which are threatened by these disruptions. However, most leaders underestimate the effect this will have on their businesses. In his session at 21st Cloud Expo, Rene Buest, Director Market Research & Technology Evangelism at Ara...
When growing capacity and power in the data center, the architectural trade-offs between server scale-up vs. scale-out continue to be debated. Both approaches are valid: scale-out adds multiple, smaller servers running in a distributed computing model, while scale-up adds fewer, more powerful servers that are capable of running larger workloads. It’s worth noting that there are additional, unique advantages that scale-up architectures offer. One big advantage is large memory and compute capacity...
"We are a monitoring company. We work with Salesforce, BBC, and quite a few other big logos. We basically provide monitoring for them, structure for their cloud services and we fit into the DevOps world" explained David Gildeh, Co-founder and CEO of Outlyer, in this SYS-CON.tv interview at DevOps Summit at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
SYS-CON Events announced today that IBM has been named “Diamond Sponsor” of SYS-CON's 21st Cloud Expo, which will take place on October 31 through November 2nd 2017 at the Santa Clara Convention Center in Santa Clara, California.
A look across the tech landscape at the disruptive technologies that are increasing in prominence and speculate as to which will be most impactful for communications – namely, AI and Cloud Computing. In his session at 20th Cloud Expo, Curtis Peterson, VP of Operations at RingCentral, highlighted the current challenges of these transformative technologies and shared strategies for preparing your organization for these changes. This “view from the top” outlined the latest trends and developments i...
"Loom is applying artificial intelligence and machine learning into the entire log analysis process, from start to finish and at the end you will get a human touch,” explained Sabo Taylor Diab, Vice President, Marketing at Loom Systems, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
In his session at @ThingsExpo, Eric Lachapelle, CEO of the Professional Evaluation and Certification Board (PECB), provided an overview of various initiatives to certify the security of connected devices and future trends in ensuring public trust of IoT. Eric Lachapelle is the Chief Executive Officer of the Professional Evaluation and Certification Board (PECB), an international certification body. His role is to help companies and individuals to achieve professional, accredited and worldwide re...