Suppose the product/application has to deliver to the client at 5.00 P.M, at that time you or your team member caught a high Severity defect at 3.00 P.M (Remember the defect is high severity), but the client won't wait for a long. You have to deliver the product at 5.00 P.M exactly.

Then, what is the procedure you follow as a QA in this situation?

  • 2
    Please stop adding trivial edits to this question. None of the edits provide a significant improvement. If you want to attract better answers, the correct method is to post a bounty on the question, not to keep making edits that add one or two words or characters.
    – Kate Paulk
    Commented Jul 3, 2017 at 15:45

7 Answers 7


This is a simple, if uncomfortable, situation to be in. Unfortunately, it does happen from time to time and you need to be ready for it.

The fact that the defect has been found close to the deadline is, in the short term, irrelevant. Your team has found a high severity defect, so you report it. Given the short timescales, you ensure that everyone who needs to know about it knows about it, so they have the information they need to determine -their- best course of action as soon as possible.

You must -absolutely- not ever hold off from reporting an issue, at least to your local management structure. That would, at the very least, ruin the reputation of your team and could potentially have much more serious consequences.

The next thing to do is to determine the answer to the obvious question: "Why was this found so late?". There are many reasons why this situation could arise - your test preparation could've been too light, you could've mis-prioritised some work, there may simply have been too much to do. As a member of the test team, you need to know what caused the issue and therefore how you can reduce the risk of it happening again.

Obviously, we don't live in a perfect world and it's possible that no action may be taken to resolve the defect before release. It's entirely possible that it makes more sense to go live with a bug and then release a quick fix, than to decide not to release at all. That's a different discussion, though.

For what it's worth, this has happened to me a couple of times over the past dozen or so years. It's a horrible feeling but as long as you've done your best, there's nothing more you can do.

  • 1
    thanks @Dave....nice thinking. anyhow we have to handle a client politely and I think we have to fix those defects ASAP.
    – Bharat Mane
    Commented Apr 21, 2016 at 12:54
  • 3
    Great answer. Hiding the issue is never the answer in my point of view. One addition: Before getting ready to answer the question: why so late, it would be good to get as much info on the issue as possible to share with your client/leaders. They will need to make a decision: proceed with the time sensitive release, even with the defect, or wait until it's fixed and validated. That decision will depend on the need, and from your perspective, the circumstances that cause the defect and the ramifications of the defect.
    – jruberto
    Commented Apr 21, 2016 at 16:27

Deciding to release with severe bug (and escalate next release with a fix) or postpone release is business decision. It can be done only by someone who understands how customer works.

Maybe it is not a big deal at the end, and you can go on with the release (and inform customers what bug is, and find workaround until bug is fixed.

Maybe system is not safe to use until bug is fixed, and release has to be postponed. Which might incur penalties, and only business managers know about the exact wording of the contract and possible penalties. Again, business decides, based on all the information which QA and developers can provide (including estimated time to fix it).

QA cannot "assure" quality. QA can "assist" business side with information about quality and process. Business decides what is best allocation of resources: more development, or more testing, or more management and control.

In situation like yours, you

  • escalate, informing management quickly about found defect (it is their job to understand client priorities and negotiate with the customer)
  • make a post-mortem analysis to find out a root cause why such severe defect was found at such late time
  • improve your process so root cause is eliminated.

The bug is high severity only so we send the application to the client and find out the severity is priority or not. If its priority then we ask him to wait. Here we found defects/bugs in the last minute of the delivery or release date- Then we have two options

  • Explain the situation to client and ask some more time to fix the bug.
  • If the client is not ready to give some time then analyse the impact of defect/bug and try to find workarounds for the defect and mention these issues in the release notes as known issues or known limitations or known bugs. Here the workaround means remedy process to be followed to overcome the defect effect.
  • Normally this known issues or known limitations (defects) will be fixed in next version or next release of the software.

There is no magical answer for this. Your options include:

  • Hide the bug and hope that the customer does not find it before you can deliver a fix.
  • Delay the delivery until the bug is fixed.
  • Talk to the customer about the bug and let them decide how they want to proceed.

The choice depends on your circumstances, and no one here knows those as well as you do.

If you find that situation unmanageable, I recommend quitting your job and finding work at a company where the ship date does not depend on the customer expectations, or even better, a company that sells a service instead of selling software. When your own company is the only consumer of your software, you can make these kinds of decisions in a more reasonable way.


First inform the project manager, the bug is critical so he will give some suggestions. If not, then raise as a bug and send it to the developer who was involved in the code so they may get some idea.

If the developer said it's not possible to fix within the time frame, then explain the flow of the application to the client. When the bugs is found, explain the issues of the priority and that it needs more time to fix the bug.

As the role of testers, we should give the product as bug free and stable without blockers or critical issues.

We should give the product which is tested thoroughly as a tester we are not satisfied with product and we are not able to give the product to the client, so the right testing give the right satisfaction of the client.

If the customer does not accept that, then we will give the application as well as release notes and we mention the bug in the notes, so we will fix the bug asap so customer can understand our situation...


Communicate in writing

  • Log the (severe) bug ticket, ensure it is reproducible if at all possible.
  • Determine frequency and effect
  • Immediately inform management using the ticket to track the conversation
  • Inform the testing team so everyone expects it and don't also log duplicates
  • Inform developers who are currently working in the codebase
  • Follow-up to ensure the issue and ticket is resolved and the resolution communicated.

Analysis of impact will be required throughout the process.
Initially it will need to be done in the order of minutes.


Lets keep every one (all who worked in the project from project manager to fresher) in loop draft a mail to offshore and onshore to make every one on same page. Have a discussion with development team whether it can get fix in short time & if so, have a QA strategy of required testing. If its not possible to fix in shorter time, communicate it to client and provide the workaround if any. Let the management and client come up with the plan whether go-nogo....

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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