Those of you who are in the software testing industry, would have experienced this. You have worked long hours to meet a release deadline. Everything you have done has passed. All boxes have been ticked. All defects have been closed. All results have been stored in common repository. Test Summary Report has been issued and approved by all stakeholders. Deployment plan has been issued and approved. You have organized testers to perform Production Verification Testing (PVT) on the day of the release..

In short, you have completed all tasks and are ready for the release.

Yet……..you are dreading the release date. You are thinking:

• Has the new code broken some existing BAU functionality that we failed to test?
• Would the production support team raise any sev-1 (critical) or sev-2 (major) defects?
• Would we be asked the same question again: How did we miss this in testing?
• Would this negate all the hard work that has gone into completing the testing for this particular release?

Ever felt like below (courtesy of http://www.stellman-greene.com )?

The secret to surviving the release date is as below.

First, don’t be so hard on yourself.

No application can be bug free.

Despite the myth, application cannot be 100% bug free. If that was true, then there would have been no need for windows to do updates on a regular basis to fix bugs and security issues. We do not have unlimited resources or time to test an application completely. Often risk based testing approach is adopted. So there is likelihood that some inherent bugs may slip through. What we need to keep an eye on and where test expertise comes into play is that there should not be any sev-1 or sev-2 defects and core functionalities should not be broken.

Second, the release is a collaborative work.

If we succeed, we do it with other groups: development, deployment, release management.

If we fail, historically development and testing are blamed. Try to think that the release has made it better for customers, despite the few defects that may have slipped through. It is probably a change in your thought process but it works!

Third, you will always get blamed for defects.

So get used to it.

The type of accusations I have encountered in my professional career are:

• Why didn’t we find these defects?
• (Even when defects are found) Why did we find it so late in the SDLC process?
• (When we quote for test estimates involving extensive testing) Why is test estimate so high? Development effort is quite low, so why is test estimate so high? Can test estimate be lowered?

So you can see that no matter what we do, when things do go wrong, we would be the first to blame. Its just the nature of the game/profession.

Fourth, remind yourself that you have done the best of your ability.

You have had the test scope and coverage approved by business. You have been sending daily test execution report to all stakeholders. You have been keeping everyone informed about the status of defects with the application. And most importantly, you have been transparent with your tasks and efforts, including tracking of work and budget.

No can ask more than this from you as a test expert. No one can claim of sudden surprises or risks to the project delivery, if you have done all of above properly.

Fifth and most important of all,

Relax, enjoy the work and believe in yourself.

As a test expert, you must have confidence in your ability and have a bit of an ego. You know you are good and you know that you can handle any project, small or big. Let your work speak for itself.