I think this is something you're gonna have to just jump into and start since you don't have anything to work off of. it's going to take a lot of work, but at least you'll be able to work off your own ATFs once you finish. good luck..

I mean, start with trivial cases of the core functionality of what your system does. Then build upon it based on your own findings and what your clients report.

E.g. if your system loads images then put in a tiny 5x5px solid square or checkerboard pattern and see if it loads. Then try putting multiple images, different formats (webp, gif, png, tga) etc. see if that breaks anything, keep building out.

if there are zero automated tests, things probably weren't written with (automated) testing in mind, so there may be a lot of coupling... starting off with integration tests just to validate existing behavior is a good start. hopefully the existing applications aren't also inextricably bound to environments that are run on pet servers and managed by other teams...

It probably really depends on the project, though I'd probably try and start with the tests that are easiest/nicest to write and those which will be most useful. Look for complex logic that is also quite self-contained.

That will probably help to convince others of the value of tests if they aren't onboard already.