QA challenges with agile software development

What are the most common agile testing challenges faced by software testers or QA in agile projects? What is it like to be a QA in an agile team?

Ever since agile development methodologies were introduced in software development, the role of QA in agile projects has changed considerably. There is no longer a team of QA sitting in a corner, away from the developers and designers, waiting for the development team to handover a piece of work for testing.

One of the most important elements for QA in agile projects is having a good understanding of the agile development methodologies and processes. Many agile companies follow the Scrum framework for delivering quality software, so ensure you are familiar with Scrum.

Agile Testing Challenges

The very essence of agile development is delivering working software frequently, each time adding or enhancing a small feature which is of value to the customer. That itself poses a lot of challenge not only for testers but also developers and anyone else involved in the delivery of application.

In this article I list some of the most common agile testing challenges for QA in agile projects and how to overcome them.

Changing Requirements / Last Minute Changes

Changing requirements or dropping stories mid-sprint is not uncommon in agile projects. This can be a nightmare for the whole team as it means that the work already carried out might be scrapped completely or changes should be made to what’s already half done.

These requirement changes and last minute requests can affect the scope of testing which can frustrate testers.

How to overcome:

Testers should be able to respond to change, knowing that in agile projects, change is inevitable. When requirements change especially towards the end of the sprint when there is not enough time to test adequately, testers should provide as much information as possible about what tests have been run and which part of the application hasn’t been tested well so that the team can make an informed decision (possibly based on risk) whether to release the feature or not.

Try getting the developers involved in testing as well, as testing and quality should be the whole team responsibility.

Not Enough Information on the Story

There will be times when a product owner who writes user stories, has some idea about a new feature but doesn’t have all the details to write a good set of acceptance criteria to fully define the behaviour of the feature. They ask the development team to create a prototype so they can get more ideas about the functionality and behaviour of the feature.

This creates a challenge for testers because there is a lack of understanding and requirements, so proper test cases can’t be constructed.

How to overcome:

You don’t need very detailed requirements to start testing, so start by thinking about high level scenarios that test the concept of the story, rather than waiting to get full clarification about the feature. By drafting high level test scenarios, even when the details change, the context should still be the same.

Continuous Testing

In agile, testing is not a phase, it’s an activity. Testing starts from the very beginning, even before the development starts.

In order to have a smooth ride during the sprint, the stories in the backlog should have been elaborated during the story grooming sessions. This means the QA should collaborate with product owners to learn the details of the story and then help write good acceptance criteria.

Providing early feedback to developers is crucial and challenging for testers. As testers, not only we have to make sure that the new feature works as specified according to its acceptance criteria, we have to also make sure that the new code hasn’t broken existing functionality, i.e. we haven’t regressed, and we have to provide this information quickly.