I suspect you need to be careful that you are not initially taking them a step backwards.
Iāve seen this scenarioās many times
Lots of test cases created. Majority were fairly useless, rarely found new things and carried a lot of waste.
Test suites. Documented in painful detail, often given to new starters in the false belief that they could learn both about testing and the product from them. There are so many better options for learning so again these suites were generally waste.
In many cases the best thing was to get rid of those test cases and suites and move to much more of discovery focused testing coverage with exploratory test sessions, in almost every case I have seen this is a massive step forward. Usually does come with testing session notes, risk analysis general useful info if someone new is coming on board but some just adapt to documenting purely what the team needs at that point.
Check if the team had any problems with what your predecessor was doing, what they did well and what opportunities there are for improvement.
Test cases and suites approach maybe what you know well but it could be a step back, so check if they had it before and consciously improved on that approach to a better way, perhaps they didnāt and a reset to the very basic testing model maybe what they need.
Leveraging from automation is a separate thing, there are almost guaranteed to be opportunities to leverage from automation so that needs an āautomation opportunity reviewā, do not do this in isolation do it with the developers if at all possible.
It will often seem as an obvious first step easy win to get a basic smoke test running and it does look impressive initially to managers but it can be time consuming, if your predecessor was doing really good testing and you are spending time on automation to the team it may seem like a drop in testing coverage.
If there is no automation at all, then starting with unit tests may make sense but then you need to consider do you have the influence over developers to push this good practice or do you have the skills to cover this. Often testers will jump to cover this at a slightly inefficient layer as that is their skillset, for me I am not even sure if some UI automation is better than no automation if there is no unit coverage.
Start with talking with the team and learning the product.
The last time I did this it sort of went like this.
Get everything set up so I can test - remotely this can take longer than you think.
Talked with every team member, challenges, get to know your session, where can they help me and where can I help them ideas came out of this.
As soon as I could test I was testing. There was a transition backlog, that became priority.
Once that was cleared and I was add value every day and not a bottleneck then and only then could I look at improvement opportunities with the team.
As a team we made a lot of improvements including the introduction of developer automation.
Note that not once did I look for test case or test suite documentation and not once did I write a test case down.