A few things stand out to me.
First, the ratio of developers to testers stands out as being very lopsided.
In my experiences, a good ratio is about 3-5 developers to 1 manual tester. This seems to work out well as long as the tester is involved from early in requirements development to begin to start identifying test strategies, approaches, and cases. The work to develop the tests begins at the same time as development on the functionality. In cases where the development is done and the work is handed off, I've found that the developers need to shift away to support testing as the tester has questions or isn't sure about behavior in edge cases unless it's explicitly documented somewhere.
Second, the testing in feature branches before merging to master is concerning. This is increased since there are conflicts that need to be resolved when merging the feature branch into master.
It seems like the code that is being tested is not the code that ends up in the mainline of the product. This means that you can't be sure that your tests are finding the problems that exist in the post-merged product. There are two ways to correct this. First, regularly merge the master branch into long-running feature branches and test. You may not need to retest everything, but if there are conflicts, you can analyze the diffs and choose what tests must be re-executed. Second, if you are working on a planned release cycle, something like the gitflow model may be useful in ensuring that master
reflects releases while having feature and development branches that are synchronized with each other.
Third, automate.
Work on automating your test suite. Make it very easy to run various test suites. A good focus would be on regression - finding and ensuring that previously fixed issues don't return. But automate as much as possible from the unit through the system level and make it easy to run. Integrating into a build process would also help to ensure that each branch is in a good state.
Fourth, quality is everyone's business.
Shift as much of quality assurance to everyone on the team. This may not be possible - in some cases, there are contractual or regulatory requirements that force a separation between developers and testers. Even in these cases, try to gain a full understanding of what the requirements really are and try to share the workload. From my experiences in regulated environments, organizations tend to misinterpret requirements, including around verification, validation, and independence and it's often not necessary to always have a hard line between development and test, and even when it is, development can do some level of testing to ensure that the testing group has a much easier time of it.