5 Ways to Shift Performance Testing Left | TechWell

5 Ways to Shift Performance Testing Left

Left arrow painted on a wall

Performance testing is often a barrier to accelerating software delivery. Much like testing other nonfunctional requirements, application performance has traditionally been measured late in the software development lifecycle, as a finished application and a production-like testing environment is necessary to get valid performance results.

While it is true that performance testing cannot be finished until the entire application is complete, there are many ways to get started earlier. Doing so will reduce the rework necessary to address performance issues and accelerate delivery. Here are five ways to start shifting performance testing left.

1. Profiling code

There are lots of reasons your application may not achieve its performance goals for capacity, scalability, or responsiveness, and one of them is certainly the speed of your application code. Profiling your code during continuous integration activities and locating algorithms, functions, or components that are bottlenecks to overall performance help considerably. Identifying these areas and refactoring them as you go will reduce the likelihood of finding out late in the process that your application is too slow.

2. Using incremental performance analysis

While it is true that measuring the performance of your application against its performance requirements is only valid when done in a production-like environment, this does not mean that doing performance testing incrementally as you build your application isn’t useful. Instead of focusing on whether early lifecycle performance testing meets your performance goals, track relative performance over time as new features are introduced. If you see significant changes in the response time or overall speed of the application, it is wise to dig in immediately and find out what is happening. This type of performance testing is often done through the user interface (UI) so we can measure the relative response times we are seeing in distributed applications between components.

3. Performance testing below the UI

Incremental performance analysis should be done below the UI, too. Much like your automated functional tests are less brittle and run faster when implemented below the UI, the same is true of your performance tests. Create performance tests along with your other component and API tests to make sure they get run as you test continuously. If your performance tests don’t run fast enough to perform during check-in builds, run them as part of the regression testing you should be doing daily to make sure new functionality doesn’t break something else.

4. Leveraging service virtualization

Often when building applications incrementally, we don’t yet have particular services or components that our application needs to execute and measure performance. The best way to address this is to leverage service virtualization to emulate or simulate those services we have yet to build. Doing so allows us to measure the relative performance of our application as we build it using the approaches discussed above.

5. Shifting production-like environments left

Ultimately, the best way to effectively conduct performance testing earlier is to provide developers and testers with production-like environments to use for testing. This allows teams to measure performance against service-level agreements and requirements earlier as well.

Up Next

About the Author

TechWell Insights To Go

(* Required fields)

Get the latest stories delivered to your inbox every week.