WoW Forever Beta Day One: Testing Checklist for Classes, Quests, Dungeons and Systems

Create the test record before pressing Play #

Use Unknown for a field the client does not expose. Do not infer a region from a friend’s location, a layer from a loading screen or a class restriction from one unavailable button.

Test access, login and the client boundary #

Official material establishes Windows, Mac, internet access and the Battle.net desktop app. It does not establish the final selector, preload procedure, opening hour or every region’s launch behavior. The access guide owns entitlement and code explanations; this section owns the observation.

1. Confirm the account’s access path: opt-in invitation, Epic/Collection entitlement or another official instruction. Record the path without publishing a code or account identifier.
2. Record the client selector, installation location, download size if displayed, build and any preload or maintenance message. If a field is absent, write Unknown rather than guessing.
3. Enter the game and record the region, language, ruleset and character-creation screens. Capture the exact label for any limitation.
4. Repeat one logout or reconnect if safe. Note whether the same account returns to the same selection path and whether a queue or error appears.
5. Stop before changing accounts or buying another edition. A failed access path needs a support record, not a second untracked variable.

Test the class and race matrix before recommending a build #

Use the existing class pages for announced availability, then add beta observations only when the client supports them. One locked talent or missing race can reflect level, access, faction or build context; record that context before treating it as a restriction.

Trace one quest chain from pickup to reward #

Week one is capped at level 20, with level 30 planned later. Riverglades and maximum-level raids are outside that scope; early quest observations cannot fill later leveling or endgame coverage.

1. Choose one accessible starting quest and record the NPC, exact text, coordinates or named location, faction, race, class and level.
2. Follow every required objective. Record prerequisites, travel, phase or group requirements and any choice that changes the next step.
3. Capture the completion text, experience, currency, item tooltip and follow-up quest. Do not call a branch optional until the client shows the alternative.
4. Repeat the first pickup or completion on a second relevant character when possible. Note which differences come from faction, race, class or level.
5. Publish a route only when another tester can follow it from the recorded starting conditions.

Test one dungeon without writing the whole endgame #

The announced dungeon list and raid sizes are not a walkthrough. Test an available destination end to end, but keep boss mechanics, keys, loot tables and raid requirements Unknown until each has its own evidence.

Probe the systems that need more than a tooltip #

▶WATCH VIDEO EXCERPT · 39:58–41:26Choose HD or SD models; see restored animationsLoad YouTube player

Apply the shared status labels #

Needs playable verification is a page-level banner for the three beta articles. It is not a substitute for a section result. Keep the section label tied to the evidence that actually exists.

Publish a result only when the record is complete #

A failed test is still useful when the failure state is precise. Record queue, error, missing button or unavailable content with the same care as a successful route.

1. Attach the build, platform, region, ruleset, faction, character and party context to the observation.
2. Quote the exact client label or quest text and give the location or action that produced it.
3. Repeat the test or find an independent matching observation before moving from Observed in beta to Reproduced.
4. Update the narrow guide section, its review date and the source ledger. Do not silently rewrite an announcement as if it were a gameplay result.

KEEP GOING

Your next step.