Why Use Agile as a Tester?

Whatever you are using now, whether it’s a phone or a web app, it has undergone a significant amount of testing to ensure that you are happy with them and that you don’t run into any problems with them. And with the fast pace of delivery in Agile, testing is brought to the forefront of it all. Teams must develop a set of solid test engineering processes to help ensure that they are creating their products with quality in the short amount of time they have committed to their customers.

Traditional Testing with Waterfall

Waterfall follows a linear, phase-by-phase approach in developing a product. It starts with gathering and knowing all the requirements, then gets things going with analysing and designing the product features, and actualises plans with developing the product. And before it reaches the hands of the customers, it goes through phases of testing and defect resolution, such as System Integration Testing and User Acceptance Testing. Only when the tests have been passed can the product be deployed, handed over, and maintained.

One of the most common problems of testing in a Waterfall project is that as the phases go on further, the more expensive the defects become. Even if static testing can be done earlier on the requirements and the code, that is often not enough to uncover most problems. For example, a requirement might turn out to be insufficiently designed, but the features have already been developed. That piece will have to be reworked, and then re-tested along with other integrated features. Another example, a feature might be infeasible due to technical constraints, but the design and architecture have already been signed off, so the team will have to go back on those again.

Waterfall is good for products that are simple and straightforward to make. But for complex products such as apps and websites, they need a more robust framework that can give room for flexibility. This is one of the main reasons why organisations switch from Waterfall to Agile.

Agile Testing, and What’s Involved in Switching To It

The main difference between Agile and Waterfall is that Agile delivers the product earlier on and more often. Because of the iterative nature of Agile, testing also needs to keep up to speed with the pace. Thanks to backlog management and breaking down the product into increments, all development activities including design, coding, and testing are managed to adjust to the pace as well, but not without compromising on traditional practices.

For one, because Agile values “working product” over “comprehensive documentation”, test plans, test cases, and other testing documents found in Waterfall don’t have to be as thorough as in Agile. One approach that can be done by Agile teams is to have a test plan for a certain release, with a list of scenarios and acceptance criteria to watch out for. The collaborative nature of Agile also does away with detailed System Requirement Specifications documents and makes do with user stories and road maps instead.

The faster pace of Agile also calls for an “all hands on deck” approach to quality. Gone are the days of team members keeping within silos. Instead, all roles in the project are even more responsible for not just testing but also ensuring that the product is built the way it should be. For example, the tester could give performance and usability insights to the Product Owner when designing user stories. The tester could also act as a business analyst and help clarify requirements between the clients and the development team. Cross-functionality in an Agile project means that the strengths of each role complements with the others, instead of separating responsibilities by role.

<– Continue Reading –>

Our Book Recommendations

We found these books great for finding out more information on Agile Scrum: