A New Playtester’s Guide to NDAs, Testing Phases, and Getting Started

Player.gg is one of the best entry points for people who want to break into game testing. Many of us use the experience and feedback we build here as a practical resume when applying for paid testing roles with larger studios. This guide is for new playtesters and anyone who still has questions about how the process actually works. It’s long on purpose—grab a drink, settle in, and let’s walk through the essentials.

We’ll start with NDAs—the legal side every tester needs to understand first—then cover what a typical playtest looks like across the different development phases so you know exactly what to expect.

What an NDA Actually Is

A Non-Disclosure Agreement (NDA), sometimes called a confidentiality agreement, is a legally binding contract. As the tester (the receiving party), you agree not to share, publish, discuss, screenshot, record, stream, or otherwise disclose confidential information about an unreleased or in-development game.

Confidential information usually covers unreleased builds, features, mechanics, story and plot details, characters, art, bugs, performance data, and sometimes even the existence of the test itself. Related materials and any feedback you provide also fall under it. You may only use the information for testing and giving feedback to the company. The company retains ownership of everything, including your feedback and ideas.

Why NDAs Matter

Studios invest heavily in development and carefully timed marketing. Early leaks can spoil surprises, kill hype, hand competitors useful information, disrupt the planned rollout, and in some cases weaken the legal protection of certain elements (novelty for patents or trade-secret status).

For companies, an NDA creates a clear legal obligation of confidentiality before they hand over sensitive builds. It signals seriousness, deters leaks through the threat of real consequences, and gives them a basis for action if something is disclosed. Many studios require every tester—including volunteers in closed alphas and betas—to sign one before participation begins.

For testers, the NDA is the price of early access. Signing it shows you understand the rules and can be trusted. Breaking it costs more than just the current test. It can damage your reputation in gaming communities and with studios, making future opportunities harder to get.

Important note: NDAs do not protect general ideas. Anyone can independently come up with a similar game concept. They protect the specific confidential details shared under the agreement.

Legal Aspects and Consequences of a Breach

An NDA is a contract. Violating it is typically a breach of contract and, in some cases, can also support claims for misappropriation of trade secrets (if the information qualifies and the company took reasonable steps to keep it secret). Remedies are primarily civil, not criminal, for ordinary playtester leaks. Companies decide how aggressively to enforce based on the severity of the leak, the harm caused, and the cost of action. Enforcement can be expensive and sometimes draws extra attention, so many studios rely on deterrence and quick account-level responses first.

Consequences generally escalate like this (exact outcomes depend on the specific NDA language, jurisdiction, evidence, and the company’s choice):

Most common first steps: Immediate revocation of playtest access. Ban from future playtests with that company (and sometimes related accounts or platforms). In some cases, bans from the finished game or other titles from the same publisher. Content strikes or removal demands on platforms. Companies such as EA have publicly warned that breaking an NDA during a technical test can cost you access to the test, future tests, and potentially the finished game itself.

Cease-and-desist / formal demands: A letter requiring you to stop disclosing, take down content, and sometimes destroy materials. This is often the step before court.

Injunctive relief: A court order (sometimes obtained quickly) requiring you to stop further disclosure, remove leaked material, and refrain from using the information. Many NDAs state that a breach causes irreparable harm for which money alone is inadequate, which supports requests for injunctions.

Civil lawsuit for damages: The company can sue for breach of contract and/or trade-secret misappropriation. Possible outcomes include compensatory damages (actual financial harm such as lost sales or costs to mitigate), liquidated damages if the NDA specifies a pre-agreed amount, recovery of the company’s legal fees (if the NDA allows), and other remedies. You may also face the costs of defending the suit.

Real-world examples exist. Epic Games has sued Fortnite playtesters over leaks of Chapter 2 material, seeking injunctions and damages. In China, miHoYo obtained a preliminary injunction and later a judgment against a tester who secretly recorded and disclosed unreleased character designs, requiring the person to stop, pay roughly 500,000 RMB in damages and costs, and publish a statement to mitigate the impact.

Additional fallout can include industry blacklisting or difficulty getting future testing or employment opportunities, reputational harm in communities, and (rarely, in more serious cases involving intent to benefit competitors or foreign entities) potential criminal exposure under laws such as the U.S. Economic Espionage Act. Ordinary sharing of screenshots or impressions by a volunteer tester almost never rises to criminal prosecution.

Practical Notes on NDAs

Always read the specific NDA carefully before signing. Definitions of confidential information, permitted uses, duration (often lasting years after the test ends or until public release), requirements to return or destroy materials, and remedies clauses vary widely. Some are extremely strict—no streaming, no screenshots, no discussing even with family. Many are one-way (protecting only the company’s information). For unpaid testers, the consideration is usually the access itself.

This is general educational information based on common industry practice and reported cases. It is not legal advice. Laws and enforceability differ by country and state, and individual facts matter. If you are presented with an NDA or facing a potential issue, consult a qualified attorney in your jurisdiction. Companies enforce these agreements because leaks cause real commercial harm. The spectrum of responses—from simple bans up through lawsuits—exists to protect that interest and deter violations.

