Conveying the "bad" news...

This came up from an interesting discussion I was having with the colleague of mine. The situation is something like this- A Software Testing team is working in a high pressure release of a product in which a lot is at stake, so much so that most of organization's revenue depends upon its successful launch. In obvious terms, this is a very high visibility release in which all the stake holders are keeping an eye on daily progress. From testing perspective, everything seems to be going on track i.e. Test coverage is growing steadily, bugs reported are being logged timey with precise information, Bugs are being
fixed and regressed on time, the defect trends are under control and all this is giving huge confidence to the project stakeholders. The project reaches Release candidate phase riding on this confidence. The release is just a few days later and when all is looking so well and on the doorsteps of an immensely successful release with accolades awaiting everyone in the project.....BANG, BANG, BANG!!! Testing group comes across two new bugs and initial (rather tensed!) analysis by testing team reveals that these bugs "looks" to be showstoppers. Such situations are a common place in most of the projects. And these kind of situations are generally very stressful and a thought on "How to convey the bad news" often crosses a tester's mind. It turns out often that who/how to bell the cat.
Conveying the right information/status about the project to its stakeholders is one of the primary tasks of the testing group. So, every now and then, the tester would be in a situation where he/she would need to convey so considered "bad" news about the happenings in the project. Now, the question in mind is- how to deal with such situation? I have a few thoughts around this based on what I have observed in my experience-
1. Don't Panic...
The first reaction to such a reaction is usually that of Panic. But being in panic won’t get you anywhere and can worsen the situation. So, Don't Panic.

2. Don't blame yourself...
Another thing that might not help you think clearly in this situation is the feeling of guilt. Basically the feeling which says- I am the owner of testing the module under question and it was supposed to be perfect and bug free. Well, displaying ownership towards the task at hand is definitely one of striking qualities of a tester but it doesn’t mean that one ends up taking all the blame on self if something goes wrong (even without analyzing the situation). So, don’t blame yourself and understand that "any" tester can be in a situation that you are in. If at all it turns out to be your fault later, learn from it and emerge as a better tester.

3. Don't be defensive...
Other situation can be when the tester chooses to report the issue to his/her superior and immediately becomes defensive and starts putting in points in favor of his/her's argument even without being asked. The phrases like- "You know we never had specifications", "I don’t think it was even considered by a person who wrote the test cases", "I think i tested this in the last build and it worked, Must be that developers have made some late change" etc. take prominence. Being defensive means that a tester is trying to just save him/her and is not even thinking about the project. This is a situation which tells a great deal about the ownership potential of a tester. By getting into a defensive argument he/she is just trying to get away with the situation leaving an impression of immaturity.

4. Be ethical...
Conveying the bad news about the project status definitely needs a lot of courage. Those who are less courageous may even be tempted to cover the situation and do not even report the failure. Such an action is self-destructive and against the professional ethics. A tester is not doing his/her job if he/she is not choosing to report the issue. Do not fall into this trap, it may cause you to feel guiltier when the issue is reported by the customer.

5. Anticipate and Analyze...
Thinking with a clear mind, the next step is to anticipate what questions the project stakeholders might be asking you once they hear about the newly found issues. Usually, you might be asked the questions such as-
- Is this an failure that is reproducible all the times?
- Are the steps followed constitute the basic use case that a customer would be following?
- Is the Software failure severe that you user is not able to access other features?
- Was the failure prevalent in the previous builds that we tested? If yes, since when?
- Is the failure because of a recent code change?
- Is the failure dependent on a specific OS and the environment?
- Does the failure exist on all the supported languages?
Etc.
The key is to think about all the possible questions. You will notice that in most of the cases, the questions asked in this situation would aim at finding the impact the failure has on the release and not necessarily at finding the scapegoat. But it helps a lot to be prepared with answers to the questions such as-
- Why didn’t testing group find the issue earlier?
- Are there any flaws in testing process?
- Is this a human error by the tester?
Etc.
Once you have anticipated all the questions, the next step is to analyze the situation and dig into details to find more information about each question taking into consideration the bug under question. The Analysis should not be biased anytime thinking that testing group is not at fault. Remember, the primary goal of this exercise to provide project stakeholders with all the relevant facts.

6. Report the facts
Once the thorough analysis is done, the next step is to report the findings. A good report is the one that answers all the queries the recipient might have and at the same time the presented information is not too detailed that it takes a long time for a person to comprehend. One of the suggestions of the report format could be in a question-answer format in which answers to all the anticipated questions are presented either in an email or in a meeting/call with the stake holders.

7. Answering the questions not anticipated earlier
A good sense of anticipation comes from experience. It might as well be the case that there are some questions that were not anticipated earlier and these might take you by surprise. This situation can be very tricky to handle as these questions might get asked in a meeting constituting of various Senior Management personnel and other key stake holders. Some of these questions would be aimed at gaining more information about the failure and some "hard to answer" might question your ability.
The key is to be honest, have the facts in place and answer with tact. This is where Effective communication skills play a key role. There will be situations where it would be most apt to agree that it was the mistake by test team and make sure to follow-up with plans to avoid such instances in future depending upon the tone of the meeting.

8. Post meeting thoughts
Most of the times, everyone's priority is to get rid of this situation and make the release happen on time. If such is the case, then ensure to take the valuable learning post meeting and start thinking about how best to not be in such situations in future.
Sometimes, there can be the case that some of the stakeholders lose patience and give you a tough talk (read- shout at you). Well, if you are convinced that it’s an issue at your end, then it makes sense to accept the mistake and assure the stakeholder of the necessary steps that would be taken to improve the process. And if it’s not your fault, then presenting the facts and your conclusion politely often helps. It gets even trickier if you are on a telephonic call with a superior whom you haven’t seen or met in person. Maintaining calm and presenting facts in a right way helps you through successfully in such a situation.

Please share if you have been in such a situation and how you handled the same.