A test suite is not a deliverable like a logo. It is a living thing that has to change every time the product does, which means the interesting question is not who writes it but who keeps it alive.
The three months that decide it
The pattern is consistent. A suite is handed over and runs green. The product changes; a few tests fail for legitimate reasons. Nobody on the team wrote them, so nobody is sure whether a failure means a bug or an outdated expectation. The safe response is to skip the test "for now". Within a quarter, a third of the suite is skipped and the rest is treated as advisory.
Nothing about this is unusual or lazy. It follows directly from a suite being someone else's work.
What actually prevents it
Tests written in the stack your team already reads. If your developers write TypeScript, a suite in Python is an artefact they will never touch, however good it is.
Tests named after what they protect. "test_checkout_3" tells a developer nothing. "the deposit is held when the card is declined" tells them immediately whether a failure is a bug or an expectation that needs updating — which is the exact decision they will be making, alone, on a Tuesday.
Someone on your side writing one before handover. Not watching a demo: actually writing a test, with us sitting there, and pushing it. It is the single strongest predictor of a suite surviving. A person who has written one test will fix a broken one; a person who has only read them will skip it.
A runbook written against your suite. Not a generic document about the testing framework — three pages about your suite: how to run it locally, how to add a case, what the data helpers do, what to do when it is red.
A pipeline that stops on red. If a failing suite still lets a merge through, it will be ignored on the first busy afternoon and never trusted again.
The honest options if nobody will own it
Sometimes there is genuinely no one. The team is two people, both busy, and there will not be a person for this. That is a legitimate position, and there are two honest answers.
One is a smaller suite: five smoke journeys rather than fifteen, cheap enough that rewriting them occasionally costs less than maintaining them. The other is a support arrangement where the studio keeps the suite current as the product changes — worth buying only if the product genuinely changes weekly, and worth refusing if it does not.
What is not honest is selling a large suite to a team with nobody to own it, and calling the result a success because it was green on handover day. The measure worth holding a supplier to is simpler: three months later, are there tests in the repository that they did not write? If not, the wrong thing was built. We write suites in your repository, in a language your team reads — the handover terms are on the service page, including who owns the tests afterwards.
If you have not read it yet: testing a mobile app is not testing a website.