At my last job interview, I was asked:

You find a major bug, but no developers are present. The release deadline is today. What do you do?

It's not a difficult question, but it can be answered in many ways.

What is the best way to answer this interview question.

  • 2
    First,would you like to share your view on this so that others can suggest improvements.. Commented Jan 1, 2018 at 15:15
  • Define a major bug? In my book major is something that has a workaround and does not break important user flows, maybe it is just an improvement or a missed feature. Commented Apr 25, 2019 at 18:10

12 Answers 12


As others have said, there is no single correct answer. The interviewers are probably looking to see how you would handle a stress situation with a tight deadline.

Risk/Impact - This might be a major bug, but what you do depends a lot on how likely it is that the bug will occur in production, how much damage it will do if it occurs, and whether there is a workaround. For instance, a bug that's extremely likely to occur, corrupts data when it does happen, and has no workaround is a show-stopper. You immediately escalate to stakeholders and block the release.

If it's not a show-stopper (something that can only be determined with knowledge of the system and how it's used), and/or there's a workaround, document for release notes, then notify stakeholders.

Document - No matter what, you need to report the bug. Since it's supposed to be released today and there are no developers to fix it, you need to add any workaround information to the release notes, as well as flag it as a known issue. You may not be able to convince stakeholders to delay the release, or there may be overriding concerns such as contracted delivery dates with severe penalties that will force your company to release despite the problem.

Protection - The reason the bug is a crisis situation is that there is nobody available to fix it: you need to document this and work with your manager to ensure that there are always developer resources available in case something like this occurs again. Note that this isn't a case of laying blame - if the entire project was run on an overly tight timeline, it's quite possible that your team wasn't able to access the part of the system with the bug until the last day. Or other factors could have intervened: hardware failures, interaction with third parties... in my experience nobody wants to deliver substandard software, but that doesn't mean that circumstances allow everyone to work to the standard they'd like.


This is a typical behavioral interview question, checking if you have real-life experience in testing under pressure, and there are no right or wrong answers. Google for "behavioral interview questions" for more.

I would describe any situations in my past experience when bugs were detected late in the test cycle, what process we used to evaluate the situation, which options we considered, and what decision was made for which reason.

Key is: is has to be real experience, not a fake. If you try to fake it, with just few follow-up question is would be discovered.

Remember that QA cannot "assure" quality. QA reports the status of testing to management, which will make business decisions: postpone release, or release with a known bug.

In your case, responsibility of QA is to report to management (providing the best info available, especially risk/impact from Kate Paulk answer) and let them make the decisions. But if you just say this (without mentioning real war story), they will see you are obviously faking it.


One scenario for this case:

  1. bug found. looks like "major"
  2. reproduce & locate it
  3. write a bug report
  4. inform project manager about the bug and let him/her/customer to decide what to do.

We testers work in an information business: we gather information about current state of the software. We do not make business decisions.


I assume what you meant is: when you get A major bug, not THE major bug.

I do not think we can DEFINE a proper answer, it is one of those situations you will have to deal with based on its context.

  • The short answer is, talk with the stake holder. There has to be someone who has the responsibility over this product you are testing. And this stake holder does not have to be a developer, as a matter of face, from my personal experiences, stake holders have never been a developer. I have seen a test manager as the stake holder, or the product manager or a business analyst.
  • In the worst scenario, if there is no one else to talk to about this major bug you have just discovered. The least you can do is to flag it on your bug tracking system and stop this release for now, wait for a stake holder to return.
  • yes, I agree with you.But they told me as "Today is our deadline & you found major then what is next". Commented Jan 1, 2018 at 6:31
  • Is there any other way to without stopping of release. Commented Jan 1, 2018 at 6:35
  • @jensisuthar, if a major bug is not a blocking bug, then you can go ahead with release, but it will be you that is held responsible. Do you have authority to do it?
    – Yu Zhang
    Commented Jan 1, 2018 at 7:27
  • Yes, I have. But I agree with you that if not blocking then I can definitely deliver build to the client or else need to stop sharing as of now. Commented Jan 1, 2018 at 7:32

The use case in which the bug discovered is also of importance here, in my view.

For Example: if the bug is found in very corner use case of an application flow, and the probability of end user hitting this use case is fairly low, then a release can be made as planned and the bug will be flagged as a high severity bug in a bug tracking system.

Next when dev team is available to address this, ask them to fix it as soon as they can and then, make another release/deployment to production.

In this way, the release do happen as planned and hopefully there are not many impacted users (as the use case is not in happy flow of deployed application).

But of course if bug is easy to encounter by end user or is part of happy-path journey of your application flow, then you as a Quality Assurance person has to stand on your ground and flag the risk to all stakeholders, senior management.

If all stakeholders are still ok to go to production, with this bug still open, due to deployment deadline, well then its upto them to assess business impact of this defect in production, customer dissatisfaction etc.

