A little over a year ago I met with another tester in town to provide advice on performance testing. I recently found the notes from the meeting in an old notebook. In the five pages of handwritten notes, I documented my understanding of the problem and how I would approach the project. Take these notes for what they are - sketches over the course of an hour or two as I asked questions and clarified the project. However, I thought they would be interesting to share.

The second page was an attempt to understand the goals of the performance testing.



They wanted to better understand their calls-per-hour capacity. They were also trying to determine how many licenses they needed of third-party software to support their anticipated load. As I took notes, I jotted down a couple of constraints and some additional details of a couple of key components/transactions.

A little over a year ago I met with another tester in town to provide advice on performance testing. I recently found the notes from the meeting in an old notebook. In the five pages of handwritten notes, I documented my understanding of the problem and how I would approach the project. Take these notes for what they are - sketches over the course of an hour or two as I asked questions and clarified the project. However, I thought they would be interesting to share.

The first page was an interactive attempt to understand the problem.



To protect the company (who might not want to be identified) I won't provide more details than what's in the picture, but what I remember was that it emerged over a series of questions where I asked things like: "And that's connected to?", "And that gets its data from where?", and "That's not on here yet, where does it go?"

When using tables and graphs of data test, check the following generic formatting points before you submit your results for review:

• Is it clear what data the table is showing? Does it have a clear caption?


• Do all columns contain headers? Is it clear what the data in that column represents?


• Are you showing enough significant digits in the data?


• Do the units of measure line up? Are they consistent across columns/tables as appropriate?


• Would the data be better shown as a graph? If there is a graph, is it clear that the data and graph are related?


• Do the graphs use the same terminology and units as the data? If not, is that made clear somehow?


• Does the graph contain too much data? Should it be broken out into multiple graphs to make it simpler to read or follow?


• How big is the resulting file where you've stored your tables and graphs? Is it too big to share using your standard method of delivery for information of this type?

When running load runner tests, I grab screen shots of the settings used on the Controller. Its a fast way to keep track of the settings. And if an arguement comes along after testing about what settings were used, I have proof. Settings in the Controller are essential factors. I would imagine this same tip could be applied to other tools.