You are using an older browser that might negatively affect how this site is displayed. Please update to a modern browser to have a better experience. Sorry for the inconvenience!

Performance Testing in Agile Development Cycle


Introduction:

The water fall model is getting replaced with agile/scrum model which is the latest trend in the software development. The huge competition for faster delivery of products in the market to the customer is the reason for change behind this. When faster delivery plays the vital role, there will surely be a critical need for maintaining the performance standards. So, this article will help us to learn more about the performance testing which is also included as a part of agile processes. The goal is to test performance early in the development effort and to test functionality and performance in the same Sprint.

Performance Testing in Waterfall Model: 

Performance testing is referred as NFT means Non-Functional-Testing in water fall model and it will usually take place only at the end of the regular testing cycles which will be executed between testing and deployment. The main aim is to detect the performance issues in the software developed like memory leaks, system performance which do not meet the required key performance indicators, problematic queries etc.,

Problems in executing Performance Testing in Agile:

In agile approach, we cannot execute performance testing likewise in water fall method as the development cycle is very short and delivery of the product to the customers are very frequent and rapid. So, performance team cannot wait until the full product is developed.

Changes for Performance Testing in Agile Model:

Performance requirements should be outlined on a high level in the beginning of the feature layer. Performance requirement should be part of the definition of ‘DONE’ for a sprint. Only when performance requirement is met, the sprint should be ‘DONE’. We will need an approach which can help us introduce performance testing quite early rather than following the big bang approach (Sprint Hardening) of conducting performance testing at the end of the sprint, as it delays time to market for product and will be more expensive to incorporate changes at a later stage as explained earlier. Introducing performance testing in Agile is very difficult because its main input will be a fully developed and functionally stable product so that performance testing can be done in a useful way.

Challenges in SCRUM model:

Shorter Development Cycles Require More Tests in Less Time:

Load and Performance testing should be initiated until the last day of the sprint or sometimes it should be done every other sprint. This may end in code being released without being adequately tested or the stories may slip to the next release once they have been tested. In order to overcome this, testing can be done earlier in the development cycle, but that’s not so easy because the team may lack with the resources and tools to make it happen.

“Working” Code Does Not Always Perform Well:

The developer in Agile teams will put their maximum effort in delivering the working code, but will the code really work if it is put under load? Let’s think before closing a story and changing its status to “Done” what if the application/ code crashes when it is put under load say 100 users?  Then the huge number of users say 1000, 10000?? Etc., Always developers have pressure to get the code out of the door is high, but the same clients will expect high-quality products from all aspects.

Real Agile Approach for Performance Testing:

If performance testing is introduced early during the development phase, then we will need to take the below points into consideration:

  • Performance testing or response time testing for every newly developed feature during the sprint.
  • Performance regression testing for the system integrated with every newly developed feature.

Upon completion of a functionality or feature, the performance or response time is tested to understand how much time it’s taking to perform its functionality. Similarly, when the newly developed functions get integrated with the overall system, performance testing should be conducted only to cross-verify that the newly developed features do not bring any performance bottle necks to the overall system behavior. Performance testing during the regression phase will also help identify any configuration, sizing of hardware and infrastructure issues.

Advantages of agile performance testing approach:

Early Performance Checks:

As performance tested early in the software lifecycle, robust code and functionality can be delivered before releasing the product.

Cost Savings:

As performance is considered early in the software lifecycle, testing can help avoid critical code changes starting from end to end or software changes.

Time Savings:

As performance is conducted in parallel to software development and within the sprint, time to market can be reduced in delivering the release in comparison to the waterfall approach.

There may be some disadvantages too:

Less Emphasis on Documentation: The agile approach does not push towards documentation. This may sometimes in rare cases create a big deal if a team member leaves during a sprint and a newly joined team member would need time to come up to speed with the project.

Conclusion:

Thus, including Performance testing in projects using agile methodologies should become a practice to deliver the project with a good quality without any performance bottlenecks.

Ref links: http://www.agileload.com/performance-testing/performance-testing-methodology/performance-testing-in-the-agile-process

https://hubpages.com/technology/Agile-Methodology-A-Brief-Overview