Ever Been Asked To Hide A Bug?

[Paul]

Has anyone on here ever been asked by a project manager (or other colleague) to overlook a bug (e.g. a bug that maybe wasn’t in scope of testing) in order to meet a deadline?

Just curious!

[Alin]

Hi Paul,

I have never been in a situation where I have been asked to hide a bug but I can try to imagine how this can be.
As you said, the limited time would be a cause for getting in this case. I think this situation is also connected to responsibility and costs of rework. When a bug is found and it will cause the impossibility to not meet the deadlines, then there must be a discussion between tester(s) and project manager and possible cases can be like this:
– When the project will get its money only if deadline is met, then it might be possible to accept the current version and not stop the release phase due to that bug.
– If that bug is not critical and will not affect customers, then the version can also be released.
– If a bug fix can be easily and quickly made without significant costs, then the bug can be overlooked.
In all cases the responsibility must be shared between the tester and project manager.
But the bug will be hidden from some people and it is important to know who these people are. Mostly, I think there are the stakeholders who will get the product as scheduled and they will get quickly a bug fix without knowing that there was initially a bug found. I think the internal team especially developers will get the information about the bug.
I find these situations highly exceptional and they must be always avoided when it is possible because reliability of tester’s work might decrease.
These are only general ideas on this topic. Maybe someone who was facing this situation can give a specific example with more details.

Regards,
Alin

[Matthew]

Yes, I’ve been asked to ignore bugs (defects/faults/whatever) because they are not the strict scope of the testing or because it’s close to a deadline and the Project Manager wants to get the delivery over the line.

My response has always been to ignore them and raise it. To me, any issue, whether in the current scope of testing or not, needs highlighting. It might be minor, or it might be a showstopper, but the Product Owner has a right to know and to make an assessment themselves of whether they are willing to take the risk. Alternatively, the development team might take a look at the defect and be able to resolve it quickly.

In the end, that is what testing is about -mitigating the risk of defects when a product goes live, and giving the Product Owner (or stakeholders) information on which they can base a decision.

“Hiding” a defect is unprofessional – but where a defect is resolved, then a Product Owner does not need to be aware of it – at least in detail (release notes should always list the issues resolved).

I’ve been in situations where the stakeholders did not trust the delivery of the project, because they had had bad experiences in the past. Once I’d sat them down and showed them exactly what we did, and that we would never hide anything from them, they relaxed and let us get on with our jobs. In my mind, trying to hid a defect just to meet a deadline will always blow up in your face later on down the line.

[Paul]

I guess there won’t be many responding to say “yep, I hide (significant) bugs all the time” as it would be an admission of “unprofessional” behaviour (at least!!) as Matthew says.

I’m more interested in hearing about how testers have handled the experience – what they chose to do in response to such a request. Is it a common wrangle with Project Managers that gets resolved between the testers and PMs or is it just a case of bypassing their request and being up front about defects?

[Jorge]

In one of my first assignments as a tester, more than 20 years ago, I had no direct access to the bug tracking system. I had to pass the bug reports to an employee, since I was a third-party contractor. It was a multi-team, international project. The project manager explicitly forbid to report bugs in the week before integrating the artifacts with the other teams, since it would make his team look bad. As always, politics trumping professionalism.

[Shobha]

There are always a different situations as explained by folks above
From my view point , you should never hide Issues/Bugs , Its good to have transparency from all the internal stakesholders
Dev: If they find some issues which may impact their code fix even if its not within the scope – they should communicate to Testers if its not covered in the Test scenarios
Testers- having domain expertise[considering] find issues out of scope which has broken existing functionality – They have to raise it – Justify how it might impact the existing Users and standby
PM : Should never ask to hide the Issues / rather add it to the release notes in the Known Issues section , which provides transparency and would create a faithful impression from Customers.
Blockers/Showstoppers – Never agree on releasing /or cannot be hidden and rest can be judgmental

Testers should be able to provide valid justification on the issues and mention the impact by deriving the statistics of Users who may have impact.
Ideally based on the analysis everybody should have common understanding . As mentioned its best to suggest PM to include known issues list in the release notes if it cannot be fixed within the release deadline.
Eventually your Work is accountable and take up these issues for the future releases or agree on delivering patch based on the impact .
Here everybody has the same goal to deliver a quality product. Deadlines ,Scopes , Handling issues are all situation based .

hope this helps!

[Thanh]

Hi Paul,

May I ask what do you mean by “hide the bug” or “overlook the bug”?

Does it mean you found a critical bug and your manager wanted you not to submit it because release deadline is coming?

[Elísabet]

Interesting topic!
I have never been asked to hide a bug or not report it and I don’t think I could do it if I was asked to. In my mind, asking a tester to do that would be the same as to ask Santa not to bring any presents – but that’s his job!
However, I have had developers telling me that some bugs I find are outside the scope of the project, even when the bugs are in the module they just delivered for testing. I think this is one of the interesting parts of testing, the communication between people and convincing the developer/product owner that certain issues really do need to be fixed.
I do report everything I find because it is my job to do so, show-stopper or not, but the bugs are not all critical and some of them are not fixed right away but get the “known issue” stamp instead.

