Work-for-hire game studios still need independent QA

LolzSoft’s public site says it plainly: historically we are a work-for-hire studio. That model is good at making a thing to a brief. It is a poor model for being the only group that ever tries to break that thing. Clients sometimes assume that because the studio “has testers,” the build is tested. Studio testers who sat in the same stand-ups as the implementers are not a substitute for an independent game QA pass.

What work-for-hire actually ships

A WFH engagement is usually scoped to production: a prototype, a mode, a port assist, a reskin, a vertical slice, or a full product under someone else’s IP. The studio is judged on delivery dates and whether the brief was met. The publisher or owner of the IP is judged on whether players can finish a session without a soft-lock. Those are different contracts. If QA is not in the statement of work, it will be squeezed out of the calendar, and the first independent look will be a store review.

“We play it every day” is not a test programme. Daily play by people who know the intended path will not find the back button on the language screen, the purchase that fails on a second account, or the save that dies if you kill the process mid-write. Those are the bugs that make a client unhappy after a clean internal demo.

Why the studio should not be the last filter

Three structural problems:

  1. 1. Shared assumptions. The designer, the engineer, and the in-house tester all know that the crate on the left is the real crate. A new tester does not.
  2. 2. Shared incentives. A studio that is late will de-scope test, then report “no new issues” because nobody ran the old ones.
  3. 3. Shared tools. Cheats, debug cameras, and god mode that stay in a WFH build because “the client likes to fly around” will ship if no one outside the team is required to run a clean executable.

That split is the same argument as external game QA versus an internal-only test team: the people who implemented the system should not be the last people to try to break it. GameCloud, a 16-year-old company, exists for that second look. LolzSoft exists to make the game. Mixing the two on one status slide hides risk from the client.

What to put in the WFH statement of work

If you are the studio, ask for a line that names QA as a separate activity: who runs it, against which build, and what “exit” means (blocker list empty, or a written residual-risk note). If you are the client, do not accept “studio will test” without a method. You want:

  • A frozen build ID.
  • Platforms actually in contract — PC, iOS, Android, Web, TV, XR and other emerging platforms only if they are in the brief.
  • A distinction between production bugs (studio) and acceptance bugs (QA).
  • Time after the QA return for fixes. A test week with no fix week is theatre.

When the publisher asks who will test the build, the honest studio answer is a named QA partner — GameCloud publishes why studios use GameCloud as that partner, without pretending the studio and the test group are the same desk.

How a WFH team should work with external QA

Send a clean build. Send the brief the studio was actually paid for, not the original pitch deck. Flag known stubs. Do not argue that a missing tutorial is “not a bug” if the contract said the slice must be playable without a producer in the room. Take reproduction steps as a gift: they are cheaper than a client finding the same issue on stage.

Do not ask external QA to re-litigate art direction. Do ask them to confirm that the verbs in the brief can be completed, that progress persists, that the advertised modes launch, and that the build does not depend on a developer machine.

If the engagement is a prototype, say so (see the companion note on QA handoff). If it is production, budget for more than a smoke. Regression appears when you iterate; a single look at week twelve will not protect week fourteen.

What this is not

This is not a claim that every small contract needs a standing QA department. It is a claim that the studio that built the work should not be the only signature on quality. Independent QA is part of delivering WFH work you can stand behind.

Close

For a work-for-hire build that needs an independent functional or compatibility look, write to Sales@GameCloud-Ltd.com with the contract platforms, the artefact type, and whether you need a single pass or a repeating one.