Keeping Up with Changing Requirements
In traditional software development projects, business requirements are usually fixed and agreed upon at the early stages of the project. This can make the job easier for testers, who are sure that they will not need to change much in their test plan and test cases.
Since Agile projects frequently inspect and adapt the product they are building, requirements are also bound to change as frequently. There will be more maintenance work done, especially for regression test cases. Testers need to be ready for these changes and work closely with the Product Owner, the business analysts, and the developers in making sure that the product increment is built right, given the timebox.
Frequent Builds That Break Code
When the implementation phase in a traditional software project is over, coding work is stopped and only done when defects need to be fixed during the testing phases such as SIT and UAT. Code moving around or being broken to accommodate changes can result to once-stable features to be buggy. This can be expected from Agile projects, as teams race to complete the sprint before the timebox expires.
This is an extra pressure for testers, who need to ensure that newly introduced and developed features would not affect the old features by performing regression testing. For this reason, Agile teams are encouraged to invest their time in automation testing on top of their work.
Recommended Further Reading
The following materials may assist you in order to get the most out of this course: