Traditionally bugs are found in two ways in production: Bug reports reported by users and by repeatably scanning the log files for errors.

The problem is that very few users, only 1%, report errors that they find. When was the last time you reported an error to a software vendor?

Therefore, measuring application quality by counting the number of bugs users have reported is not an accurate way to do it. There are too many unknown errors that users will never report because they are not important enough for the user, but they might be vital for your team.

function saveDiscount(User accountOwner, string id, decimal discount)
{
    if (id == null)
    {
        throw new ArgumentNullException("You must specify account id.");
    }
    if (accountOwner == null)
    {
        throw new ArgumentNullException("You must specify account owner.");
    }

    var account = LoadAccount(id);
    if (account == null)
    {
        throw new InvalidDataException("Failed to load account " + id);
    }

    account.Discount = discount;
    SaveAccount(account);
}

The simple function to the right requires four tests to ensure that it works per the requirements, no matter if the tests are in code or done manually by a tester.

It's quite common that only one test case is made for a function, making sure that the successful case works. By not testing the fault paths, the code might continue with invalid data, and those errors can be tough to debug.

The important aspect of cyclomatic complexity isn't as a test indicator, but a comprehension indicator. The higher complexity, the harder for a developer to manage all the different way that the code can take. Complex code is much more prone for errors.

Your team should strive to have at most 20 as complexity in their functions, as the risk of bugs increases too much over that.