Been in that situation, and far more than I'd like. While we'd like customers to provide complete and iron-clad requirements, it never (and I do mean never) happens. Well, unless you're shooting people into space. I hear they do a pretty thorough job.
For the rest of us, it's generally a continuum. The bits of this you don't have as far as requirements go, you'll have to rely on experience and make educated guesses. Obviously you know that exceptions, 500 errors, timeouts, and login fails are bad.
I've seen the "I can't test at all without requirements!!" mantra, and it's bupkis. You can test it. But it's not going to be "fully tested" in any sense of the word. :-)
I've found that sketching out my assumptions at the get-go helps direct my testing and gives me a good idea of how to prioritize/time box my efforts. This is especially important when "testing dark".
These are (always) some of the core questions I to ask. If the requirements answer them, great! If not, make your best guess.
Who is the tool/program trying to help? (target audiences)
What is the tool trying to help said folks accomplish? This isn't merely what they "do" with the tool It's the difference between "getting a photo onto a website" and "sharing pictures with family" ... the difference is sometimes subtle, but very important.
Does it do that? (this covers mostly happy path)
Reasonably easily? (this covers basic UI)
Once that's down, you (of course) will need more info as testing gets under way. I've found approaches like the following helpful in getting answers to the above...
"So is it more a experience assumed feature, or a level of experience?" <-- substitute examples as appropriate.
"I think this feature is supposed to work this way...is that right, or am I missing something?"
"Can you help clarify something for me, if I do X, should I see Y or Z happen? No? But Q should never happen, right? Ok. Well, it's doing Q .... "
I'd concur 100% with the 100% comments above. There is no such thing as a completely tested app.
You are not the "gatekeeper of quality" ... that's rubbish. Your job is to do your best to let those-who-make-decisions know the state-of-the-app. That job is bounded by time. Give me more time, I'll give you a more confident answer. Give me less time, I'll prioritize and do what I can but it'll be less deep.
This speaks to the ridiculous "complete run-through" request ... I generally will give a swag along the lines of:
In one day, I can hit 20% of the basic functionality, but only verifying to 5% deep.
Give me a week, I can hit more like 40% of the most used functionality, but it'll be more like 10% deep.
In a month, I can hit 75% of the functionality, with a 40% depth.
With the caveat: with more bugs found and longer fix times, those numbers will need to be adjusted.
I once had an old grizzled QA mgr ask me "How many QA engineers does it take to screw in a lightbulb?"
"None. We just report that it's dark."
True, but I'd add "but we will tell you when the light went out, how often it goes out, what the state of the switch was when it went out, whether we can make it go out repeatedly, in what room it went out, and who likely touched it last"
cheers - and good luck!