Why it’s important to define the scope of software testing activities
Understanding a tester’s role
Understanding a tester’s role and scope is central to effective work and project success, but it’s often done wrong. To offer some guidance, this post focuses on the question: “What do you need from your tester?” The aim isn’t to provide a direct answer but to explain the meaning behind it, highlight why it matters, and pinpoint who should be asking it and when.
Defining the scope of testing activities
When it comes to “the scope of testing activities”, the essential question is, “What does your tester do, exactly?” It’s not enough to use vague terms like “testing” or “QA”; we need to have a more specific answer. At the same time, this doesn’t mean there’s a one-size-fits-all answer for every team or project within a company.
In my opinion, the scope of testers is more varied and complex compared to that of developers. While the general idea of a developer’s role is relatively consistent across companies and projects, the same can’t be said for testers. Sure, we can also talk about the scope of programming activities, such as code review, deployment, and writing documentation. Some developers participate in these activities while others don’t. But, programming, the primary activity for developers, is universally understood with clear expectations.
Defining what testers do isn’t as straightforward. Even when we consider basic activities like “manual testing,” “automated testing,” or “test analysis,” the terms alone don’t provide information about what’s expected. This underscores the need to clearly define the scope of a tester’s responsibilities.
In software testing discussions, we often refer to the testing scope for a specific feature, part of a feature (like a “ticket” in Jira-like tools), or a project. But I’m highlighting a broader, higher-level scope. This encompasses not only what a tester does but also when and under what conditions they operate.
The impact of undefined scope on effectiveness
If you lack a clear understanding of a tester’s role, both the tester and the company will pay the price. Without a defined scope, they can’t work effectively.
As there are usually fewer testers than developers, a common pitfall involves testers frequently switching contexts within a team or project. This approach is ineffective and should be avoided. The scope of a tester’s responsibilities should remain stable and not undergo daily or weekly changes.
For example:
- If the scope is “feature testing for team A”: Avoid frequent changes to both the testing objective (feature testing) and the team context (team A).
- If the scope is “regression testing for teams A, B, and C”: Establish clear prioritization guidelines. This helps prevent disruptions to stability caused by frequent changes in priorities.
These examples highlight the importance of having a well-defined and established scope for testers.
A common misconception in software testing is that “everything needs to be tested.” This isn’t the case, and more importantly, it’s not feasible. We can’t automatically assume testers are meant to test everything. In certain scenarios, they won’t test at all and will instead guide others. In other cases, they might test simple and mundane tasks out of necessity, especially when tools such as automated tests aren’t available. Testers could find themselves in a middle ground for consultative testing. Blanket statements like “test everything” or “test nothing” introduce uncertainty to a tester’s role.
A well-defined scope for testers is necessary for effectiveness, stability, responsibility, and reliability.
Who should ask the scope question
The question of scope is especially crucial for those steering the ship, such as team leads, software architects, QA leads, and project managers. But it also holds weight for everyone involved, from the testers themselves — who should emphasize it during interviews or major process changes — to the developers, who need a clear understanding of what’s expected from their testing counterparts.
Timing matters: When to ask about scope
Knowing when to pose the question is just as important. It’s not a one-and-done task. It should be raised when onboarding new testers, especially when the role is novel for the team, project, or company. But it shouldn’t stop there. Any shift in the context of existing testers or a realization that the current scope falls short calls for revisiting the question. Here are some examples of when to reassess the scope of activities for testers:
- The development process changes, whether in the entire company or a particular team
- Changes in the ratio between the number of testers and developers
- Testers become bottlenecks in development
- Struggles with the quality of development despite dedicated testers
- A rising demand for testers alongside questions about the efficacy of testing activities
- Testers consistently failing to meet workload expectations
Real-world examples of scope gone wrong
Situation #1: Tester’s formal team vs. actual responsibilities
Imagine a scenario where a tester is officially part of one team but, in reality, bears responsibilities for other teams as well.
Two teams, A and B, both consist of a tester, developers, and a product owner. When a developer or product owner is on leave, the team adapts and carries on with adjusted expectations and workflows. But when the tester from Team A is absent, Team B’s tester is expected to fill in and take over the missing colleague’s responsibilities.
This situation is problematic for several reasons. Firstly, expecting one person to double their workload is unrealistic. Secondly, the scopes of Team A and Team B may significantly differ, both from a business and technical perspective. Lastly, assumptions about replacements imply that a team can’t function without one member or don’t see them as an inherent part of the team. I’m not saying it’s impossible for a tester from Team B to help Team A, but that the scope of work has to be adjusted.
Situation #2: Scaling developers without adjusting the tester’s scope
Consider a scenario where two testers, six developers, and one project manager collaborate on a long-term project. The project evolves and the number of developers grows from six to twenty, but the company fails to hire more QA capacities. With the false expectation that the scope can remain unchanged, the project suffers. To maintain quality and tester motivation, the scope of work needs to be adjusted in the face of expanding development teams.
Conclusion
As you can see, it’s not enough to simply anticipate the scope of testing activities. It’s not enough to define it and leave it as it is indefinitely. The scope needs to be clearly defined, communicated, and then adjusted when needed.
