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:
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.
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:
Cons:
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:
Cons: