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?
2
-
1This is incredibly broad. Do you have any data to help? Consider things like classifying the reported defects to understand affected parts of the system or root causes, identifying areas of poor test coverage, identifying areas with poor automated test coverage, usage information for various features. But without more data to guide your effort, it's not possible to say what the next step(s) should be.– Thomas Owens ♦Commented Aug 18, 2023 at 11:36
-
I follow Thomas' perception - you are basically asking how to do better software engineering.– João FariasCommented Aug 19, 2023 at 13:39
Add a comment
|
1 Answer
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.
answered Aug 18, 2023 at 12:28
