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?
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.
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
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
There is no magical answer for this. Your options include:
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...
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....
