"We follow best practices and cover our code with tests" appears on nearly every development studio's website, including studios whose repositories contain no tests at all. The claim costs nothing to make. If you are working out how to choose a software development company, it is the claim worth checking first, and you can check it in a call without reading code.

Ask to see a failing test

Not a passing suite — a failure. Ask what a developer sees when something breaks: is there a video, a trace, the exact step and the state of the page before and after? A studio that works this way will show you immediately, because they look at it weekly. One that does not will describe a process instead of showing you an artefact.

The difference matters to you directly. Without failure artefacts, every red test costs a developer an hour of reproduction before the fix even begins — and you pay for that hour.

Ask what their test files are called

This sounds trivial and is remarkably revealing. Test names fall into two families:

  • `test_login_1`, `checkout_spec_2`, `smoke_final_v2`
  • `the deposit is held when the card is declined`, `token refreshed mid-session`, `arbitration when both sides claim delivery`

The second family means someone decided what each test protects. The first means someone was ticking a coverage number. Ask for a screenshot of a directory listing; nobody needs to expose a client's source code to answer.

Ask which failures they have tested for

Every product has a list of things that have actually gone wrong: a payment that half-succeeded, a duplicate webhook, a session that expired at the worst moment. Ask which of those the suite covers.

A studio that tests only the happy path will answer in generalities about coverage. One that tests properly will name specific scenarios, and the names will sound unglamorous and oddly specific — because real failures are.

Ask where the suite runs and who owns it

Three follow-ups:

  • Does it run on every push, or when someone remembers?
  • Whose repository does it live in, and in what language?
  • Is there anything to install or subscribe to that stops working when the contract ends?

The answers tell you whether you are buying an asset or renting a dependency. The same holds whether you hire a whole studio or a test automation company for the testing alone.

The uncomfortable one

Finally, ask what they do not test, and what they would refuse to promise. If you remember one thing about how to choose a software development company, make it this question. Everyone has limits: load testing, security auditing, regulatory certification, guaranteed store review times. A supplier who claims all of it either has not thought about it or is willing to tell you what you want to hear — and you will find out which on the project, at your expense.

How to choose a software development company from the answers

Put the answers side by side and the choice usually makes itself: a studio that showed you artefacts beats one that described a process. For what it is worth, our own answers: thirty end-to-end journeys drive our marketplace app on a real device, one hundred and seventy-three tests across twenty-four suites assert the same flows from the server, and the operations platform we run carries eight hundred and eighty-four checks across its three repositories. We do not do load testing, we do not chase coverage percentages, and we will not promise you an App Store review time. Ask us the four questions above; that is what they are for. The numbers behind those answers sit in our own case studies, and the work itself is priced here.

Worth reading alongside it: who maintains the tests after the studio leaves.