Regression Testing For Product Owners – Part 2
The following scheduling approaches can be adopted:
Traditional Testing Approach – The team does an iteration regression after a sprint cycle. After some sprint cycles, the product goes through full regression testing.
Delayed Week Approach – In this approach, the iteration regression is not confined within a timeline and can carry over to the following week. This works for teams that are still familiarizing themselves with the product.
Delayed Sprint Approach – In the current iteration, the team performs regression testing on the features made during the previous iteration. This is a fairly common approach and makes do without the two levels of regression.
Risk-Based and Collaborative Regression Testing
If a team is short on time, they can choose to prioritize the test cases to execute during regression testing. In using a risk-based approach, the team categorizes their test cases into the following priorities:
High – These are test cases that cover the critical, highly visible, or defect-prone features of the product. It is usually about 10% of all the test cases.
Medium – Being around 30% of all the test cases, these cover exceptional conditions (boundary testing, negative testing, etc.).
Low – These makeup 60% of the remaining functionalities, and are usually only involved when full regression is to be done.
Another approach that can be used is collaborative regression testing. The team can use a “regression board”, where changes done to the product are written on post-its and placed on a board. A team member can declare the prioritization of testing that change by how high (or low) they position the post-it.
Technical Side of Regression Testing
It is imperative for the team to be able to test within a short period of time, given the faster frequency of builds. The team can opt to automate their regression test suite, especially the test cases for features that have established user flows already. This can help the testers save time from manually executing the same tests over and over again, over different browsers and devices.
Choosing this approach isn’t simply codifying the test cases, however. The team must be able to intelligently select which test cases to automate and optimizing those test cases for automation. The automated test cases should also be reviewed and modified from time to time; test cases that are found to be obsolete should be discarded to avoid redundancy.
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum:
Communication for Successful Regression Testing
In whatever approach the team takes, seamless communication is highly important to the team. One of a product owner’s responsibilities is to help guide the team in what direction to take by being clear on the priorities. The Scrum Master should help facilitate the communication by coaching the team on Agile practices. And the development team must be on top of the changes they made in a particular iteration.
Agile presented us with a lot of benefits: feedback loops are shorter, critical defects (functional and non-functional) are found earlier, and value is delivered faster, among other things. Agile also presented us with a lot of challenges: shorter timelines, more frequent changes, and increasing test coverage, to name a few. The iterative nature of Agile makes it necessary for the team to check everything on the product design and implementation so far.