Not in Scope: Ensuring Your Bug Is Valid

As mentioned earlier, one of the most important sections to review in any Tester Spec Document is the “In Scope / Not in Scope” section.

This section defines the boundaries of the test, what you should report and what you should not.

In the Not in Scope section, you will almost always find two common exclusions:

• Usability Issues

• Abnormal User Behavior

Understanding these two categories is essential to avoiding invalid reports.

---

Usability Issues

Usability issues are suggestions or opinions about how the app could be improved.

We genuinely appreciate the creativity and insight of our testers. Many suggestions are thoughtful and valuable. However, during most testing cycles, your role is not to redesign or improve the product, it is to test the app exactly as it currently exists.

Our clients expect us to:

• Verify existing functionality

• Identify defects

• Report deviations from expected behavior

They are not requesting design recommendations or feature suggestions.

Although your ideas may be excellent, submitting improvement suggestions instead of actual defects will result in a Not in Scope resolution.

---

What is vs. What is not a Usability Issue

When testing an app in isolation, focus only on what is currently implemented.

❌ Example of a Usability Issue

You notice that the “Log Out” button is only accessible inside the Settings menu.
You believe it would be better to place a “Log Out” button in the Side Menu.
You report that the app “should include” this option.

This is not a bug. It is a design suggestion.

You are reporting something that is missing according to your preference, not something that is malfunctioning.

---

✅ Exception: Cross-Platform Comparison

If you are specifically instructed to compare platforms (e.g., iOS vs. Android, mobile vs. web), and:

• A feature exists on one platform

• But is completely missing on another

Then this difference should be reported, because consistency across platforms may be in scope.

Always refer to the Tester Spec to confirm whether cross-platform comparison is required.

---

Expectations vs. Actual Behavior

Another common source of usability reports comes from personal expectations.

Sometimes testers assume that an app should behave in a certain way because that is the industry norm.

For example:

You tap “Terms and Conditions” and expect a new screen to open.
Instead, the text expands below the button on the same screen.

Even if this differs from what you are used to, it is not automatically a bug.

The key question is:

Does the action successfully display the Terms and Conditions?

If yes, then the functionality works, even if the design choice differs from your expectations.

As a tester, you must evaluate behavior based on functionality, not personal preference.

---

Abnormal User Behavior

“Abnormal User Behavior” refers to unrealistic, destructive, or malicious actions performed to intentionally trigger an issue.

Examples include:

• Rapidly spamming buttons to force a crash

• Overloading the device with background apps to create memory issues

• Using jailbroken or rooted devices (unless explicitly allowed)

• Using location spoofing or unauthorized tools

• Performing extremely complex action sequences unlikely to occur in real usage

Testing should simulate realistic user behavior.

A bug that only appears after performing 50 rapid taps, switching networks repeatedly, and minimizing the app multiple times may not reflect normal usage.

If an issue requires unrealistic conditions that an average user would never encounter, it may be considered Not in Scope.

---

Realistic Testing Behavior

When testing, always ask yourself:

• Would a normal user realistically perform these actions?

• Am I testing the app logically and honestly?

• Am I trying to validate functionality or force a failure?

Your goal is to simulate real-world usage conditions.

We understand that testers rarely act with bad intentions. However, maintaining logical, fair, and professional testing behavior ensures:

• Valid bug reports

• Faster moderation

• Higher acceptance rates

• Stronger tester reputation

---

Final Reminder

Before submitting any issue, always double-check:

• Is this a real defect in existing functionality?

• Is it truly within scope?

• Does it reflect realistic user behavior?

Understanding these distinctions will significantly reduce rejections.