One important organisational point of Agile API delivery is the concept of a team producing a usable version – which should result in the improved alignment of development, QA, and technical operations teams. Perhaps an even larger benefit of Agile is that it allows teams to effectively manage change in both external and software functionality, while simultaneously accelerating the development of quality software. Part of the challenge with managing this change, however, is providing quick feedback on when the change in software happens, and its resulting impact.
You may be familiar with the mantra, “test early and often.” It’s an approach that is closely aligned with the waterfall methodology. In waterfall terminology, “early” means “before the software is transitioned to QA.”
This mantra is largely inaccurate when it comes to API performance testing in Agile. Instead, with Agile, you test all the time. This means designating a resource who will be responsible for the testing, and tightly involving all stakeholders – including those on the business side. Typically, functional testers define functional tests to match the sprint functionality. If you’re doing functional testing, there’s a great opportunity to introduce performance testing scenarios too.
Here are four handy suggestions for Agile load testing to help you get started.
#1 – Test Your API Incrementally
Incremental API testing starts at the lowest functional levels. First test a small function, and then build from there. If all the individual components function and perform correctly, chances are they will work well together and this knowledge will help you analyze and debug performance bottlenecks when you test at the system level later on.
Look at performance testing in Agile as testing of different performance layers that can be approached in an onion-like fashion in the rhythm of your sprints. To achieve flexibility, you also need to plan your performance testing efforts and break a bigger challenge into smaller tasks. As a comparison, it is difficult and expensive to solve a 12 man-year problem at once, but one can solve 12 one man-year problems in sequence. The same approach can be applied to signing off the performance of an application.
#2 – Establish Performance Goals
Create API performance tests to work alongside your functional tests, while also incorporating the performance test into your build process. Start by establishing performance goals when writing user stories.
For example, let’s say you’re creating an API for an online store. You want a user to be able to add an item in their cart, and you also want to verify that this request takes no more than half a second to process.
Creating your performance test alongside your functional test allows you to continually measure the performance of your API.
#3 – Reuse Functional Tests
Always check to see if you can reuse existing or future API functional tests as performance tests. It may be possible to incorporate timers into an automated test to give you a feel for how the application is responding. You can review your functional tests with a designated performance expert and make the decision, or you can utilise tools like SoapUI NG Pro (API functional testing) and LoadUI NG Pro (API load testing), which allow you to efficiently reuse tests in the same software platform.
Reusing functional tests whenever possible is one of the key anchor points for Agile performance testing, driving the development of work scenarios for later use as the workload of more in-depth load tests.
#4 – Include API Performance Tests in the Build Process
Finally, you should include your load tests in the build process so that each build goes through some level of performance testing. By doing this, it’s going to be easier to determine what caused the slowdown in your application’s performance. Also, if you need to roll back to an earlier build, you know how well that particular build performs because you’ve already tested it.
This post was originally published by SmartBear here
