Software testing - Is it different in Agile projects from traditional projects?

"Yes", There are lots of differences in testing an application in agile methodologies and in traditional projects. To have a comparative study lets consider Agile Scrum as base

"Sprint team should ship a workable product at the end of each sprint" is the purpose to adopt the Agile methodology.

Documentation Challenges:

Agile project follows minimum documentation so each time test team have to liaise with Dev, Product, System Analyst to get their queries clarified. (Depending on nature of queries). This slows down the test prep phase and sometimes understanding gaps. So testers have to be a quick learner to overcome these kinds of hurdles.

Estimation:

Estimation used in Agile projects is Poker planning. This requires knowledge of application under test. This imposes a barrier on new team members in participating in estimations, poker planning and sprint planning sessions.

Review of Test Deliverables:

In Waterfall or other project methodology, we allocate special time frame for Review, Rework and Sign Off of Work Products. But in Agile, we follow generally a sprint cycle of 2 weeks or 4 weeks. In such a short span of time, it’s very difficult to follow a detailed review process. This may impact in missing some test scenarios. So tester should be competent enough to not to miss any scenarios and should give a full test coverage and assure a quality product.

Solution to this review process could be selective review of functionalities. Business critical functionalities should be reviewed irrespective of time crunch issue.

Retesting after Demo:

In Agile Scrum, QA Points provides the demo of functionality to product owner and sometimes product suggest the changes after demo is completed successfully. This creates additional burden to QA Team to complete the testing. (retesting the complete functionality)

Regression Test Efforts:

In each sprint, some enhancements are delivered. Regression testing is required to show that these enhancements are not impacted the current functionality. In turn regression testing is required irrespective of 2 week / 4 week sprint. If regression suite test count is too much then this will delay the test certification and project delivery.

To reduce the regression testing window, automation of regression suite is necessary.

Updating of Test Documentation / Regression Suite:

In 4 week sprint cycle, it’s very challenging to update the existing test documentation (master test plan, test strategy) and regression suite. So at any point of time these are not updated and team need to follow a sperate plan to keep these test deliverables.

This achieved by adding a tech deb task in, in between sprints.

Resource Management:

If a resource goes on leave for more than 3-4 days in a single sprint, then this creates a burden on other testers. Because of this there is risk of not meeting the commitments by the sprint team.

As sprint cycle is very short so this kinds of issues are very frequent.

To summarize, to perform the testing in Agile Projects: - Testers have to be quick learner, 'can do' attitude of work and a good team member with excellent work ethics.

"It’s not every one's cup of Tea :)"