Release with the known issues dilemma

Hi
I have some kind of dilemma. User really wants a feature. But feature reqiremens, as often happens, where thrown into team just before release. As result we have a feature which is doing what customer wants and contains a lot of bugs. Question: would you agree to add this feature to release (customer really wants it) with list of known issues? Or release a product without feature and have the sleepless nights for a couple of weeks to make it better? And why? I would like to here you best practice advice based on your experience. As life does not always follow books and rules :wink:

  1. Here is what it is expected to do and here’s what it does.
  2. It solves that users problem, but may cause unforeseen problems for other customers.
  3. These are the bugs we know about it. It strongly implies others we haven’t yet found.
  4. We can’t account for the bugs we don’t know.
  5. Here are the risks this release represents.

At that point I would leave the release decision to someone else. Assuming you have that option. If you’re not the release manager or the test manager it’s not something I would assume the responsibility for. Even then I would fall back on “Here’s the risks I can tell you about. I can’t account for the possible business or operational risks.”

It depends

Some of your choice are:

  • Release to just that customer as a beta with a list of known bugs (this will require communication with the customer and their agreement)
  • Release, but give that customer and nobody else access to the new feature as a beta. Whether you can do this or not will depend on how you manage the product licensing.
  • Release, but flag that feature as a beta.
  • Delay the release and work to get as much fixed as you can (this is not something I’d prefer, because the delay will cascade onto your schedule and because working crunch hours is not a viable solution - and you run the risk of crunch hours becoming normal).

Regardless, document all the options and the risks you see for each, then hand the decision to someone who knows how each option will impact the business.

5 Likes

Thanks @katepaulk
I am going to suggest this top manager. I don’t like delays as well - beside everything else they make a team exhausted.
Btw, I am open for any another ideas as well.

Team decision right? You as a tester present the facts (this is what we tested, here is what works, here are some problems) and then let the team/stakeholders decide if they wish to release.

1 Like

From one side: if we do not release what impact will we have? May be release contains fixes several big problems, but introduce one minor. May be new functionality is advertised already and customers are waiting, buying hardware, signing contracts to use it. We should block release in this case only if we have major bug, real release stopper.
From other side: if we have time to fix the bug, no one waits us, okay, lets fix and release in a week.
Or we have some nice-to-have functionality and found critical bug, lets say, in clients money calculation. This is for sure release stopper.

@ihor_kurval, I have just found a critical bug… yes, just before I have read your reply :joy:

1 Like