Understanding and Avoiding “Not In Scope” Bug Rejections

A bug can be valid and reproducible but still rejected as Not In Scope if it falls outside the defined objectives of the test cycle.

Common reasons include:

• The issue affects a different feature or section than what’s being tested

• It’s a usability concern, not a functional defect

• It results from unusual user behavior

• It’s caused by a third-party app or tool

Below are the main categories and how to avoid this rejection type.

Not In Scope Based on Documentation

a. The issue affects a feature or section outside the test scope

Always verify the Tester Specification carefully before you start testing. Some projects have detailed scope and exclusion lists. If the area or feature is not mentioned as part of the scope, issues from there will be rejected.

b. The issue is outside the Test Case instructions and exploratory testing is limited

If the problem is not triggered by following the Test Case steps, or happens outside the covered area, it’s considered out of scope.

Tip: Follow the Test Case instructions strictly unless exploratory testing is explicitly allowed.

Not In Scope - Usability

Issues related to minor visual inconsistencies, non-uniform design, or suboptimal behavior are often treated as Usability issues and rejected as out of scope.

Best practices:

• Ask yourself: “Is the app broken, or could it simply be improved?”

• If it’s more of an enhancement than a bug, don’t report it as a functional defect.

• Check the Usability Guidelines if you’re unsure.

Not In Scope - Unusual User Behaviour

Issues caused by abnormal or unrealistic user actions (e.g. spamming buttons, abusing navigation paths, or forcing rare edge cases) are typically considered out of scope.

Best practices:

• If the issue is severe (e.g. the app crashes after tapping the same button 5 times), report it with lower severity (it’s still valid but not critical).

• Not all extra actions are “unusual.” For instance, performing 2–3 extra taps after a freeze can still reveal a valid bug. Use judgment and context.

Not In Scope - Third-Party Elements

Issues triggered by non-standard third-party apps, tools, or custom settings are not valid. Testing should reflect typical user environments.

Best practices:
Valid examples:

• Issues caused by system-level actions such as battery saver, notifications, OS updates, or incoming calls.

Invalid examples:

• Network conditioners

• Third-party RAM/battery management tools

• Rooted devices (unless specified in the scope)

• Custom launchers or overlays with heavy UI modifications

In Summary

To avoid “Not In Scope” rejections, always make sure your reported issues align with:

• The defined scope and Test Case instructions

• Standard usability expectations

• Normal user behavior

• Native device environments

By staying within these boundaries, your reports will be valid, relevant, and more likely to be accepted.