Bureaucracy bug tracker

I have been working as a tester for more than a year now and I want to write about some bureaucratic ways that testers interact with developers through a bug tracker.

1. Ping-pong (ineffective way, causes management's claims)

The tester writes a bug, and the developer closes it without any comments and puts offensive status “Disabled”. Tester rediscovers the bug with the comment "You yourself are disabled." The developer is forced to write a comment. Not the fact that the case.

2. Undefix

Nezdofiks - this is not a fully fixed bug. For example, the required button was missing in two places. After fixing, the button appeared, but only in one place. When verifying such a bug, in my opinion, it is best to start a new bug that the button is missing in second place. And leave the original bug unconfigured and insert the comment “verification is blocked by a new bug”.
')
If you believe the original bug, it is possible that as a result of fixing the second bug, the button will disappear in the first place, and we will skip it.

3. Developer bug

A developer bug is a bug written by a developer. Often, developers do not write in the bug script playback, or even at least the desired behavior of the product. Therefore, it is very difficult to verify such a bug without a bottle or without additional information from the author.

In this case, a comment like "Give information, how to verify, or believe, please, yourself." Such a phrase, combined with the assignment of a bug to a developer, works better than just “Give information, how to verify”.

In the latter case, we do not give the developer an alternative of choice and he can start inventing it for himself. For example, refuse to give information, claiming that an incompetent tester cannot read between the lines. But as soon as the alternative to verifying the bug independently comes up to the developer in full growth, he, as a rule, writes detailed instructions.

4. This is not a bug, but a feature (developer's opinion)

A bug that is closed with such a comment needs to be closely examined. Not only by the tester, but also, perhaps, by its manager and the development manager. The feature, it turns out, is so unobvious and intuitively incomprehensible that it looks more like a bug. If the parties nevertheless agree that it is inappropriate to fix anything in the product, you should write a documentation bug so that the non-obvious behavior is clearly described.

5. This is not a bug, but a feature (tester opinion)

If the tester saw a bug like "We need to support three new versions of Linux", this is not a bug, but a feature, since the verification process will probably contain complete regression tests. Three times. Not to mention the possibility of testing the transition from the old version of Linux to the new. Accordingly, the time spent on verifying such a “bug” will be much more than average. Therefore, the one who started such a bug should be forced to design it as a full featured feature.

6. Bug verification for the current version is blocked by a bug planned to fix in the next version

Nonsense. The fixed version of both bugs needs to be delivered either the current one or the next one. This should be required in both bugs.
Perhaps I will write the obvious thing, but I had to write it once before.

If the first bug was recognized so harmful that it was fixed in the current version, but now everything breaks down in the same scenario, therefore, the blocking bug is just as harmful as a blocked one. So, there is no point in keeping them in different fixed versions, except that now nobody can fix the blocker. Consequently, it is absolutely safe for the quality of the product to move a blocked bug into the next fix version, since the script is still broken.

But it is better, of course, to fix the blocker in the current version.