Example Documents
Performance Testing Strategy:
Since I have started writing articles and moderating forums, one of the most common questions I have been asked is “Where can I get a Performance Test Plan template?” As much as we may want to deny this fact, we have to concede the importance of documenting our projects. Over my tenure as a performance engineer, with the input of countless clients, friends and co-workers, I have compiled the following document of thoughts based on the methodology outlined on this site. I call the resulting document the Performance Engineering Strategy.
Why, you may wonder, do I call this an “engineering strategy” rather than a “test plan”? It is my opinion that these things are quite different, while they do serve fundamentally the same purpose. Many of you are familiar with a functional test plan. This document tells the who, what, when, why and how of the functional testing effort. It includes very specific tasks assigned to specific people to be completed by specific dates. If you look closely at our performance testing approach, you will see that once we execute our first test, we reach a set of decision points. It is simply not possible to put this kind of structure around activities such as ‘tune’ or ‘identify and develop exploratory tests’. We don’t even know when this document is being written if any tuning will be required, or how many exploratory tests may ultimately be developed. How can one assign the optional activity of ‘tune’ to a person when we don’t know what needs to be tuned? One can’t. What one can do, however, is explicitly detail the approach, or strategy, for “what do we do when…?” Because of that, I like to make the distinction up front. While it is possible to build a ‘performance test plan’ I have found that it becomes more of a hindrance than a help by the conclusion of the first battery of executed tests. I find it more useful to have a document that outlines the strategy, then when a performance issue presents itself, to create a ‘mini-plan’ for resolving that performance issue that is consistent with the overall strategy.
Performance Test Results:
One of the most often overlooked aspects of a performance testing engagement is the documentation of results. What happens most often is performance testing falls behind, testing continues frantically until go live day, the application goes live, it doesn’t crash, everyone forgets about performance. Then a couple months later someone finds a performance problem and they ask “Did we find this during testing? Does anyone know how to fix this? Don’t we have scripts to help isolate the problem?”. To which everyone replies…”ummm, I don’t know.”
Why does this happen? Because we didn’t document the results. Now, not only is it our fault that performance “suddenly got bad”, but now we are being accused of “not really doing a good job testing in the first place.”There is one simple way to fix this – with a Performance Testing Results document.
PerformanceTesting Quick-Start:
This document is an outline of things to be thinking about through different stages of the project.It serves as a good reminder to ensure things don't get overlooked.
