Editorial note: I originally wrote this post for the Stackify blog. You can check out the original here, at their site. While you’re there, take a look at their offering that can help you with your own performance testing.
Software development, as a profession, has evolved in fits and starts over the years. When I think back a couple of decades, I find myself a little amazed. During the infancy of the web, hand-coding PHP (or PERL) live on a production machine seemed perfectly fine.
At first blush, that might just seem like sloppiness. But don’t forget that stakes were much lower at the time. Messing up a site that displayed song lyrics for a few minutes didn’t matter very much. Web developers of the time had much less incentive to install pre-production verification processes. Just make the changes and see if anything breaks. Anything you don’t catch, your users will.
The Evolution of Web Application Testing
Of course, that attitude couldn’t survive much beyond the early days of dynamic web content. As soon as e-commerce gained steam in the web development world, the stakes went up. Amateurs walked the tightrope of production edits while professional shops started to create and test in development or sandbox environments.
As I said initially, this didn’t happen in some kind of uniform move. Instead, it happened in fits and starts. Some lagged behind the curve, continuing to rely on their users for testing. Others moved testing into sandbox environments and pushed the envelope besides. They began to automate.
Web development then took another step forward as automation worked its way into the testing strategy. Sophisticated shops had their QA environments as a check on production releases. But their developers also began to build automated test suites. They then used these to guard against regression tests and to ensure proper application behavior.
Eventually, testing matured to a point where it spread out beyond straightforward unit test suites and record-playback-style integration tests. Organizations got to know the so-called test pyramid. They built increasingly sophisticated, nuanced test suites.
Web Application Testing Today
Building upon all of this backstory, we’ve seen the rise of the DevOps movement in recent years. This movement emphasizes automating the entire delivery pipeline, from written code to production functioning. So stakes for automated testing are higher than ever. The only way to automate the whole thing is to have bulletproof verification.
This new dynamic shines a light on an oft-ignored element of the testing strategy. I’m talking specifically about performance testing for your web application. Automated unit and acceptance testing has long since become a de facto standard. But now automated performance testing is getting to that point.
Think about it. We got burned by hand-editing code on the production server. So we set up sandboxes and tested manually. Our applications grew too complex for manual testing to handle. So we built test suites and automated these checks. We needed production rolls more frequently. So we automated the deployment process. Now, we push code efficiently through build, test, and deployment. But we don’t know how it will behave in the wild.
Web application performance testing fixes that. If you don’t yet have such a strategy, you need one. So let’s take a look at the fundamentals for adding this to your testing approach. And I’ll keep this general enough to apply to your tech stack, whatever it may be.