I’ve been in this situation, and it’s never a fun place to be.
That said, you’ve got options - here’s what I’ve done in this situation:
-
Talk to people - you’re new to the organization, but there are people there who have been in the company long enough to be able to tell you about the product. Ask around your team to find out who is the best person to ask for the specific information you need (with a legacy product like this, you’re most likely to want to know why things are done the way they are - there will have been compromises and workarounds that have been built over the years and are now just “the way it works”.
-
Tour the software as a user - In the absence of formal documentation, you can use the software itself as your specification. If there’s a date field, what date format does it require. What are the logically valid dates (for example, if you’re recording a loan application and the software requires the applicant’s date of birth, the applicant should be at least x years of age).
-
If you have access to the application database, you can use database field sizes to tell you the maximum input length of text fields, for instance if the last name field in the database is a varchar(64), then the last name that’s entered into the application shouldn’t be more than 64 characters. Older software doesn’t always include field length specifications because back in the bad old days browser enforcement of attributes could be… erratic. (Of course, if it’s desktop software, there are other factors involved).
-
As you investigate the software, if you find something that doesn’t make sense to you, ask around. It could be behaving exactly as it’s supposed to. Or you could have found a bug.
-
Document what you’re doing and your observations. In something as large and complex as this, you won’t remember everything. If you get something wrong, you can always correct it - the key thing initially is to build yourself a map of what the software is supposed to do (I ended up with several hundred wiki pages which have proved to be insanely valuable over the years).
As a general rule, your best option is to start with what documentation you have and then treat the application as your requirements. From there, you can build out a set of testing documentation that acts as a guide to newer testers. If you’re really lucky, your documentation can become the basis of user manuals written by your technical writing team (I’ve had that happen. At one of my previous jobs it got to be quite common for the tech writers to ask me for my notes to use with their manuals - because my notes described how to set up the new feature and the potential problems that could be caused by failing to configure it properly).