Firstly, congratulations on your new role! It seems like you have a lot of work in front of you.
I believe your management hired you in order to fix the situation where there are a lot of bugs in production, therefore, most probably, you’ll have the support you need to institute changes you propose to improve the quality of the product.
Now, you need to get meta and try to figure out where the bugs are coming from:
- Are features not correctly defined?
- Are you shipping too many features too fast instead of investing in quality?
- Are features not tested properly before the release?
- Or are there a lot of regression issues that could have been prevented with more widely used regression testing?
As you can see from the questions, the right answer on what to do first (and you probably would need to do a lot) depends on what is the reason for those bugs.
If you work in a startup there is a good probability that you are at the exact moment where the MVP starts to become a real product and, therefore, the number of bugs explode with the number of features.
If this is the case, it is important to understand that you won’t be able to fix everything immediately, however, you can start changing things and paving the way.
And it is extremely important to get the priorities right and address the most important issues first.
I’d ask the CEO/CFO how many customers were lost because of bugs and how many deals didn’t happen because of bugs and what were these bugs. This will help you to get understanding of how company operates and what process you can institute to prevent as many important issues as possible.
Then you can propose your plan and discuss what is important with the management, and then act accordingly.
Some common notes:
One of the things we see, BTW, is that unit testing is a tool to help engineers to deliver features faster. Because, in many cases they could just run quick unit tests instead of starting the whole system and go through the steps to test the feature they are delivering. So, definitely there was some kind of misconception there.
Other than that, I’d suggest trying testRigor - your team even if they don’t have automation skills will be able to quickly build tests (like 15X faster than with Selenium/Cypress/Playwrite) and those tests are in plain English, so you can involve PMs into the review of those test cases. Disclaimer: I’m a co-founder of testRigor. If you can automate majority of the most important functionality within months then at least you free your team up from the tedious manual regression.
If the issue is related to the definition of features being purely understood you can involve BDD or SDD to make sure that specs are understood correctly.
In any case, all the best with your journey, I’m happy to elaborate more if you’d like, just ping me on LInkedIn here.