AGILE & Performance testing

In case of waterfall or other traditional approaches, we observed that each phase of the development process was allocated a time line and that phase was carried out based on the schedule laid much earlier in the project. Testing (and thus performance testing) came almost in the end of the cycle when app was first ready and then later when app was made changes (after bugs published in the first testing cycle). Testing in AGILE method follows a slightly different approach though. Here the activities related to testing the app begin right in the beginning of development and as soon as the first version of the app is made available, the testing is started.

Some key performance tests that are expected to be conducted in the Agile Dev Cycle –

This unique way of testing provides an opportunity to test the app such that different modules / functionalities (those developed in the early releases) get tested in isolation. It is like choosing some business processes and executing tests against those. This type of testing not only resolve issues associated with app design / architecture at a much early stage but also makes the application quite robust yet simple. Same goes with performance tests, as a new app is planned and activities related to its development are started, performance test planning and infrastructure set up also begins and right after first release (it may not yet be production release), the app is tested for its performance. Most of such tests would be nothing more than the tests designed to find bugs and bottlenecks by proactively searching for performance limits. It is here when the test driven development, risk based approach is followed and the app is critically tested for its more probable and highly impacting areas.

These tests are performed one after another in iterations till the performance issues are resolved across all different sprints.

Here are some key steps followed while performance testing an app in AGILE –

  1. Project Vision: While starting on a performance testing project, it is essential to understand the main objective out of the test. The objective can be either of the following –
    1. Evaluate the new application being developed
    2. Re-engineer an application to improvise it further
  2. Project Goals: These are some key factors essential for achieving the vision. The key factors that are most important for performance testing are discussed in this phase of testing. Some of these factors are –
    1. Response time expectations of the client
    2. Capacity requirement of the business
    3. Timeline of application buildup
  3. Business value: Once the project vision and goals are understood, the business value of the performance testing activity is judged and knowledge regarding the application under test is acquired by the stakeholders involved.
  4. Test environment: The infrastructure and environment is setup for testing and as soon as the first version of the software is released (may not be a production release), the Agile performance testing is kick started.
  5. In this step the tasks associated with performance testing are all identified and then are delegated amongst the team members.
  6. All the tests involved in the performance testing cycle are executed in this step.
  7. Results are then analyzed and reports are created.
  8. Results are then compared against the SLAs and business requirements and checked for its performance criteria.
  9. Based on the priority of the performance issues, the issues are then fixed and as those are fixed next round of tests are performed.

Some additional ‘Points to consider‘ while doing performance testing in AGILE:

  • Over-communicate: Always communicate every key finding with all the team members.
  • Performance testing cycle is a time consuming activity and hence no matter what performance testing sprints will always lag behind the actual product development sprints
  • Try to build a regression suite which can be re-used again and again as you proceed in your testing for next releases.
  • You must compare results out of each build, with the business targets but comparing those against earlier releases is also important. It gives an idea about what change led to which business objective improvement.