Answer.

Background: Elusive, intermittent bugs have long been a headache for testers: they do not always appear and are often poorly documented, complicating their reproduction and analysis, and therefore, their correction.

Problem:

The main issue with intermittent bugs is the inability to have a clear reproduction scenario. Often the cause can be unstable environments, response times, data synchronization errors, or conflicts when multiple users are working. It's difficult for a developer to fix what cannot be consistently caught. If the tester does not document the accompanying conditions, the bugs go unresolved.

Solution:

Use an extended report format: document time, environment, steps to reproduce the bug, logs, videos/screenshots.
Analyze trends: under what conditions did the bug occur? (For example, "during heavy load in the daytime" or only in specific sequences of actions.)
Close collaboration with developers to update environments and clarify technical details.
Repeated attempts to reproduce on different devices and operating systems.

Key Features:

Always document even the smallest differences between successful and unsuccessful attempts.
Indicate the frequency of occurrence and attempts to reproduce.
Attach media materials (screenshots, videos).

Trick Questions.

Can you close a bug as 'not a bug' if it could not be reproduced by the support engineer?

No. If there is a suspicion of a bug, it's better to leave the ticket open with a note "reproducibility: low" and update it upon receiving new data.

Is the problem always in the code if the bug appears intermittently?

No. Errors may occur in the network, environment configuration, outdated browser cache, specifics of third-party services, or peripherals.

Should the priority of intermittent bugs be lowered if they cannot be reproduced every time?

Not always. The consequences can sometimes be critical for the user (for example, double charging of money), so prioritization should consider business risks.

Common Mistakes and Anti-patterns

Documenting bugs without accompanying information about time, environment, version.
Attempting formal "closure" of complexity as non-reproducible.
Ignoring intermittent bugs if they were not reproduced outside of the test environment.

Real-life Example

Negative Case

The tester discovered a bug in unlocking the profile, but the bug occurred no more than 1 in 10 attempts. The documentation was limited to a screenshot of the error — the bug was closed since the developer could not reproduce it.

Pros:

Quick closure of the task.

Cons:

The bug surfaced in production with real users, and it had to be urgently fixed, risking corporate reputation.

Positive Case

The tester carefully recorded all conditions: browser, time of day, login method, attached short videos and logs, maintained regular contact with developers until a stable scenario was obtained.