eLearning QA Checklist – 60 Things to Test Before Launch

The course looks finished, and the stakeholder has seen a demo and loved it. Then it goes live and the help desk lights up: the quiz won't submit on tablets, module three never marks complete, and a typo sits in the title of the final screen. Every one of those was detectable with basic quality assurance (QA), and a real eLearning QA checklist turns "I clicked through it and it looked fine" into a repeatable test. What exactly should you test before an eLearning course launches?

Before launch, test seven areas: content accuracy, navigation, audio and video, interactions and assessments, accessibility, learning management system (LMS) tracking, and device and browser behavior. The checklist below breaks those into 60 specific checks. Run them on the beta build in the real LMS, not just in the authoring tool's preview, because many of the worst bugs only appear once the course is packaged and launched. Use a tester who didn't build the course, log every issue with a screen ID and severity, and retest each fix before sign-off.

How to Use This eLearning QA Checklist

Use this eLearning QA checklist on the beta build, with final audio and the real LMS, and assign each section to a named tester. QA is faster and more thorough when it is divided by focus, because one person reading for typos will miss a broken trigger, and one person testing tracking will miss a mispronounced term.

A few ground rules make the difference:

• The builder should not be the only tester. Builders know where to click and miss what confuses everyone else.
• Test against the approved storyboard, not memory.
• Record each issue with the screen ID, what happened, what should happen, the device and browser, and a screenshot.
• Rate severity so the team fixes the right things first.

Content and Text (1 to 10)

Content checks catch the errors learners notice first and trust least, so read every screen slowly, with the storyboard open beside the build.

1. All on-screen text matches the approved storyboard.
2. Spelling, grammar and punctuation are clean on every screen, including buttons and pop-ups.
3. Terms, product names and acronyms are used consistently.
4. Acronyms are spelled out on first use.
5. Numbers, limits and dates match the source documents.
6. The course title, module titles and menu labels match each other.
7. Text fits its boxes with no overflow or cut-off words.
8. Fonts, sizes and colors follow the style guide.
9. Images and icons match the content they sit beside.
10. Legal, compliance or copyright notices are present where required.

Navigation and Functionality (11 to 19)

Navigation testing means clicking everything, in every order a real learner might try, including the impatient ones who click Next before the narration ends.

11. Next and Back buttons work on every screen.
12. The menu links go to the right screens.
13. Locked screens open only after the learner meets the condition.
14. Resume works: close the course midway, relaunch and land in the right place.
15. Every button, hotspot and link responds and does what its label says.
16. No dead ends: the learner can always move forward or exit.
17. External links open in a new window and still work.
18. Attachments and resources open and are the current version.
19. The exit button closes the course cleanly without losing progress.

Audio and Video (20 to 27)

Listen with good headphones and with laptop speakers. Problems that hide on one often jump out on the other.

20. Narration matches the approved script word for word.
21. Technical terms and names are pronounced correctly.
22. Audio volume is consistent from screen to screen.
23. There are no clicks, hums, clipped words or long silences.
24. Animations and on-screen text sync with the narration.
25. Videos play, pause and replay correctly.
26. Captions are present, accurate and timed to the audio.
27. Audio doesn't overlap when the learner moves quickly between screens.

Interactions and Assessments (28 to 36)

Assessments carry the most weight for compliance courses, so test them the way an auditor would, by trying to pass with wrong answers and fail with correct ones.

28. Each interaction works the way the storyboard describes.
29. Correct, incorrect and partial feedback all display with the right text.
30. Every possible answer path in a branching scenario has been tried.
31. Quiz questions have exactly one correct answer, unless designed otherwise.
32. Answer options randomize if they should, and "all of the above" doesn't break when shuffled.
33. The passing score matches the requirement.
34. The number of attempts and the retry behavior work as intended.
35. Results and review screens show the right information.
36. Drag-and-drop targets accept the right items and reset correctly.

Accessibility (37 to 45)

Accessibility checks deserve their own tester if you can manage it. The W3C's Web Content Accessibility Guidelines (WCAG) are the standard most organizations measure against.

