Web Performance

Keeping Customers On Your Web Site Though Web Load Testing

Customers will not stand for slow reaction times on a web site. Companies only have a few moments to display a page or complete a transaction before a customer gets frustrated and surfs away to a competitor.

To make sure a company’s web application keeps customers and does not turn them away, a company has to test for the number of customers that may hit a web site.

If you are concerned about satisfying your customers demand for a fast and smooth web experience, then automated software testing provides a way to develop good web application performance.

Lets assume that your web application has been functionally tested, meaning all user-initiated actions produce the expected results. For example, when you want to buy and sell stocks on your online brokerage account you go through several steps. Logging into the account, looking up your portfolio, viewing market data, selecting a stock to sell or buy and lastly completing a stock transaction.

A web application may be functionally perfect (a user can complete his brokerage transaction online,) but under certain load conditions, the user’s experience can become so unacceptable he does not complete that transaction, or worst, the web application cannot serve the user because it is too busy dealing with processing other user requests.

For a web application to perform well, the application must serve all customers at the same time with a minimum standard of performance.

A customer’s web experience depends upon the performance of the following components of a web application: efficient software, well-designed database transactions, properly tuned web and application servers, and network infrastructure all impact performance.

To test the performance of your web application, you will want to understand the behavior of all those components during a load test, or you may not find the bottleneck that was the cause of the bad web performance.

In addition, web applications change over time, for example at the online brokerage, a new portfolio of mutual funds is added. Your company will have to plan for a change such as the number of customers and infrastructure enhancements to the web application.

Options for testing a web application include manual testing for limited user load levels, however, this quickly becomes impractical when reaching higher loads that would require coordinating several hundred people to log onto a brokerage account at precisely the same time.

Another option is using testing software, since the start of the web, programmers have built in-house test scripts to test their applications rather than manually test.

Lastly, you can use commercially available web load testing tools.

Automated tools let you build, record and customize testing scripts. Similar to a Macro in Microsoft Word, or a recording cylinder on an old player piano, these software tools let you record the whole process of completing a stock transaction. Once recorded, you can alter the script to simulate 10’s, 100’s or 1000’s of customers completing a transaction.

You can use the tool to run different testing scenarios, from buying a stock to selling a stock, and run various combinations of those scenarios at the same time in order to simulate the reality of what the online brokerage would face on a typical day.

One example of a tool is QuotiumPRO from Quotium Technologies; their tool allows you to easily create and monitor load scenarios for eleven different databases, web and application servers, and network components running your applications back office.

Other benefits include: accelerating a site launch date by allowing testing throughout development. Increasing the number of defects found during testing. Providing organized, detailed test logs and an audit trail of executed tests, and lastly graphical reports.

Poor web performance can directly hit the bottom-line and will always affect the perception of your company’s brand. There are several automated tool vendors to consider from Massachusetts including: Quotium Technologies, Segue, RadView and Empirix. Others: Mercury Interactive, Rational and Compuware.

10 Step Guide to Web Application Testing

Pavankumar Pothuraju's web blog has a useful 10 step guide to testing your web application.

"In performing load testing, you want to simulate how users will use your web application in the real world. The earlier you perform load testing the better. Simple design changes can often make a significant impact on the performance and scalability of your web application."

Testing Purposes

I came across this quote on Chris Chappell's website at Microsoft, I thought the quote was interesting and wondered if you the reader agreed with the statement?

"Trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more...

If you want to lose weight, don't buy a new scale; go on a diet.

If you want to improve your software, don't test more; develop better."

When to test your web application

When thinking about how to test your web application, you should start early so that you can avoid producing defects and bugs. The requirements stage of the software development process is one area of the process where you can easily develop errors by not correctly understanding the user's requirements.

Performance Test Tools Only Work When You Plan

Robin Goldsmith in our interview together last week talked about the importance of developing an effective testing process.

The effectiveness of both functional and performance testing depends primarily on having an effective testing process. Everyone says this, but for most folks it’s only words. A testing process defines what needs to be tested. An automated tool can’t do that; it only can assist the execution of the tests that have been identified. Proactive Testing as we present and practice it not only helps focus effort on the most important testing, but identifying reusable test designs can greatly enhance the speed and quantity of test automation; and most importantly, Proactive Testing helps developers speed delivery by preventing rework and showstopper errors.

I can basically say that you have to remember even when you have automated tools such as QuotiumPRO from Quotium Technologies or Segue's SilkPerformer, you have to develop a good criteria and framework for what you are going to test. The testing tools help you test but your expertise comes into plan with the planning stage.

Collaborative Testing

Jonathan Kohl writes.

Testers who have strong development and testing skills (and who understand and have insight into TDD, bad coding smells, interface discovery, etc.) should fit well into both categories - generative and elaborative. Most testers I might wager, will fit in better in the elaborative test development aspect of TDD. We are used to Business-Facing Product Critiques, and test idea generation activities. Generative test development will probably be new to many dedicated testers. If you want to pair with a developer doing TDD, this might be something to keep in mind.

An interesting discussion on the subject of how you should test and the approaches to testing.

Performance Testing of Application Architectures

I recently found this great article about the performance testing of web applications from downunder.

UCMs

Renaldy Bodhiwan attended a load testing lecture and had a few comments.

So I have a basic understanding of how to use them and when. First, you get ur conceptual architecture. This is a structure for your system. Then you identify some key scenarios. These scenarios like use cases with the system. Where as use cases look at the system from the outside, as it interacts with users, UCMs look at how the system handles it on the inside. That is, how the structure handles it.

IEEE 829 Test Plan

According to the IEEE 829 test planning process there are eighteen factors to consider in building a success testing plan

1 Test plan identifier. 2 References 3 Introduction. 4 Test items. 5 Features to be tested. 6 Features not to be tested. 7 Approach. 8 Item pass/fail criteria. 9 Suspension criteria and resumption requirements. 10 Test deliverables. 11 Testing tasks. 12 Environmental needs. 13 Responsibilities. 14 Staffing and training needs. 15 Schedule. 16 Risks and contingencies. 17 Approvals. 18 Glossary.

Web Test Results For Your Entire Environment

Testing the load of your web applications is very simple. You want to know if your server can sustain the number of requests customers are sending to the servers in your web application environment? If not, you want to know where the problem lies.
Servers in your web application environment may include the application server, the web application server and database server.

An automated web load-testing tool should allow you to test if multiple requests to an application server can be handled in a timely manner. If you have a web application environment with several components, you want to discover if there is a bottleneck within your application environment. However, if you are not monitoring all of the components of the web application environment, you will not understand the root cause of the problem.

When testing a web application with different layers, a database or web server, to get to the root of the cause of a bottleneck, you really have to monitor the different components of the system in one place.

If you don’t run a test across the entire web application environment within the same automated testing application, you will not capture results for every layer of your web application environment at the same time. Your reporting results will not give you a complete overview of your web application environment at one point in time, you will only have part of the picture.

Monitoring each component, or one or two components separately will tell you individually how a particular component is functioning. You will not understand how each component sustains a load when integrated within the entire web application environment.

Therefore, I think many developers make the mistake of not considering their whole environment within a testing framework. If you are going to use an automated testing tool, I’d suggest seriously consider the consequences of not load testing every layer within your web application environment within one load-testing tool. If you do use one tool to test your entire environment, every layer’s results will be integrated with your overall results. You will have a true picture of your entire environment and be able to analyze the reported results together if everything is tested within the same tool set.