Manual Testing (IT)QA Engineer

What approaches and techniques help manual testers identify hidden or non-obvious defects that are undocumented in the requirements and are not covered by test cases? How should they be properly documented?

Pass interviews with Hintsage AI assistant

Answer

Background:

As software complexity grows, it has been observed that some bugs are only discovered outside of test cases or specifications — often these bugs are the most critical for real users. To find such defects, testers employ special techniques, combining standard tests with their own experience.

Problem:

Hidden bugs related to the interaction of components, incorrect handling of non-obvious situations, or missing requirements are the hardest to detect and document. Often, testers are unsure whether to officially record a found issue if it is "not specified in the requirements document."

Solution:

Methods like exploratory testing, pair testing, and experience with similar products are used. Always document such bugs as thoroughly as possible: steps, observations, why you consider them defects, links to related requirements or accepted logic.

Key features:

  • Necessity for initiative and critical thinking.
  • It is important to argue why it is indeed a defect.
  • In some cases, participation in discussions with analysts/PO is needed.

Tricky Questions.

Can bugs not described in the requirements be disregarded or ignored?

No, always report them, even if there's no exact reference to a requirement; otherwise, critical issues will reach the client.

Is user inconvenience a bug or an improvement (feature request)?

If the behavior is clearly illogical, causes confusion, or poses risks, record it as a bug; otherwise, classify it as an improvement.

Should a tester consult the team on every non-obvious bug?

It is recommended to discuss disputed cases with an analyst or developer beforehand to avoid pointless tickets.

Common Mistakes and Anti-patterns

  • Ignoring obvious defects for users that are not documented in requirements.
  • Poor/incomplete documentation of hidden bugs.
  • Lack of justification for the bug report.

Real-life Example

Negative Case

A tester noticed that when two windows are opened simultaneously, the system hangs, but did not file a bug since this scenario was not described in the requirements and test cases.

Pros:

  • Did not add an "extra" bug, freeing developers for other tasks.

Cons:

  • The system was released with a critical vulnerability, affecting clients.

Positive Case

The tester filed a bug with a description of the step (opening two windows, sequence of actions), attached a screenshot, and explained why they consider it a bug (a real user might find themselves in this situation).

Pros:

  • The bug was promptly fixed, and end users did not encounter the issue.

Cons:

  • Time was needed to discuss the scenario with analysts.