02-08-08, 10:59 AM
Virtual Web Designs are currently in the process of building a bespoke multi shop eCommerce website which will access all it’s products from one database (6 different url’s). Testing will be a major part of this website build. So we though we would share some of our thoughts on how we will go about testing this sort of eCommerce website.
Although a lot of time and consideration is usually spent on preparing the creative side and content aspects of websites, functionality and web application testing is often neglected. This can be an oversight for which a company's reputation may pay dearly. According to the research, bugs found after release can not only spell doom for a project, but also cost 80 to 1,000 times more to fix than if they were found during pre- deployment testing.
Usually the best way to ensure web applications meet the demands of visitors, while meeting internal deadlines, is to keep testing simple. Here's an analogy: in order to check the plumbing of a major sports stadium in the US on the eve of opening day, the entire workforce got together and flushed the toilets simultaneously. This simple, labour intensive approach is often used to load-test new web applications, with lots of people asked to log in at the same time. However, not only is this approach logistically challenging, it's often impossible to realistically simulate the number of users who might hit the site.
This is where Rapid Bottleneck Identification (RBI) comes in. Every web application has at least one bottleneck— an element of hardware, software or bandwidth that places defining limits on data flow or processing speed. In addition, applications are only as efficient as their least efficient elements, and it's here that bottlenecks directly impact on performance and scalability.
While the best testing should be quick and simple, it needs to be thorough, which is why RBI is a great testing methodology for web developers.
Back to basics
Performance testing often begins with scenarios that are overly complicated: exercising too many components makes it easy for bottlenecks to hide. By starting with basic system-level testing you can check the web application's performance before it's even deployed.
Furthermore, applying a modular approach helps simplify things. You start by testing the simplest possible test case and gradually build in complexity. If this works, testing moves on. If the next stage fails, you can identify where your bottleneck is. What's useful about the modular method is that after uncovering each bottleneck, you've already ruled out previously tested components. For example, if you hit the homepage and encounter no problems, but then decide to execute a search, which shows poor performance, you've established that the cause of the bottleneck is the search functionality.
All performance testing should begin with assessing the basic network infrastructure supporting the web applications. If this cannot uphold anticipated user load, then even an infinitely scalable application will bottleneck.
Next, it's time to focus on web applications. The approach, again, should be to start with the simplest possible test case and then to add complexity. For typical eCommerce applications this means testing the homepage first, then adding pages and business functions until complete transactions are being tested, first individually and then in complex scenario usage patterns.
Once this is complete, transactions can be put into scenario concurrency tests. These must reflect real user behaviour (for example, 50 per cent just browse, 35 per cent search, in per cent register and log in and five per cent add to the shopping cart and make a purchase). But the virtual users who are testing the site must execute the steps of those transactions using the same pace and behaviour as real-world visitors.
Testing is a bit like insurance — usually you don't realise it's not good enough until it's too late. So, whether or not you conduct performance testing in-house or via a managed service, it's important that it's done methodically and rigorously.
Although a lot of time and consideration is usually spent on preparing the creative side and content aspects of websites, functionality and web application testing is often neglected. This can be an oversight for which a company's reputation may pay dearly. According to the research, bugs found after release can not only spell doom for a project, but also cost 80 to 1,000 times more to fix than if they were found during pre- deployment testing.
Usually the best way to ensure web applications meet the demands of visitors, while meeting internal deadlines, is to keep testing simple. Here's an analogy: in order to check the plumbing of a major sports stadium in the US on the eve of opening day, the entire workforce got together and flushed the toilets simultaneously. This simple, labour intensive approach is often used to load-test new web applications, with lots of people asked to log in at the same time. However, not only is this approach logistically challenging, it's often impossible to realistically simulate the number of users who might hit the site.
This is where Rapid Bottleneck Identification (RBI) comes in. Every web application has at least one bottleneck— an element of hardware, software or bandwidth that places defining limits on data flow or processing speed. In addition, applications are only as efficient as their least efficient elements, and it's here that bottlenecks directly impact on performance and scalability.
While the best testing should be quick and simple, it needs to be thorough, which is why RBI is a great testing methodology for web developers.
Back to basics
Performance testing often begins with scenarios that are overly complicated: exercising too many components makes it easy for bottlenecks to hide. By starting with basic system-level testing you can check the web application's performance before it's even deployed.
Furthermore, applying a modular approach helps simplify things. You start by testing the simplest possible test case and gradually build in complexity. If this works, testing moves on. If the next stage fails, you can identify where your bottleneck is. What's useful about the modular method is that after uncovering each bottleneck, you've already ruled out previously tested components. For example, if you hit the homepage and encounter no problems, but then decide to execute a search, which shows poor performance, you've established that the cause of the bottleneck is the search functionality.
All performance testing should begin with assessing the basic network infrastructure supporting the web applications. If this cannot uphold anticipated user load, then even an infinitely scalable application will bottleneck.
Next, it's time to focus on web applications. The approach, again, should be to start with the simplest possible test case and then to add complexity. For typical eCommerce applications this means testing the homepage first, then adding pages and business functions until complete transactions are being tested, first individually and then in complex scenario usage patterns.
Once this is complete, transactions can be put into scenario concurrency tests. These must reflect real user behaviour (for example, 50 per cent just browse, 35 per cent search, in per cent register and log in and five per cent add to the shopping cart and make a purchase). But the virtual users who are testing the site must execute the steps of those transactions using the same pace and behaviour as real-world visitors.
Testing is a bit like insurance — usually you don't realise it's not good enough until it's too late. So, whether or not you conduct performance testing in-house or via a managed service, it's important that it's done methodically and rigorously.
Support
Webnetics UK Ltd.
Webnetics UK Ltd.