[Red]

Agreed with everyone here – we should always report validated defects… but be aware that a bug as defined can be in the eye of the beholder.

This then becomes a semantic question: how can we prove that it is in fact “unwelcome”, or “incorrect” behavior? If you have no acceptance criteria to point at – in whose judgement is it “unwelcome” or “incorrect”… so you have to always strive to have a model to compare the behavior to, even if it’s the product itself. If you’re wavering even a little, it can be perceived as weakness in your commitment to having it fixed.

Early in my career in QA – the only time I was asked to not report defects was exceedingly early in the development cycle for the SUT, when defects sometimes make no sense. Example – why write a defect on a UI that isn’t even close to being ready? We have to use judgement there too.

On the humorous side – I did once have a manager come running into my cube pulling his hair out – and shouting “Are you trying to make me crazy!???” after submitting one of the most bizarre ‘shoe on the keyboard’ defects I’ve ever found.

[Shey]

I started my testing career in the computer games industry just over 15 years ago. Some would say during the bad old days of games testing.

During those “bad old days” I was routinely told to withhold reporting bugs. Two major occasions during the project where we were asked to sit on the bugs were:
1. Just before exporting a bug list to send to the publisher
2. Just before going gold

It wasn’t uncommon for an all-stop on reporting bugs to be issued, but we were expected to keep testing the game. This was mainly to be sure there weren’t any showstoppers in the game.

I have no visibility as to whether the above still goes on in the games industry as I don’t work in it any more. I hope things have moved on since then. I certainly have! 🙂

[Jesper]

oh they days of going GOLD on cd deliveries…. #movedOn

[stefan]

I was asked to not post a bug because they will fix the issue without a ticket.
I was asked to not post an issue because the area needs to be re-worked entirely and the planning will be done soon.
I was asked to not post an issue because it is not a focus for the first releases (ex. alpha or one of the beta phases).
I was asked to not create an issue because that’s just functionality that wasn’t implemented yet.

Sometimes I did not listen to them, or didn’t even ask and created this kind of tickets. The result, closed as duplicate or won’t fix or cannot reproduce.

[Hannah]

Hi everyone,

I have recently been asked to close all my unresolved bugs from our bug tracking system (time of reporting the bugs ranges from months ago to days ago). This request was given to me without any context and no reason as to why we should do this. I shared with my team leader that I was not comfortable with doing this as these issues still exist in the system.

As I am still quite new to the world of testing I would have appreciated at least a reason why we had decided to take this action. Maybe deadline related or stat related?

[Padmaraj]

Hi Paul ,

If you have manager with test knowledge or technical knowledge with domain then you are lucky, your bug get in scope. ( else some time you need to convince your super manager or lead about it )

best practices for me is I agree on project kick off day what is test scope of the project and limits & get to know what we need to test what not..( scope can be change over time )

In my experince no one developer want to see Friday critical bug get assigned to him/her ( Its happen when we working under extreme programming or contract job where developer need to over work). Developer normally say you don’t add today, mean you need to add same bug on Monday 🙂

[Paul]

Thanks for all of your responses! 🙂

There are some very interesting experiences ranging from deferring bug reports til Monday (which on the surface of it seems ok) to withholding bugs, closing unresolved bugs, politics, etc. (not so ‘ok’ !)

Testers have a huge responsibility to end users really when you think about it. Reporting defects (or not) can have a massive influence on the finished product. PM’s are so focused on release dates and getting projects “over the line” and there’s always a degree of conflict between company objectives and customer requirements. I’d imagine this is a constant battle for testers but maybe I’m wrong?

The world is increasingly reliant on software and customers need to be able to trust that what they are buying is delivered by professionals acting in good faith. The impact of a broken trust could be catastrophic (in terms of reputation/profitability etc.).

Speaking out against what you consider malpractice isn’t easy (I’d imagine) – particularly if you’re in a new job – but not speaking out (or turning a blind eye) when you know something is wrong makes you complicit.

My next question is – have you had encountered scenarios where serious bugs have been deliberately overlooked e.g. in the interest of meeting a target release date?

[Archana]

I think this is a very common scenario. I would like to share one particular incident where I, or rather the entire testing team, was asked to hide a major defect. The client was loosing confidence in the product that was being developed and this particular release was a major one. The smoke test itself failed and when the development team came to know about it, they assured us that the defect will be fixed within an hour. And requested us to hide this defect until that time, which we did. At that time it seemed the right thing to do and we didn’t have much choice either. The good thing was that the defect was indeed fixed within an hour

[Paul]

@archana – what would you have done if the defect hadn’t been fixed within the hour? Or at all?

[Archana]

The defect was a major one and it would not have taken more than 5 min for the client to discover it. What the testing team did was just delayed the whole testing process. Had the defect not been fixed, test manager had decided on rejecting the build, because obviously there was no way she could have approved it even if she wanted to.

[Tassawer]

You have to overlook some bugs if there is a time critical release nearby. Following aspects are keep into consideration i.e.

1. Bug is not a regression
2. Very low customer probability

Then, it is advised to overlook or ignore it and report it after the release 🙂

[Author]

Posts