Lots of good answers. I've been in a similar situation and it took process changes in order to overcome the product issues.
Product quality issues are a reflection of the process used to develop the software.
For me, my QA philosophy is what I call "Quality First Development." This entails:
- Deliver Excellence: Users should not be finding bugs.
- Collaboration: Quality is a cross-team responsibility.
- Find Clarity: Reduce risk and uncertainty by testing early and testing often, which will improve confidence.
- Consider Perspective: Focusing on user experience, usability, and empathy improves quality. Be an advocate for the customer.
- Efficiency: Automate for functional efficiency and long term success.
- Be curious: “Why” and “What if” are the best questions to ask.
General questions to ask and consider:
When does testing start?
If it's only after the development is completed, you are waiting too long. Bugs, defects, glitches found earlier in the process are easier and cheaper to fix. I have found that once the stories and requirements are written, review them with the PM, Lead Dev, QA to ensure they are written clearly and without ambiguity. One reason bugs happen is a misinterpretation of the requirements between dev and QA, so if you can solve ambiguity earlier, less chance of bugs occurring.
This same goes for once the design mockups are finished. Review the design against the requirements to ensure they match. I can usually start test planning, test case design after the requirements and designs are finished and before dev starts. If you are doing testing automation, you can start creating automated tests before dev starts.
Are you grooming the bugs/defects weekly or on a routine basis?
This can help set bug priority, severity, as well as, including bugs for your development sprint. Bug grooming includes all bugs found by QA, Dev, and users/customers. With every bug found, you need to find the root cause analysis. This is where white box testing and knowledge of the code base can help.
I also like the advice given by the Ministry of Testing on fixing bugs.
Are the bugs following a bug template?
Every bug ticket written should be done the same way and include as much information as possible. This also helps speed up bug grooming and helps speed up root cause analysis.
When bugs do happen, find the root cause. Dig into the code, use 5-Why's. Ultimately, you want to understand where in the process the bug occurred, why it occurred, and how it could have been prevented.
What does your test automation pyramid look like? Are unit tests being done? Are integration testing being done? Are there UI, end-to-end testing being done? If there's no automation, it's time to start.
Are the devs using linting tools and following the same rule set in the linters?
Linters are an often overlooked static analysis tool, but they help all the developers play by the same rules, using the same coding standards. They can also help bubble up bugs early.
What about team attitude toward bugs? Is QA "blamed" for not finding bugs that ended up in production? If so, this "blame and shame" needs to stop as it lowers morale of the team. Bugs are going to happen. We are all humans and that's part of the creation process. How you deal with them matters.
In my experience, when I've helped setup these changes on a dev team, the amount of bugs going to production and being reported by users/customers decreased significantly, which also meant customer/user satisfaction went up.