Wednesday, January 9, 2013

How to organise a performance test without having the experience

What do you do when you need to organize a load and/ or stress test of a web application but you've never done it before? The purpose of this article is to provide a light checklist of things to keep in mind when organizing a performance test.

1. Define some high level performance indicators
Check the competition - how long do they take to load a page in average?Which pages load fast and which load slower - and when is a slower load acceptable?
Who needs to be involved? Client, Technical Architect, Sponsor, PM
On average, a screen needs to load in 2 seconds
Overview pages need to load in 5 seconds
Detail pages need to load within a second

2. Obtain the business critical scenario's
Common sense will get you far. Think of
- How many concurrent users/transactions do you expect to be used by the functions?
- Which functions are heavy or complex? (think of calculation engines)
- Think about peak times and regular time simulations. (You might not want to pay for infrastructure that you will only use once a year)
- Think about back ground concurrent (batch) processes that need to be simulated
Who needs to be involved? Business, Technical architect, Oracle or Expert (someone the clients business and or technical processes)
Example: Definition of the risk class of a prospect based upon a set of defined parameters
Rule of thumb: Try not to have more than 10 scenario's

3. Create the detailed test scenario's
During functional testing, make screenshots and exact steps on how to reproduce each scenario
Interesting additions are
- Think times: How long does it take to fill out a page before you can proceed
- Expected response times per screen or per request
- Define load profiles: Out of 100% total users, how many will use which scenario - in comparison to expected business behavior.

4. Define the environmental needs
An environment needs to be as close to the production environment as possible to obtain comparable results. If you have the opportunity to use the Prod environment only once (before go live) then do the exact same tests on the non-sized test environment. You might be able to find a relation that will allow you to predict the future.
Let your performance team assess the environment

5. Find a specialized company to run the load tests or select/setup your tool
When you don't have experience in performance testing, this is the part where you find yourself a skilled person or company.
Any company providing a decent performance test will require at least the previous 4 as an input and might even assist you to obtain results.
Other things to take into consideration when selecting a third party or tool
- Measuring points: where do you want to measure (web server, application server, load balancer, database layer,...) Note that every measuring point has impact on performance. A measuring point needs to be available in order to isolate a possible bottle neck.
-  Required automation work-arounds. The use of personalized security tokens might for example make life slightly more difficult...

6. Run the performance tests
- Performance intake
With the first functional code available, early analysis can be done at code and architecture/ design level to identify possible performance issues or risks. Performance defects found in this stage might still get prevented in stead of fixed and will therefore be less costly to implement.

Stress tests
  =>When and where does the system break? Identify the bottle necks and implement fixes where required.

Load tests
  =>To verify that you can run the different business processes, with an expected load of people using the expected on a production like environment

7. Result interpretation and presentation
- Isolate issues and investigate any issue before reporting it as a performance issue (many issues reside in the test, measuring points,...)
- Provide recommendations based on your results

No comments:

Post a Comment