A QA brief is one page with 10 fields that tells testers what build to install, what to test, what to skip and how to report what they find. Write it before the build goes out, keep each field to a few lines and attach the known-issues list. A tester who gets this page on day one starts logging useful bugs in the first session instead of the first afternoon.
What goes in a QA brief?
Every game testing brief answers the same 10 questions, whether the test is a one-day check or a month of regression passes. The table below lists the 10 fields and fills them in for Hollow Ferry, a fictional co-op roguelite heading to Early Access. Hollow Ferry is an example only, invented for this article. Two free references help with the harder fields: the sample QA report shows the full report structure and the severity scale, and the bug report grader scores any bug report on 8 criteria, so you can check what format to ask for.
| # | Field | What to write | Example (fictional game Hollow Ferry) |
|---|---|---|---|
| 1 | Build access and branch | Store, branch name, password sent separately, build ID | Steam, branch qa-ea, password by DM, build 0.9.3 (ID 1184) |
| 2 | Milestone and date | What the build is for, when players get it, when you need the report | Early Access launch on 3 Dec; report by 21 Nov |
| 3 | Scope: test this, skip that | 3 to 5 areas in, plus areas out | In: first 60 min, co-op join, save and load. Out: chapter 3, placeholder VO |
| 4 | Minimum spec and hardware | Min spec from the store page, must-cover devices, input | GTX 1060, 8 GB RAM, Windows 10; Steam Deck; controller and KB+M |
| 5 | Known issues | Bugs already logged, with tracker IDs | HF-212 lobby timer desync, HF-230 missing subtitles in cutscene 2 |
| 6 | Priorities and severity | Top risk for this milestone, severity and priority scales | Top risk is save corruption in co-op. Scales: Critical to Cosmetic, P1 to P4 |
| 7 | Tracker and report format | Tool, access, required fields, language | Jira project HF, required fields as in the sample report, English |
| 8 | Contact and response time | One named person, channel, reply time | Producer, Discord #qa, replies within 4 h on working days |
| 9 | NDA | Status and rules for screenshots and streaming | NDA signed; no screenshots outside Jira, no streaming |
| 10 | What the report must contain | Sections and delivery date | Summary, counts by severity, top 3 risks, coverage, bug list with video |
The severity and priority scales in field 6 come from the Jumbo Jelly sample QA report (accessed 27 Oct 2026): 4 severity levels (Critical, Major, Minor, Cosmetic) and 4 priority levels (P1 fix before release, P2 fix soon, P3 fix when possible, P4 backlog). Severity says how bad a bug is for the player. Priority says how soon to fix it given the milestone. Writing both scales into the brief means your team and the testers sort bugs the same way.
If you want to try this brief on a short, low-risk job before a bigger launch, a Smoke Test puts one tester on your build for 8 hours and returns a prioritized report in 2 working days. The 10 fields above are what that tester needs on the first morning.
Which fields take the longest to fill in?
Fields 3 and 5 take the most thought. Scope forces a decision about what matters for this milestone, and the known-issues list means someone has to clean up the tracker first. Fields 1, 8 and 9 take minutes and still cause the most delays when they are missing.
For field 1 on Steam, a password-protected beta branch is the usual route. Steamworks documentation says testers must enter the password before they can see or access the branch, and players switch to it under Properties, then Game Versions & Betas (Steamworks: Branches, accessed 27 Oct 2026). Put the branch name in the brief and send the password through a separate channel.
Copy this QA brief template
The template below is the same one-page brief as a Markdown file. Copy it into your doc tool, or download qa-brief-template.md and fill in the brackets. Delete any line that does not apply to your build instead of writing “N/A”.
# QA brief: [Game title], [milestone]
Source: jumbojelly.com/how-to-write-a-qa-brief/ (free to copy and edit)
## 1. Build access and branch
- Platform / store: [Steam, Windows]
- Branch: [branch name], password: [send separately]
- Build ID or version: [e.g. 0.9.3, build 1234]
- How to switch to the branch: [Steam > Properties > Game Versions & Betas]
## 2. Milestone and date
- Milestone: [Next Fest demo / Early Access / 1.0 / patch]
- Date the build goes to players: [YYYY-MM-DD]
- Date the report is needed by: [YYYY-MM-DD]
## 3. Scope: test this
- [Area or feature 1, e.g. first 60 minutes, new player flow]
- [Area or feature 2]
- [Area or feature 3]
## 3b. Scope: do not test
- [Area that is unfinished or out of scope]
- [Placeholder art, audio, text that will change]
## 4. Minimum spec and hardware
- Minimum spec: [CPU / GPU / RAM / OS]
- Must-cover hardware: [e.g. Steam Deck, low-end laptop, ultrawide]
- Input: [keyboard and mouse / controller / both]
## 5. Known issues (do not report)
- [Known issue 1 + tracker ID]
- [Known issue 2 + tracker ID]
## 6. Priorities and severity definitions
- Top risk for this milestone: [e.g. save system, co-op join]
- Severity: Critical / Major / Minor / Cosmetic
- Priority: P1 fix before release / P2 fix soon / P3 fix when possible / P4 backlog, studio decides
## 7. Tracker and report format
- Tracker: [Jira / Linear / GitHub Issues / Google Sheet], access for: [emails]
- Required fields: title, severity, priority, build ID, area, hardware/OS, reproducibility, steps to reproduce, expected, actual, video or screenshot
- Language: [English]
## 8. Contact and response time
- Main contact: [name, role, Discord/Slack/email]
- Answers questions within: [e.g. 4 hours on working days]
- Who decides on blockers: [name]
## 9. NDA and confidentiality
- NDA: [signed / to sign / not needed]
- Streaming, screenshots outside the tracker, sharing the build: [allowed / not allowed]
## 10. What the report must contain
- Summary with counts by severity
- Top 3 risks before the milestone
- Coverage: what was tested and what was not
- Bug list with repro steps and video
- Optional: game-feel notes (not bugs)
- Format and delivery: [PDF / tracker export / both], by [date]Three habits keep the template useful over several builds:
- Save a copy per milestone (demo, Early Access, 1.0, each patch) instead of editing one file forever.
- Update field 1 and field 5 every time a new build ID goes to testers.
- Link the brief from the tracker project description, so it is one click away during the test.
What changes when testers get a one-page brief?
A brief changes where the first hours of testing go. Without one, testers spend that time working out access, guessing the scope and asking questions your team answers one at a time. The table compares the two situations field by field, based on what each field controls in the report.
| Situation | With a one-page brief | Without a brief |
|---|---|---|
| First session | Tester installs the right build from the named branch and starts on the listed areas | Time goes to finding the build, the password and the right person to ask |
| Coverage | Report states what was tested and what was skipped on purpose | Coverage follows whatever the tester found first; gaps are hard to see |
| Known bugs | Testers skip logged issues and look for new ones | Known issues come back as duplicates your team has to close |
| Severity | Bugs sorted on the same 4-level scale your team uses | Each tester’s sense of “major” differs; triage starts with re-labelling |
| Priority | P1 items line up with the milestone date in field 2 | Priority is guessed without knowing what ships when |
| Hardware | Min-spec and Steam Deck runs are planned | Bugs come from whatever machine the tester owns |
| Report | Arrives in the format and tool you asked for | Arrives as a document someone on your team re-types into the tracker |
None of this needs a big process. The brief is the cheapest part of a QA engagement to get right, because it costs your team about an hour (editorial estimate) and shapes every hour of testing after it. For how testing hours turn into budget, see how much game QA costs.
Five mistakes we see in game testing briefs
These are editorial observations from the Jumbo Jelly team’s test work, not measured data. They are the gaps that most often send testers back to the studio with questions.
- Scope with only an “in” list. “Test the whole game” leaves testers to decide what matters. Name the 3 to 5 areas that carry the most risk for this milestone and say clearly what to skip, such as unfinished chapters or placeholder audio.
- No known-issues list. Testers then rediscover bugs the team logged weeks ago. A short list with tracker IDs saves both sides time, and it tells testers which fixes to verify.
- Build ID missing or out of date. When the branch updates mid-test and nobody says so, bugs get logged against the wrong build and can’t be reproduced. Put the build ID in field 1 and post every new upload in the contact channel.
- Severity left to the tester. Without written definitions, one tester’s Critical is another’s Minor. Copy the 4 severity levels and P1 to P4 into the brief, or link a repro steps standard and a sample report.
- A contact who is busy shipping. The lead programmer in crunch is the worst possible contact. Pick one person who can answer within a few hours and give a backup name for blockers.
How to write the brief in about an hour
Most of the content already exists in your tracker, store page and team chat. The work is collecting it on one page.
- Copy the template and fill in field 1 and field 2 from your build pipeline and launch calendar.
- Open the tracker, close stale tickets and export open bugs into field 5.
- Agree scope (field 3) with whoever owns the milestone, in a 15-minute call if needed.
- Copy the minimum spec from your Steam store page into field 4 and add any device you care about.
- Fill fields 6 to 10, send the brief with the build, and ask testers to confirm access on day one.
Send the brief at the same time as the build. Testers can then raise questions before the first session, while answers are cheap.