37. Every meaningful image has alt text, and decorative images are marked decorative.
38. The whole course can be completed with a keyboard only.
39. Keyboard focus is visible and moves in a logical order.
40. A screen reader reads each screen in a sensible order.
41. Text and important graphics meet color contrast requirements.
42. No information relies on color alone.
43. Every interaction has an accessible alternative if the main version can't be operated by keyboard.
44. Nothing flashes more than three times per second.
45. Learners can pause, stop or replay audio and moving content.

LMS and Tracking (46 to 54)

Tracking bugs are the ones that generate angry emails, because a learner who finished the course still shows as incomplete. Test in the production LMS or an exact copy, using the standard your LMS expects, such as SCORM (Sharable Content Object Reference Model). Rustici Software's SCORM explainer is a good primer if tracking is new to your team.

46. The package uploads to the LMS without errors.
47. The course launches from the LMS on the first try.
48. Completion status reports correctly when the learner finishes.
49. Pass and fail status reports correctly, using the right score.
50. The score sent to the LMS matches the score the learner saw.
51. Bookmarking survives closing the browser and relaunching later.
52. A learner who fails and retakes the course gets the right final status.
53. Time tracking looks reasonable in LMS reports.
54. The course title and description display correctly in the LMS catalog.

Devices and Browsers (55 to 60)

Ask IT or the LMS team which browsers and devices learners actually use, and test those, including the oldest one still in service.

55. The course works in every browser your learners actually use.
56. It works on the tablets and phones learners will use, if mobile is in scope.
57. Screens rotate and scale properly on mobile devices.
58. Touch targets are large enough to tap accurately.
59. The course loads in a reasonable time on a typical connection, not just office Wi-Fi.
60. Pop-up blockers and company network settings don't stop the course from launching.

How Should You Log and Prioritize Bugs?

Log bugs in a single shared tracker and rate each one by severity, so the team corrects launch blockers first and cosmetic issues last. A spreadsheet works fine, because what matters is that every issue lives in one place with a clear status.

Critical and high issues must be corrected and retested before launch, and medium issues usually should be. Low issues can go into a list for the next update if time is tight, as long as the decision-maker agrees in writing.

What Does a Useful Bug Report Look Like?

A useful bug report lets the developer find and fix the problem without asking a single question. Compare these two:

• Weak: "Quiz is broken."
• Useful: "M3-S04, Chrome on Windows laptop. Selected the correct answer (option B) and clicked Submit. Feedback said 'Incorrect.' Expected 'Correct.' Screenshot attached. Severity: High."

The second one takes thirty extra seconds to write and saves a round of back-and-forth. Multiply that by fifty bugs and you've saved a day. Give testers a simple template with fields for screen ID, steps, expected result, actual result, device, browser and severity, and they'll write useful reports without thinking about it.

Which Checks Do Teams Skip Most Often?

Teams most often skip the checks that take setup: resume and bookmarking, retake behavior, tracking in the real LMS and testing on actual mobile devices. They're tedious, so they get pushed to "if we have time," and there's never time.

These are also the checks behind the worst launch-week problems. A typo is embarrassing, but a course that doesn't record completion for hundreds of learners is a crisis, especially for compliance training with a deadline. If you can only protect a few hours of QA, spend them on items 14, 46 to 54 and 56.

Who Should Do QA, and When?

QA should happen in layers. The developer tests during the build, a dedicated tester runs the full checklist on the beta, and the subject matter expert (SME) confirms that content corrections are accurate. A small group of real learners can then try the course before full launch and identify what still confuses them.

The content checks are where SMEs matter most, and they're also where schedules slip if reviews aren't planned. Good habits for working with SMEs, such as booking their review time early and asking them focused questions, make the final QA round much faster. Don't save content QA for the end, either, because catching an error in the script costs minutes, while catching it after narration and build costs hours.

Run the eLearning QA Checklist Before Learners Run It for You

Every course gets tested; the only question is whether your team does it before launch or your learners do it afterward. This eLearning QA checklist gives you 60 specific checks across the seven areas where courses typically fail, from typos to tracking.

Copy it into your tracker, assign each section to a tester, and run it on the beta in the production LMS. After a couple of projects, add your own checks based on the bugs you've encountered, which is how a generic checklist becomes your team's quality standard.

← All articles