This year I filed my taxes using a popular online web tax service and started to wonder how many other people were using the same services to do their taxes. There had to be millions. I looked it up – and according to the IRS over 80% of the 150 million tax returns that will be filed this year are expected to come in electronically. About a third of them – or 45 to 50 million – are self-prepared, online submissions from people like me.
It is hard to comprehend just how quickly the companies who provide these services (TurboTax, TaxSlayer.com, eSmart Tax, H&R Block, and many others) need to ramp up their operations every year. Taxpayers don’t receive their W2s and other tax documentation until the end of January, so there is virtually no activity in that particular month. Then, once people have their forms at the beginning of February, a huge spike in traffic occurs.
Online tax companies go from an absolute standstill to 100 mph in a matter of days.
How do these companies do it? Tax laws change every year, so that online application is basically a brand new release when users start pounding away at it in February. What is it like to test the performance of a website that sees a higher traffic spike than an eCommerce site on Black Friday – with no warm-up period preceding it? How do they get performance right the first time that they face an onslaught of users?
Odds are your industry does not bear the same extreme performance characteristics that these tax software providers face. However, you can learn a ton from their tried and true testing methods. We at Neotys encourage you to read on to see how your site can become truly bulletproof.
The Twin Peaks of Tax Season
You may not realize that taxpayer traffic actually has two peaks. The first peak occurs right at the start of February, with people who file as soon as they have their paperwork. These are the early-birds who want their tax refunds from the government as quickly as possible.
The second peak happens in the first half of April, as the rest of the population scrambles to meet the April 15 tax-filing deadline. For tax software companies, there are basically no site visitors until January is over. Then, the floodgates open. Forget the soft launch!
Faced with that initial and immediate spike in traffic, tax companies freeze their software applications until activity subsides. Environments are locked and change is minimized as January winds to a close. From a software performance perspective, there’s not much to do during this period of time. However, when the first wave of activity starts to die down in March, an opportunity arises to do a small release. At this point maintenance can be done on the site – patches and minor upgrades mainly – and all the data gathered during February can be put to use to fix lingering problems. Then it’s back to lockdown for the April filing peak.
Because of these dynamics, the critical time period for testing an online tax site is October through January. This is when all of the site’s core functionality and operating environments are tested, along with integration, load, and performance. The entire company has to rally around one thing: making sure everything is ready for that first day of February. Because that’s when the switch is turned on.
How To Build Bulletproof Testing Methods
If you want to be sure that your applications will remain high-performing even in the face of spiking demand, take a few tips from the people who operate online tax software. Put in place strong load testing, stress testing, and performance monitoring systems. Let’s take a look at a few specific guidelines in greater detail.
Load Testing With Agile Development
If you are using a load testing framework that has the right capabilities, you can get rid of a lot of the hassle of load test scripting by turning it into a click-and-script-only exercise. You record a script once, set up all the dynamic data and correlated data, save these items to the framework, and automatically apply them when rescripting. It minimizes manual work, allowing you to integrate load testing into your continuous integration process. Then you can compare the performance of individual sprint releases against each other with ease, and present the information to development teams in a simple report so they can analyze the data and make improvements.
Run lots of user tests for long periods of time. This will help to flush out memory leaks that may only present themselves after weeks of normal usage in production. Virtual users can help you avoid having to shrink think times (the time taken by the users to think or to navigate to different pages in the application) which can lead to unnatural issues with session counts, connections, and garbage collection. The more virtual users you can use, the closer you can get to simulating reality.
It’s common for load testing to get pushed to the end of a cycle, but you don’t have to let that happen. Use risk assessments and project prioritization to find testing activities that will add value without increasing resources. Design new tests to be executed during what is normally considered down-time. Instead of waiting for project leaders to give the go-ahead for testing, reach out to them early. This approach might allow you to proactively manage your workload and get more done.
Bandwidth limiting allows you to emulate connectivity from physical locations to see what real response times look like. You can identify bandwidth intensive applications that might consume the majority of the internet pipe and determine whether or not they are necessary. This technique lets you create conditions that mimic what your users actually go through, and it can help you identify a whole class of problems that would otherwise go unnoticed.
Automation is everything. Don’t stop with automating test execution – also think about how you can automate other typical tasks. A good place to look is your monitoring systems. As your server environment grows and changes, setting up new monitors can take time and resources. Manual steps associated with these changes introduce risk, opening the door for inconsistent monitoring that misses critical events. The ability to copy monitors (for multiple hosts) in addition to out-of-the-box monitoring for open source systems dramatically reduces the time to setup a test scenario. What took a day in the past can now be completed in less than an hour.
Troubleshooting In Production
When you are going from zero to 100 mph, you don’t want to leave anything to chance. So even when you are testing, you should look at all the performance data you would normally review in production. This helps guarantee that your production monitoring tools provide the detail needed for troubleshooting. Whenever possible, run at least one test from outside your firewall. Some issues can only be found using this approach. You should consider cloud testing for this strategy. You’ll also want to build a good test-in-production process to certify the production environment.
Performance Testing – Or Death For Your Product
Unlike death and taxes, performance testing is advantageous to make your site as bulletproof as possible. These tips will help you to plan early, subject the system to stress, and monitor performance so that you get as close to real-world as possible without having to subject actual users to performance problems. If you can make your site as rugged as tax software, you’ll be well-equipped for any scenario that comes your way.