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