I have been asked the following question during an interview:

Today is the release date and you have found some bugs. Being a Senior SQA Engineer, how would you write an email to a client about this situation? Would you postpone release or do something else? What would you write in your email?

  • 2
    If the bug was serious enough to push back the release date, I'd start by talking to the customer rather than informing them via email. Feb 24, 2016 at 12:56
  • 2
    How did you answer the interviewer, when you were asked this question? Feb 24, 2016 at 19:37

5 Answers 5


As this is an interview question I would like to tackle it from another point of view.

Instead of talking about the content of a possible e-mail I would do something else, describe that I do not think this is part of the QA role. I think we have a signaling role and not a role to communicate with end-clients.

Depending on the severity of the found issues I would give a GO/NO-GO advise to our internal business owners and let them communicate or discuss this with the client.


This is exactly why QA should be quality assistance not assurance.

When bug is found closely to release date, QA informs management. Business decides if it is a release-critical bug (and release is postponed), or not critical, and bug is added to list of known bugs and triaged for fixing.

It is business decision, not QA decision, to release a product, which likely has many other (non-release-critical) bugs.

Failure of QA was not to miss the bug, but to test critical areas well ahead of the release so such surprises will be avoided, and to get release code stable enough ahead of release to have time to do so. But again, buck stops with the management failing to develop the corporate culture prioritizing the quality, establishing processes to have automated tests for critical areas.

Quality cannot be "assured" by more diligent testing - only by consistently following the process which builds quality into the product.

What exactly you do depends of way too many variables:

  • do you have one customer, or many?
  • how important is the bug for majority of customers: inconvenience? are lives at risk?
  • how critical is the bug for keeping good name for your brand
  • how customers will be affected if release is postponed, do they have a workaround, say continuing to use old release
  • how important are other features released (if ie. regulations are changing for certain date, you have to release even with release-critical bugs)
  • how long it will take and how much it will cost to release new fixed release (resources)
  • do you have skills to fix it, or you have to pay someone else
  • etc.

Please note that many of these variables are business-related, not QA-releated.

Also see this Workplace.SE question: https://workplace.stackexchange.com/questions/62542/how-to-tell-client-about-having-missed-their-deadline - and more there.


It should not be up to QA on if the release is postponed it should be up to the client / product owner. So providing them with enough information so that they can make this decision is very important.

Things that you may want to consider highlighting:

  • What the bug is and how they can replicate it.
  • Is the bug present in previous releases which are already live?
  • Estimates on how long it can take to fix and re-schedule the release, can also be a factor.
  • What impact the issue has on the live site. e.g. I something just out of place in a certain browser or does it stop a user from buying something.
  • What is or can be done to try and catch this type of issue earlier next time.

Overall, its best to be honest and not cover anything up and if there is an issue, highlight it sooner rather than later.


Your actions should be as below before writing an email.

  1. Get the list of bugs and its priority
  2. Quick discussion with dev team, how long will it take this to resolve the bugs
  3. Get the history and try to find out reason of bugs why this were missed.
  4. Try to figure out the impact of bugs on release.
  5. If impact is big your email should conclude to postpone the release and if impact is low your email should conclude in such a way that client needs to take decision on it.

Then put all this details in polite way and send an email to client.


You will always find some bugs, even on a release date. It just depend how though you test. My presumption is that on release date is too late to fix anything.

If there is space to make some hotfix, ask your DEV team to solve showstoppers/blockers.

Later, with the rest of bugs:

  • If your communication with customer is set to be transparent and trustful:

    1. Definitely, you SHOULD report them.
    2. Best practice is to make standard part of the delivery a "List of known bugs".
    3. Do the quick communication on the list of the bugs with customer to decide, which of them should be hotfixed ASAP and which will wait till next release or if there is a showstopper/blocker which cannot be released.
    4. Make this points to be your project habit.
  • If your communication is not set to be transparent and trustful,

    1. make steps to set it up first,
    2. be diplomatic,
    3. show the errors to internal team,
    4. raise that issue, but
    5. let the Project Manager to tell it to the customer.
    6. Recommend to your PM points 1..3 above.

    (or eventually find another project/job if this is not possible to be set).

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.