From QA stand point, you did your job by 1. discovering the bug, 2.recording it in bug tracking tool and 3.highlighting it to all stakeholders + senior management


It depends on the severity for the issue if it will be critical (stopper) issue , tell the project manager to stop the release till the issue resolved by the developer. if the production can go containing this issue and it will not appear by direct "Happy path" scenario, upload the issue and go on production till developer solve it as soon as possible.


You find a major bug, but no developers are present. The release deadline is today. What do you do?

I'd quit: A company that has no developers available on the deadline day for a release has terrible management and irresponsible developers. Finding a major bug at the deadline is also sign of irresponsible developers and a terrible testing protocol.

Such a firm is not destined to succeed and is not worth working for.

I'd also tell them: If that can happen at your company, I don't want to work for you, for the same reasons.

  • 3
    As a developer, I totally and utterly disagree. The only way to prevent QA from finding major bus at the deadline is to send them to the pub early in the morning and not allowing them to return.
    – gnasher729
    Commented Jan 20, 2018 at 17:01
  • 1
    @gnasher729 - As a developer with 20 years of experience in NYC's financial industry, I'd never hire you to program anything but games if that's the way you develop software.
    – Vector
    Commented Jan 20, 2018 at 19:03
  • For a bit of perspective - I'm the only tester in my workplace, and despite the best efforts of the dev team and my own efforts, I still run into critical problems at the last minute because it's not possible to test everything all the time. The interaction of available time, code complexity, feature complexity, third-party integrations, hardware, and so on means that we have to cross our fingers and hope sometimes.
    – Kate Paulk
    Commented Feb 8, 2018 at 12:31

At my place the rule is that devs set up things so that all that is needed to release is pressing a button. QA tests to the last minute. And at the point in time where we planned to release, the boss asks QA: Can we release this software? If the answer is "Yes", it is released. If the answer is "No" or "Don't know" then the boss decides, most likely after asking "why".

In that situation it's easy. You found a major bug. The boss asks "Can we release". You say "Don't know, we just found a major bug, this is what it does, this is when it happens, and this is how often it happens". It's up to your boss then to decide if it gets released or no.

If there are no developers present, it obviously doesn't get fixed today. If there are experienced developers present, it will also not get fixed today, because experienced developers know that trying to fix a bug at the last minute will lead to trouble.

Now if your interviewer claims that you have the responsibility and the power to make decisions: You should have been told how much of the deadline the deadline is. Are you writing software for a telescope recording pictures of the next solar eclipse? That's what I call a deadline. You ship and pray. Not shipping = no recording, shipping = maybe a recording, maybe not, but never worse than not shipping. Company signed a contract that will bankrupt it if you don't ship today? You ship and pray. Not shipping = bankruptcy, shipping = possibly upset customers. Shipping is better.

But 99% of the time, deadlines are just arbitrary points in time set by management. So you try to figure out what is the impact if you ship today, with the major bug, and what is the impact if you ship in two days time. And then decide what's better.

  • This does not answer the question: What do you do?
    – Vector
    Commented Jan 20, 2018 at 19:09
  • At my place the rule is that devs set up things..., the boss asks QA: Can we release this software? If so, it's not a real deadline at all, just an optimistic release date. The OP says there is a deadline - all this answer does is obfuscate and play with the term deadline. That's not what an interviewer wants to hear - if someone asks such a question, they want a clear decisive answer.
    – Vector
    Commented Jan 20, 2018 at 19:13

I was faced this situation, At that I was escalated to my management team and I took the decision to stop the delivery but management is not willing to stop the delivery because they have committed the date with the client Then the decision is happened in quite some time and finally they decided to release the build with the known defect. I was not happy with that release.

Anyway the management is decided, so I have documented the steps with which scenario it is causing and circulated the document along with the release notes to the client team and stack holders

At end of the result the delivery went to the client but due to the client team is not attempted the scenario which is mentioned in the document due to the known bug.

The next day we have fixed the issues and delivered the new build to the client as a priority

That point of time, I have observed the decision-making is not fully authorized to the testing team but all are saying QA has the power to stop the delivery


It is upto the Technical team.This is not in the hands of QA Team.The job of a tester is to work on the particular relaease of the software or part of the application,do testing whether manual or automation and find bugs and report.Thats it.


You find a major bug, but no developers are present. The release deadline is today. What do you do?

First question, what does major mean here? I guess major bug means: something that should block a release. Not your typical Blocker, Critical, Major, Minor, and Trivial. The question doesn't really make sense for Major bugs. E.g. something that has a workaround and does not break important user flows, maybe it is just an improvement or a missed feature.

I will advise to:

  1. Postpone the release
  2. Plan better, e.g. have developers available on release day
  3. Plan better, e.g. have testing done days before release day


  • Call the developers?

You should definitely report that issue and assign to developer. And if there is no developer present and you have to deliver the build, then deliver build and mention the issue as known issue.

Not the answer you're looking for? Browse other questions tagged or ask your own question.