Your testers have verified that everything works as expected. Your developers have fixed all the bugs that your testers have found. Your roadmap looks great and your’e ready to release ahead of schedule.

But then there’s the final hurdle: user acceptance testing.

Apart from a few typos, and minor usability issues that can be addressed in a later release, there is one glaring complaint:

When real world users test against real world data in a real world environment – they all say:

It’s too slow.

What can you do? Refactoring the architecture is needed, but why didn’t testers notice this in QA? It will take weeks to profile, and maybe months to fix the problem.

Functionally — technically — everything works as expected. But performance testing against a production load wasn’t done until the end. How could it be?

At One Shore, we can help you integrate performance and load testing (they’re not the same thing) into your testing delivery pipeline. Like all other bugs, performance bugs are easier to fix when they are caught earlier.

By adding performance checks to your functional testing flow, your can get application performance data early to optimize (or cut out) features that are too slow. And by load testing before releasing to production, in environments that look like production, you can find those architectural bottlenecks that are so hard to fix when it’s already released.

You’ll need production-like test data, but you can’t wait on real users. You’ll need to generate data that looks like production, or migrate production data, but mask it so that no sensitive information is leaked. And you’ll need to generate a significant load to spot those issues where memory, disk io, or CPU become bottlenecks under traffic spikes (like Black Friday or Tax Day) that your normal load could normally handle.

If you have performance and load problems already, don’t despair. There are steps you can take to combat the problem methodically, and to reduce the chance of a similar disaster again.