Our company has more than 130 customer side bugs in just one moth after release. How can I reduce it as team lead? [closed]

Question

Our company has more than 130 customer side bugs in just one moth after release. This problem exist before I join the organisation. My manager assigned me to reduce the number of bugs in production and allocated a new dedicated smoke test team under me. my team need to perform system testing in every sprint and make customer reported bug below 75. Can anyone share your ideas and experience lessons to solve this bottleneck?

Answer 1

Since your team can't prevent or remove bugs, I presume you mean that your team is supposed to catch as many bugs as possible so that the number of bugs reaching customers each release drops to below 75.

It sounds to me as though your team is the first/only set of testers the organization has employed, which means you will need to be a testing advocate as well as a test team lead.

I can't give you answers, but I can offer suggestions.

Core Functionality First - tour the application, and note which functions are essential to using the software. Note how many of the customer-reported bugs fall into this region. Your team's first priority is to get the most used and essential features as solid as they can be.

Buggy Features - Go through the reported bugs, and note the features where they occur. Chances are that bugs will cluster in certain features - these are indications that your second area of focus should be these features (unless they are core functionality, in which case you are already focusing on them)

Automation - To prevent regression, once you have an idea of the core functionality and the biggest problem areas of the software, start building automated tests to cover core functionality first, then other problem areas. This will be a long term project that will ultimately act as insurance to assure the team that any breakage of existing tested features will be caught. I recommend at minimum a nightly run of test automation so that regression of existing tested features will be caught within a day of being introduced to the code. If you can run an automated smoke test with every build of the software, so much the better.

Anything Else - Once you have the core features and problem areas under control, you can start focusing on other parts of the software. This is unlikely to happen for at least a year, possibly longer, since your team is going to have to use manual and automated techniques as well as build automation until you have a stable regression test suite. They will also be retesting corrected bugs, performing exploratory and scripted testing on any new development, and - ideally - reproducing any new customer-reported bugs to add detailed reproduction information.

This is a difficult task you and your team have been given, and it will be a long-term task. I suggest that you monitor the number of bug escapes with each release, and choose milestones to celebrate. A reduction in 25 bug reports per release looks like a good starting point, but if that seems too ambitious don't be afraid to adjust it.

You should also be ready to celebrate when your team reaches the milestone you've been given. With this task, you will need milestones to mark your progress.

Answer 2

1. Root Cause Analysis:

• First things first, let's collect all the bugs and categorise them by type or functionality.

• Are there any patterns? Maybe many bugs are just symptoms of a common issue.

• Let's have a with the development team. We might find some insights while discussing the recent code changes.

2. Strengthening our QA Process:

• Time to revisit our QA routine. Are there gaps that we're missing?

• Perhaps, adding more testing stages, like integration or UAT might be beneficial.

• Also, have we thought of automated testing tools? They could be game-changers.

3. Feedback Loop:

• How about more frequent sync-ups between QA and our devs? Communication is the key.

• Using tools like Jira, MS-Teams could help in getting instant feedback.

• It's essential that our devs tackle these issues promptly; let's keep the backlog short.

4. Training:

• Noticed some recurring coding issues? Let's make a list.

• Some training sessions could help. Sharing knowledge is always good.

• An external workshop now and then could bring fresh perspectives.

5. Clearer Documentation:

• Let's go through our documentation. Any ambiguities or gaps?

• A good documentation refresh can make a big difference.

• And of course, we need to ensure the team is aligned with any changes we make.

6. Time for Retrospectives:

• Monthly retrospectives sound good? Discussing highs and lows can be insightful.

• We should convert our discussions into actionable steps for the next month.

• Continuous improvement is the way to go.

7. Bug Prioritisation:

• Let's sort and prioritise these bugs. Not all bugs are created equal.

• Setting aside dedicated time for bug fixing could be a good strategy.

• Testing is crucial. We can't afford to have more bugs while fixing some!

8. Bug Tracking Tools:

• If we're not using a bug tracking tool, now might be the time.

• A quick training to get the team onboard is a good idea.

• Tracking bugs can help us stay on top of things.

9. Engage with Customers:

• How about a feedback portal? Direct insights from our users can be invaluable.

• Someone should definitely keep an eye on this portal regularly.

10. Phased Rollouts:

• Releasing updates to smaller user batches might help.

• We can gather feedback, make necessary changes, and then roll out to a bigger group.

• This iterative approach might save us from many future headaches.

11. Automate Regression Testing:

Automated regression tests can ensure that new code changes don't introduce new bugs or reactivate old ones. This automation will allow the team to focus on new features while maintaining confidence in the existing functionalities.