In this post, we'll look at testing in an Agile environment. In subsequent posts, we'll explore this subject some more. Here's a link to an earlier post on Agile Development and Testing, if you are interested.
How different is agile testing from non-agile a.k.a. traditional models? Well, for one - in Agile, testers are involved all through the release and not restricted to a specific "phase" in the development cycle. Testing occurs through each iteration or Sprint. Testing like Development, is flexible and can/should accommodate change. Also, there is a higher degree of collaboration across functions in agile where all members (Dev, Test) are part of one scrum team and not viewed as distinct members belonging to separate functional groups.
Testers are involved in release planning, reviews of stories, estimation, risk analysis and defining acceptance criteria for each story.
In an Agile team, testing doesn't wait until Development is "done". Test types may overlap at times. Test team members can pick up builds frequently from the continuous integration system, test and give quick feedback in line with the Agile goal of giving early and regular feedback as the software is being built. Testing is not considered as a final phase to be done once Development has finished their work. Different stakeholders can test, often in parallel. For example, Developers, Testers, Product Managers, Management, etc. can run a variety of tests and provide inputs as the software is being developed. Some agile methodologies may involve pairing developers and testers together as a piece of the software is being built. In this case, testers provide inputs on the scenarios which would be tested while the developer can figure out how to address them. Testers gain a greater understanding of the code while developers get instant feedback on their work and enable them to make improvements on the fly. It helps the team produce quality software quicker via eliminating the lag between Dev & test.
While the software is being built, stakeholders can see how it is shaping up and can try out and test it themselves. This brings up the requirement for flexibility in requirements which is possible when following an Agile model. Stakeholders can suggest changes to requirements based on what they have seen/used. They do not need to wait until the end when Dev and testing is done to get their hands on the product. They can see it as it is evolving. The other interesting aspect of Agile is the definition of done for each story. The done definition typically encompasses both development and testing of the developed artifact. Agile teams may even (ideally) mandate automated tests to be complete too as part of the done definition. This would enable the team to build up a regression test suite with each iteration.
Test Automation in an agile team is of key significance. Manual testing may be performed for tests that are not automate-able or for tests of exploratory nature.
In comparison to the traditional models, Agile teams typically produce "just enough" documentation. Unlike the traditional approach of detailed documentation for requirements, test plan, test strategy, approach, etc. agile teams produce the essential level of documentation which is required by the various functions. Agile teams may use tools such as Atlassian's JIRA or similar to track epics, stories and tasks (and bugs too).
Testers use the same configuration management tools as Developers, check in test automation code to the same repositories and integrate their work with the CI system so that automated tests run with each build. In real practice, for large projects it may be the case that a subset of automated tests or even just unit tests run with every build while the full set of tests are run maybe once a day (at night usually) or once in a few days due to the time taken to complete a build and automated test run.
How different is agile testing from non-agile a.k.a. traditional models? Well, for one - in Agile, testers are involved all through the release and not restricted to a specific "phase" in the development cycle. Testing occurs through each iteration or Sprint. Testing like Development, is flexible and can/should accommodate change. Also, there is a higher degree of collaboration across functions in agile where all members (Dev, Test) are part of one scrum team and not viewed as distinct members belonging to separate functional groups.Testers are involved in release planning, reviews of stories, estimation, risk analysis and defining acceptance criteria for each story.
In an Agile team, testing doesn't wait until Development is "done". Test types may overlap at times. Test team members can pick up builds frequently from the continuous integration system, test and give quick feedback in line with the Agile goal of giving early and regular feedback as the software is being built. Testing is not considered as a final phase to be done once Development has finished their work. Different stakeholders can test, often in parallel. For example, Developers, Testers, Product Managers, Management, etc. can run a variety of tests and provide inputs as the software is being developed. Some agile methodologies may involve pairing developers and testers together as a piece of the software is being built. In this case, testers provide inputs on the scenarios which would be tested while the developer can figure out how to address them. Testers gain a greater understanding of the code while developers get instant feedback on their work and enable them to make improvements on the fly. It helps the team produce quality software quicker via eliminating the lag between Dev & test.
While the software is being built, stakeholders can see how it is shaping up and can try out and test it themselves. This brings up the requirement for flexibility in requirements which is possible when following an Agile model. Stakeholders can suggest changes to requirements based on what they have seen/used. They do not need to wait until the end when Dev and testing is done to get their hands on the product. They can see it as it is evolving. The other interesting aspect of Agile is the definition of done for each story. The done definition typically encompasses both development and testing of the developed artifact. Agile teams may even (ideally) mandate automated tests to be complete too as part of the done definition. This would enable the team to build up a regression test suite with each iteration.
Test Automation in an agile team is of key significance. Manual testing may be performed for tests that are not automate-able or for tests of exploratory nature.
In comparison to the traditional models, Agile teams typically produce "just enough" documentation. Unlike the traditional approach of detailed documentation for requirements, test plan, test strategy, approach, etc. agile teams produce the essential level of documentation which is required by the various functions. Agile teams may use tools such as Atlassian's JIRA or similar to track epics, stories and tasks (and bugs too).
Testers use the same configuration management tools as Developers, check in test automation code to the same repositories and integrate their work with the CI system so that automated tests run with each build. In real practice, for large projects it may be the case that a subset of automated tests or even just unit tests run with every build while the full set of tests are run maybe once a day (at night usually) or once in a few days due to the time taken to complete a build and automated test run.
***
Liked this post? Join my community of professional testers to receive fresh updates by email. Use this link
to add your email address to the community. Rest assured, I will
neither spam nor share your email address with anyone else. Your email
id will remain confidential. Subscriptions are handled by Google's
FeedBurner service.
