Handing a rapid game prototype to QA without losing the brief

LolzSoft is a work-for-hire studio with a history in rapid game prototyping. A prototype that answers a design question is a success. A prototype that is thrown at testers with no freeze, no known-stub list, and no idea of what “done” means for this week is how studios waste both build time and QA time. This note is about the handoff — what to lock, what to label, and what to ask QA to do — not about how to brainstorm.

LolzSoft develops. GameCloud Technologies, a 16-year-old company founded in Indian financial year 2010-11, tests. Mixing those jobs in one chat without a freeze is how a prototype pretends to be production.

Prototype, vertical slice, first playable

Those three are not the same artefact.

A prototype exists to test a mechanic, a tone, or a technical risk. Large parts of it are allowed to be fake: greybox, debug spawn, one enemy type, a cheat to skip. QA on a prototype should be asked a question (“can a new player complete one loop without a spoken explanation?”), not a full test catalogue.

A vertical slice is meant to look and play like the shipped game in a narrow band. Placeholders that were fine in the prototype are now defects if they sit on the camera, the HUD, or the core verb.

A first playable is the first build you could put in front of someone who is not on the team and expect a complete short session. Save, quit, fail, retry, and the first reward have to exist.

Write which of the three you are handing over. Testers cannot guess. If you call a greybox a first playable, you will get a defect list about missing juice and ignore the mechanic question you actually needed answered.

Freeze before you invite testers

A useful prototype freeze is boring:

  • Build ID and how to install it on a clean machine.
  • The question this pass is meant to answer (keep, kill, or production estimate).
  • The intended loop in one page: start, core action, fail state, restart.
  • Known stubs (debug camera, one enemy, cheat skip) so testers do not spend a day rediscovering them.
  • Claimed devices, even if the list is “Windows PC only, keyboard and mouse.”

House platform language, when you are ready to name targets, is PC, iOS, Android, Web, TV, XR and other emerging platforms. A prototype does not need all of those. A product pitch that lists them does.

Do not send a pitch deck in place of a build. Do not ask testers to “just see if it’s fun” without saying whether they should also file blockers. Fun notes can sit in the same report as defects; they are not a substitute for reproduction steps.

What independent QA should do with a prototype

Once the pack exists, the right parent service is usually validation, not an unnamed “can you look at this.” That is the moment to send the build to game validation, not to keep demoing the same stub to new people and calling their confusion feedback. You are still deciding what the game is.

When the loop is decided and you need named test types on a build — functional, compatibility, performance, and the rest of the catalogue — that is core game testing services. If the prototype is already a candidate to ship on PC, iOS, Android, Web, TV, XR and other emerging platforms, name those platforms in the handoff so those services can scope function and compatibility against a real list.

Use validation to decide; use core services to verify. LolzSoft does not sell those pages. We link them because pretending a studio can QA its own prototype without a second pair of hands is how launch dates slip.

A practical sequence

  1. 1. Prototype until the loop can be taught in five minutes.
  2. 2. Write the freeze pack (build, loop, known stubs, claimed devices, the question).
  3. 3. Run validation so the design decision is informed by strangers’ sessions.
  4. 4. If the project continues, schedule functional and compatibility work against the real claim set.
  5. 5. Only then treat store copy and trailer lock as serious.

Skip step 3 and you will spend production polishing a loop nobody outside the room understands. Skip step 4 and you will discover device fails in review. Neither is a prototyping problem. Both are a testing problem you deferred.

What this page will not do

  • No invented shipped title, publisher name, or before/after chart.
  • No prices, pack SKUs, or headcount.
  • No claim that LolzSoft is a test studio. We build. GameCloud tests.

If a client needs production art, more modes, or an educational layer on the same prototype, that is still LolzSoft development work. It still wants a QA pass after each meaningful slice, not a single ceremonial look at gold.

Enquire

For a prototype that is ready to be seen by testers, write to Sales@GameCloud-Ltd.com with the build ID and the decision you need. For a new prototype, use the LolzSoft contact form on this site.