Instant coffee, Performance Testing, and the evolution of the Black Friday queues, Part 2

As promised, here is the second article of the series. In the first post, we reviewed 2015 Black Friday and made predictions for 2016, detailed the “what” of performance testing and why you should consider its business value.

We now move on to how to prepare your e-commerce business for Black Friday and beyond, while identifying and understanding the different types of performance tests and the gains attached to each type. Lastly, we’ll take a look at the future of performance testing.

 

It’s almost that wonderful time of year when you have to be prepared for the expected and the unexpected load. To make sure you are ready for 25th November, the date of Black Friday and the official start of the holiday season, we’ve gathered our recommendations in five practices that will help you to be ready:

1. Review your website statistics from the previous year/s.

The review phase helps you identify your user’s behavior and detail the calls and transactions they make. Analyze and determine your calls distribution – how many of your users search for products, view products specifications, how many make purchases – and link it with the number of transactions per second so you can estimate your load level.

By completing this phase, you will run tests in a more realistic manner, closer to the real user profile.

2. Set the load objectives with your business in mind.

You reviewed the last year’s statistics; what predictions can you make for this year? With the load from the previous year/s in mind, the changes in your traffic you observed in the last months, insights regarding users’ behavior (in the past years and months) and planned promotional tactics, you can set your load objectives.

3. Get your team together and plan the tests.

After establishing your objectives, share them with your team across all roles, and together plan which tests are needed in order to be prepared for the expected and the unexpected load. Testers, developers, QA or DevOps – they all should be aware of your objectives.

Mentioning DevOps is not a random fact. In addition to performance testing that investigates, determines and validates application performance attributes, other factors such as network strength, latency, bandwidth limitations, environment, infrastructure, components of the application service, proactive monitoring, and even people – with their knowledge, skills, and willingness to share information effectively – play a well-defined role.

There are several types of tests to be run, and we’ve already pointed out some of them in the previous article, but here we’ll go into more detail. Use these details to understand performance-related tests and make more informed decisions about which of them (and when) add value to your project.

Let’s get started.

Load tests

Put simply, load tests help you understand the system’s behavior under a targeted load in normal and peak conditions. Load testing allows you to investigate and validate if the application can meet the established performance objectives and enables you to measure normal performance metrics such as # Response time and % Resource utilization level.

The main benefits of load testing are related to finding functionality errors under load, collecting data about scalability, establishing how many users can the application handle before performance is affected. However, for a thorough analysis, all the results should be compared with other related load tests such as capacity tests.

Capacity tests

Complementary to load testing, capacity testing helps you identify how many users your application can handle before performance or stability becomes unacceptable. By knowing the number of users your application can handle successfully (meet performance goals), you will understand what might push your application beyond its limitations.

The main benefits of capacity testing include gathering information about how the load can be handled to meet business requirements and expectations and detailing a scaling strategy.

Stress tests

During Black Friday and the holiday season a website endures more stressful situations than ever; it’s the time when you don’t want it to be down. As we’ve seen in the previous article, even a few minutes of downtime are extremely costly. Dealing with the superior limits of capacity, stress testing evaluates how well the application will perform if it is pushed beyond the maximum limits, above and beyond normal or peak load conditions.

The objective is to reveal your application weak points and errors, such as which part of the application fails first, how it behaves under extreme load conditions, how does it recover after the failure, so you can fix them at the right time.

The main benefits covered by stress testing include collecting data about how far beyond the target load an application can go before causing failures or errors and what types of failures are the most important to prepare for.

A part of stress testing is spike testing. A spike test focuses on determining/validating the application stability and performance characteristics during a load that continuously increases beyond your expectations and above maximum design capacity within a highly short period of time. By running spike tests you can look for the application not to crash.

Peak tests

While spike testing helps you investigate how the application responds to a massive number of users suddenly generated, peak testing helps you inspect how it works during the most challenging periods. It is similar to endurance testing, but with much heavier load and shorter duration.

Endurance tests

Application stability is another performance factor. It is important to determine how able is an application to endure continuous high load while it’s performing efficiently.

Ideally, at the end of the endurance test, the application performance is the same as the performance from the beginning of the test. For example, if the response time for the login button is 2 seconds and it keeps the same response time after 10 hours, the application is stable.

As performance tests consists of a generous activity that can address many risks and provide a wide range of value to the business, such as risk mitigation and costs optimization, it is important to understand the different types of performance testing. Here’s a close-up:

Two extra hints. When you plan your performance tests, put yourself in the shoes of the user and:

  1. Test from different locations. Your customers do their online shopping from their offices or from their homes, not nearly to your data center. Where are they? Everywhere. Every customer is in a different location and has a different experience, and by testing the behavior of the application from various locations, you’ll understand their various experiences.
  2. Test on different devices. Desktop, tablet, mobile. Plus, different operating systems. There’s a tremendous range or experiences, so you need to test some universal combinations.
4. Run the tests.

After you’ve planned your tests, you can run them. If your system successfully responds to your established objectives, don’t chill out, test more. If you know what your system can do and what it can’t do, you’ll know how to manage the real situations.

5. Assess the results, repeat the tests, make the changes and enhance the customer experience.

Where do errors appear? Which solutions do you see feasible? Look at all your performance objectives defined as quality attributes. What are the results? Adjust tests and repeat them to see if the changes bettered the application; the mission is to enhance the user experience.

The future of performance testing: Shift left

Any organization with an open, quality and customer-oriented culture approaches performance testing in the early stages of the project. Performance testing, in contrast with what users expect from applications, is not like instant coffee. It needs more brewing time, as it is rather an iterative process, not an isolated event.

Embed testing in your development process from the early phases and build it into every aspect of your development cycle (different types of testing we’ve presented earlier will be inserted in the development process at different points). As a matter of fact, every application must be built with performance testing in mind, starting with the architecture phase. Think how you can scale up the architecture to support hundreds, thousands of users.

Test constantly. Repeated tests give you the opportunity to use new and actionable data for continuous improvement. An application’s overall success depends on the information picked out from your testing process.

The “why” of running performance related tests from the beginning of the application is straightforward: errors can appear anytime, but if you identify them sooner, they are easy to approach and easy to fix. This way you save time and money in the future, deliver a higher quality application which leads to a more pleasant customer experience, increases customer satisfaction and contributes to the overall revenue.

Final thoughts: It’s always Black Friday somewhere

Start seeing performance testing as a journey and not as a destination. It doesn’t begin and it doesn’t end with Black Friday and the holiday season. It’s always Black Friday somewhere. Maybe it’s called “VAT free Friday”, maybe “Black Week”, or maybe your promotions are so effective all year around that they result in a flood of customers. Even if your code has not changed, the data used by the application might, and performance could be affected as a result. The more you investigate your application behavior and the more you know about the way it behaves, the better prepared you will be for potential challenges.

Your attention to performance testing will make your applications better, your users happier and your career as a Performance Tester, QA Manager, Test Manager and even as a CMO more fulfilling as your website won’t be mainstream news for performance issues.

Ready to start performance testing?

Note: This article is part 2 of a two-part series. You may also want to read the first post in this series here.