Releasing a build that has defects!...

Sounds weird right?! QA signing off on known defects for a release!

Should it happen?

If yes, when?

If no, what might happen?

This is quite a frequent scenario in these days of quick releases, early-to-market approaches.

Also, keeping the QA position aside, one needs to understand that it is impossible to create and release new software that works 100% of the time.

Finding a defect in Production by the customer is expected, and we - as in the project team / client - already have a process around on how to deal with it.

But, how do you give a go-ahead to releasing a software build that you know has bugs?

You either wait to fix all the problems, put in more money and delay the launch, which is not 100% sure to not have any bugs of course. OR you take the risk, give the product as is with the list of known problems!

At least you are in the market on time, with the latest technology at that very time, and giving at least something new for your customers so that they stay on with you.

So how do we go about giving a go-ahead?

We need to verify that the major end to end flow, and the happy flows are all covered by dev, PO(Product Owner) and the BA, and these flows work.

For small issues, the risk is minimal i.e. it impacts less number of users and one can always release fixes as updates. Most of the updates these days are automatic. I don’t even realise and most of the social apps get updated. Sometimes, I don’t even know if there were issues if any!

I understand that as a QA, we end up looking from the smallest possible defects to the biggest of problems. That’s what we get paid for.

But then there comes a time when you need to understand the risk of insisting on defect fixes and thereby not releasing the software.

As a QA, you should know what could impact more and what could impact less. What is ok to have known issue and give the solution around. What is that known issue that customer won’t mind even if you do?!

That’s when the true value of the QA comes when they are ready to contribute by putting themselves, The BA, the QA in User’s shoe and stating “ok, this is a low priority defect and a user will not be impacted much”, or “ We can always give a solution around this in case user faces similar issues”.

When it is risky to give a go-ahead on defects :

Just make sure you don’t ignore the known problems with damaging impact. It’s a loss of reputation to recall the faulty software.

Even if the BA says, “If you don’t know reproducible steps then it’s not a defect!!” remember, it’s always good to highlight than accepting that it may not happen to user.

There are times when the BA/ PO doesn’t want any open defects on board as it’s visible to stakeholders. Don’t end up in closing the bugs just because someone says. Make sure put a right comment in bug and then close it.

In summary:

It is a difficult choice between delaying a release, probably leading to loss of revenue and loss of loyal customers, or launch the faulty system, hoping that nobody notices until a fix can be made later. (the latter happens to me most of the times :) )

You need to ask the question “Is it worth taking the risk!?”