Approach
Document it. Then try to break it.
Testing isn't the first step. Before I design the tests, I find out what the system is supposed to do, what it depends on, and who's responsible for it. A lot of what turns into a real failure was already visible as a gap in that picture.
Start with what's already there
I read whatever documentation exists and talk to whoever knows the system, then trace what it actually does: the workflow, what it depends on, who uses it, and who maintains it. I write down what's missing and what's assumed but never confirmed.
Build a record I can trust
Then I check that picture against how the system actually behaves, not just what the documentation claims. That's where I establish what acceptable operation looks like: the boundaries the system is supposed to stay inside, and what it would cost the people relying on it if those boundaries slipped. The record keeps changing as testing turns up more. It isn't a one-time snapshot.
Test the system in front of me
The tests come from what this system depends on, how it's actually used, and what a failure would mean here: a dependency going down, credentials expiring, an event firing twice, a step interrupted partway through, or an answer that's wrong but reads as right. Where it helps, I'll build a fault tree working backward from the outcome you're worried about, or a failure-mode register mapping each step to how it could go wrong. For each one, I check what happens, whether anyone would notice, whether recovery works, and whether the person responsible has enough information to carry it out.
Explain what happened and why it matters
For each finding, I record what I tested, what happened, the evidence, and why it matters to the business, not just the system. I keep demonstrated failures, suspected causes, and open questions separate, so you know what's confirmed and what still needs a look. Each one names the consequence, who would need to act, a recommended corrective action, and how that fix could actually be verified.
Report what matters
The final report brings the record and the findings together: what the system is, where it's weak, and what to do next, ranked by consequence rather than by what was most interesting to find. It says plainly what held up under testing, what wasn’t tested, and what remains uncertain.
Investigation, testing, documentation, and recommendations are the offer. If you want the fixes built too, that's separate work, quoted on its own.