The Testing Phases: A Simple Analogy

Once the NDA is handled, the next thing every new tester needs to understand is the different phases of testing. Here’s the easiest way I’ve found to explain the progression:

Think of it like making a bowl of cereal in the morning.

Pre-Alpha is getting out the bowl and the box of cereal. The basics are there, but it’s a long way from complete.

Alpha is pouring the cereal into the bowl. Things are more developed, but still incomplete and rough.

Beta is adding the milk. The experience is mostly complete, but not quite ready.

The finished game is when you add the spoon and start eating.

(For those of you who put milk in the bowl first: we can argue about that another day.)

Pre-Alpha → Alpha → Beta is the typical progression studios use to systematically find problems, improve the game, and reduce risk before launch. Each phase has different goals, levels of completeness, and expectations for testers.

1. Pre-Alpha

What it is

Very early development. The game is incomplete—often just core systems or a “vertical slice” (a small playable section that demonstrates the main idea). Many features are missing, placeholder art and audio are common, and the build is usually unstable.

Main goals

Prove that the core idea and basic systems work at all

Catch fundamental technical or design problems early (when they are cheapest to fix)

Validate the core gameplay loop

What testers typically do

Focus on whether the fundamental mechanics function. Report crashes, soft-locks, and major broken systems. Note if the basic experience is understandable or fun in its current rough form. Expect frequent build breaks and incomplete content.

Who usually tests

Mostly internal (developers + early QA). External testers are rare at this stage.

Tester mindset

“Does the foundation even work?” Be prepared for a very rough, incomplete product. Detailed balance or polish feedback is usually not useful yet.

2. Alpha

What it is

Core features and systems are implemented, but the game is still incomplete. Content (levels, quests, items, etc.) is often partial or placeholder. The build is playable end-to-end in limited form but remains buggy and unstable.

Main goals

Verify that major systems work together

Find high-severity bugs (crashes, progression blockers, broken core loops)

Identify missing or broken functionality

Begin checking basic performance and compatibility

What testers typically do

Play through available content and systems thoroughly. Focus on functionality and stability more than polish. Report crashes and freezes, broken progression or game-breaking bugs, major usability problems, and missing or non-functional features. Provide clear reproduction steps. Note when something feels fundamentally unfun or confusing—early design feedback can still matter.

Who usually tests

Internal QA + limited external testers (closed alpha). Sometimes invited community or partner testers under NDA.

Tester mindset

“Do the main systems work and can I progress?” Expect incompleteness and roughness. Prioritize severity over minor visual or balance issues.

3. Beta

What it is

The game is feature-complete (or nearly so). Most content is in, systems are implemented, and the focus shifts to polish, balance, performance, and remaining bugs. Builds are much more stable than Alpha.

Main goals

Find remaining bugs (including lower-severity ones)

Test balance, difficulty, and progression

Check performance, stability, multiplayer scalability, localization, and edge cases

Gather feedback on overall feel, fun, and clarity

Validate the game under more realistic player conditions

What testers typically do

Play more like a real player while still being systematic. Test a wider range of scenarios, edge cases, and long play sessions. Report bugs of all severities with good reproduction steps. Provide feedback on balance, pacing, clarity of systems, and enjoyment. Check for consistency, UI/UX issues, and performance problems. In open betas, also help stress-test servers and matchmaking.

Types of Beta

Closed Beta: Invite-only, often under NDA. More controlled feedback.

Open Beta: Public or widely available. Focuses on scale, real-player behavior, and last-minute issues.

Who usually tests

QA team + larger groups of external/community testers. Open betas can include thousands of players.

Tester mindset

“Is this ready (or close) for real players?” Feedback on fun, balance, and polish is now valuable. Still report bugs clearly—don’t assume someone else already found them.

Quick Comparison

Phase

Completeness

Stability

Main Focus for Testers

Typical Audience

Pre-Alpha

Very incomplete

Very low

Core systems work at all

Mostly internal

Alpha

Core features in, content partial

Low–medium

Functionality, major bugs, progression

Internal + limited external

Beta

Feature-complete (or nearly)

Medium–high

Bugs, balance, polish, performance, fun

Broader (closed or open)

Tips for New Testers

Always include clear steps to reproduce a bug, what you expected versus what happened, and system info when relevant.

Prioritize by severity (game-breaking first).

Stay constructive and specific—especially in Alpha and Beta, when design feedback becomes more useful.

Understand the phase: giving deep polish feedback in Pre-Alpha or expecting a finished game in Alpha frustrates everyone.

Communicate through the process the team has set (bug tracker, feedback forms, Discord channels, etc.).

After Beta comes final polishing, release candidates, and launch. The earlier phases exist so that by the time the game reaches players at launch, the biggest problems have already been found and fixed.

Treat every test as both a chance to help improve a game and a chance to build your own reputation. Do the work carefully, respect the NDA, match your feedback to the phase, and you’ll stand out as someone studios want to keep inviting back.