The Association for Software Testing is crowd-sourcing a book titled Navigating the World as a Context-Driven Tester. The book is being edited by Lee Hawkins, who shares questions on platforms such as Mastodon, LinkedIn, BlueSky, Twitter, Slack, and the AST mailing list.
The feasibility of testing “all the stuff” in every iteration depends on what you mean by that term. If it refers to comprehensive regression testing of the entire application, including all features, negative paths, and edge cases, then it’s impractical for most products.
In an agile context, iterations introduce small, valuable changes delivered to users quickly. This approach doesn’t necessitate retesting the entire product each time since most of it remains unchanged and has already been tested. If changes have broader implications, identifying code with potentially large impacts allows for more focused testing.
If frequent, comprehensive testing seems necessary, it might indicate deeper issues, such as poor system architecture or technical debt. In such cases, addressing these underlying problems is more beneficial than exhaustive testing.
Testers often see themselves as the last defense against releasing buggy software, feeling uneasy about not conducting comprehensive testing. However, agile development accepts this calculated risk, balancing it with the advantage of faster releases and quick fixes based on user feedback. If skeptical, try this approach for a few releases to gather empirical evidence on its impact on product quality.
Testers shouldn’t be asked to perform comprehensive testing every iteration. Educate stakeholders on the trade-offs of iterations or consider adapting more cautious development models if needed.
Automation is crucial in this process, providing daily updates on the product’s state. While it has limits, automation can handle repetitive checks, freeing testers to focus on areas needing human insight. Understanding what automation can and cannot do helps in making informed testing decisions.
If “all the stuff” means testing all changes in an iteration, excessive workloads can be managed through whole team ownership, with developers assisting in testing tasks. This approach can be initiated by signaling the issue during stand-ups, promoting collaboration.
To prevent testers from being overwhelmed at the end of iterations, adopt early testing practices. Test changes as soon as possible, even during PR stages, and provide early feedback to developers. Encourage open communication and early sharing of code and ideas during daily stand-ups or private discussions.
If testers still face heavy workloads despite these efforts, it might be a symptom of rigid scrum structures. Discuss this in retrospective meetings to find sustainable solutions as a team. Monitor progress and revisit the issue if no improvements are seen.
