Builder School — TESTING AND MORE TESTING

MODULE 01

Open book · Prepare before you test

Prepare the Product
for Real Testing.

You are not testing yet. First learn the four setup actions that make later testing more trustworthy: get the complete ZIP build, put it on a live host, open a real Chrome preview, and make a self-contained preview.

MODULE 01 · OPEN BOOK

Build the testing setup before you judge the product.

Good testing starts with the right target. If you test an old file, a partial build, a screenshot, or a preview with broken paths, you can waste time fixing the wrong problem. These four actions prepare one dependable product version for the testing work that comes next.

OPEN BOOKThe full study guide stays on this page while you answer. You are learning the process, not memorizing words.

01Complete ZIP Build

02Live Host

03Real Chrome Preview

04Self-Contained Preview

NEXTStart Testing

Request the Complete ZIP Build From the A.I.

A complete ZIP build is one packaged copy of the current product files the A.I. has built. It should contain the full version you are about to test—not one page, an old version, a code snippet, or only the last file that changed. The ZIP gives you one clear build to keep, move, host, and test.

Why you do it: Testing only means something when everybody is testing the same current product. A complete ZIP gives you a clean checkpoint. If a problem is found, you know exactly which build showed the problem.

Testing prep: For a real product, the complete ZIP creates the exact package later tests should use as their starting point.

Open-book answer:A complete ZIP build is the full current product package with all current files. It gives testing one exact newest checkpoint so everyone tests the same build and not an old version.

Put the Build on a Live Host

A live host puts the build on a real web address so the product runs through a real browser environment instead of only sitting as files on your computer. It can be a staging or test address; it does not have to be the final public launch.

Why you do it: Some problems only appear when the product is actually online. Links, routes, images, files, loading, browser permissions, and other behavior can work one way locally and another way on a host.

Testing prep: For a real product, the live host gives the build a real environment so testing can include hosted behavior.

Open-book answer:A live host puts the current build online on a real web address and server environment. This matters because testing online can reveal route, link, image, loading, or hosting problems that local files may not show.

Request a Real Live Chrome Preview

A real live Chrome preview is the working product opened in Chrome so you can actually use it. It is not a screenshot, mockup, or picture of the page. You should be able to scroll, click buttons, open menus, type in fields, move between sections, and see how the product truly behaves.

Why you do it: A screenshot can look perfect while the real product is broken. Testing needs an interactive page because many failures only show up when someone actually uses the controls.

Testing prep: A real Chrome preview gives you an interactive browser view where visual and functional testing can happen on the actual experience.

Open-book answer:A real live Chrome preview opens the working product in Chrome so I can click buttons, scroll, type in fields, open menus, and interact with it. A screenshot or static picture cannot prove those controls work.

Make the Preview Self-Contained

A self-contained preview keeps the preview's images, video, styles, and scripts inside the preview file itself instead of depending on separate local file paths. That makes the preview portable and prevents missing-path problems from making a good product look blank or broken during inspection.

Why you do it: When preview assets depend on paths that Chrome cannot reach, you can mistake a preview problem for a product problem. Embedding the preview assets removes that uncertainty and makes the inspection copy more reliable.

Testing prep: A self-contained preview creates a dependable inspection copy without replacing the live hosted build. The live hosted build still matters. A self-contained preview should help you inspect the product; it should not hide real problems that happen on the live host.

Open-book answer:A self-contained preview keeps images, video, styles, scripts, and other assets embedded inside one preview file. That removes missing local path dependencies and makes the inspection copy more portable and reliable.

Why all four?The ZIP gives you the exact build. The live host gives it a real environment. The Chrome preview lets you use it. The self-contained preview removes preview-path uncertainty. Together they prepare you to test the product instead of guessing at it.

Common beginner mistakes

Testing an old ZIP after a newer build exists.
Calling a screenshot a live preview.
Testing only local files and assuming the hosted version behaves the same.
Using a preview with missing images or video paths and blaming the product before checking the preview setup.
Using a self-contained preview as a reason to ignore a real problem that still happens on the live host.

Your understanding checkTesting Preparation — Open Book

Saved

Carried forward from Course 3Your Product State Is Still With You

Automatic · Nothing to re-enter

Checking Course 3 completion.

Complete Course 3 forwarding state

Complete Course 3 first.

Open bookExplain the four preparation actions

Use the study guide

Open-book understanding checkUse the matching open-book answer from the study guide in each answer box. Then click Check My Understanding once.

1. What is the complete ZIP build, and why do you request it before testing?Explain what goes in the complete build and why the exact current version matters. 2. What does putting the build on a live host do, and why does it matter before testing?Explain what a live host gives you that files sitting on your computer do not. 3. What is a real live Chrome preview, and why is it better for testing than a screenshot?Explain what you can actually do in the preview. 4. What is a self-contained preview, and why do you make one before testing?Explain what gets embedded and what kind of preview problem this helps remove.

Check your understandingTesting Preparation Check

One final check

Course 4 · Module 1

Use the study guide to complete the questions, then check your understanding.

Complete ZIP: Waiting for your answer.
Live host: Waiting for your answer.
Chrome preview: Waiting for your answer.
Self-contained: Waiting for your answer.

Use the four open-book answers from the study guide, then press Check My Understanding once.

MODULE 02

Open book · Learn how trustworthy testing works

Learn the Testing
Discipline.

Module 1 prepared the testing environment. Now learn the seven habits that keep testing controlled, explainable, and useful before you apply them to your own product.

MODULE 02 · OPEN BOOK

Learn the testing habits before you test your product.

A good testing setup is only the beginning. The next danger is testing without discipline: changing several things at once, fixing symptoms instead of causes, forgetting what changed, or assuming a repair worked because one screen looks better. These seven actions teach you how to test in a way you can trust.

OPEN BOOKThe seven study cards stay visible while you answer. You are learning a repeatable testing method, not memorizing definitions.

01Visual Rendering

02Functionality

03One Problem

04Root Cause

05Change Log

06Learn From Mistakes

07Retest

Check the Visual Rendering

Visual rendering means checking what the product actually looks like when the browser draws it on the screen. Look for missing images, unreadable text, overlapping sections, cut-off buttons, broken spacing, wrong sizes, blank areas, and layouts that fall apart on different screen widths.

Why you do it: A feature can technically exist and still be unusable because the user cannot see or reach it correctly. Visual testing catches presentation failures before they get mistaken for functional failures.

Testing prep: Learn to judge what the user can actually see before judging what the controls do.

Open-book answer:Checking visual rendering means looking at what the browser actually shows for missing images, unreadable text, overlapping sections, cut-off buttons, broken spacing, wrong sizes, blank areas, and layouts that break at different widths. Do it because a feature can exist and still be unusable if the user cannot see or reach it correctly.

Test the Functionality

Functionality testing means using the product the way a real user would. Click buttons, follow navigation, submit forms, type into fields, open menus, scroll, move between steps, and confirm that each action produces the approved result.

Why you do it: A page can look perfect while its buttons, forms, links, saves, or workflows are broken. Testing the actual actions proves the product works, not just that it looks finished.

Testing prep: Learn to test behavior separately from appearance so you know what kind of failure you found.

Open-book answer:Testing functionality means using the product like a real user by clicking buttons, following navigation, submitting forms, typing in fields, opening menus, scrolling, and moving through steps. Do it because a page can look right while its buttons, forms, links, saves, or workflows are broken.

Fix One Problem at a Time

One problem at a time means keeping each repair focused. Confirm one failure, repair that failure class, and verify it before mixing in unrelated redesigns or a pile of other changes.

Why you do it: If five things change at once and the product gets better—or worse—you may not know which change caused it. Focused repairs make cause and effect easier to understand and reduce accidental breakage.

Testing prep: Learn to keep repairs controlled so every change can be explained and checked.

Open-book answer:Fix one problem at a time so each repair stays focused and you can tell which change caused the result. Changing several unrelated things at once makes cause and effect harder to understand and can create new problems.

Find the Root Cause

The root cause is the real reason a failure keeps happening. A symptom is only what you can see. For example, unreadable text is the symptom; an inherited text color that conflicts with the background may be the root cause.

Why you do it: Surface patches can hide a symptom in one place while the same underlying defect breaks somewhere else. Fixing the root cause removes the failure at the level where it begins.

Testing prep: Learn to ask “Why did this happen?” before deciding what should change.

Open-book answer:A root cause is the real reason a failure happened; a symptom is only what you can see. Find and fix the root cause because a surface patch may hide one symptom while the same underlying problem keeps breaking other places.

Keep a Running Change Log

A running change log is a simple record of what failed, what was changed, why it was changed, and what happened when the repair was retested. It follows the build as testing continues.

Why you do it: Without a record, you can repeat failed repairs, forget what changed, or lose track of which build contains which fix. The log gives you a history you can inspect instead of relying on memory.

Testing prep: Learn to leave a trail of decisions so later testing can explain how the product reached its current state.

Open-book answer:A running change log records what failed, what changed, why it changed, and what happened when the repair was retested. Keep it so you can track the build, avoid repeating failed repairs, and know which version contains each fix.

Teach the Project From Its Mistakes

Teach the project from its mistakes means turning confirmed failures into knowledge that protects the build later. Record the lesson, add a check or regression rule when useful, and carry the important learning forward so the same mistake is easier to catch or avoid next time.

Why you do it: A repaired bug is useful once. A lesson learned from that bug can protect every later version. The project becomes more dependable because previous failures improve the way it is tested and built.

Testing prep: Learn to make past failures strengthen future testing instead of letting the same defect return unnoticed.

Open-book answer:Teaching the project from its mistakes means turning confirmed failures into useful knowledge, checks, or regression rules that protect later builds. This helps the same mistake get caught or avoided next time.

Retest Every Fix

Retesting means checking the repaired failure again after the change, then checking important nearby and previously working behavior for regressions. A repair is not proven just because the code changed or the Fix Agent says it is fixed.

Why you do it: A fix can fail, work only in one condition, or break something that used to work. Retesting provides independent evidence that the original failure is gone and the repair did not create a new one.

Testing prep: Learn that every repair stays unproven until testing confirms it.

Open-book answer:Every fix must be retested to prove the original failure is gone and to check that nearby or previously working behavior did not break. A repair is not proven just because the code changed or someone says it is fixed.

How the seven actions work togetherSee the product clearly. Use it like a user. Isolate a confirmed problem. Find why it happened. Record the change. Turn the failure into a lesson. Then retest the repair and the surrounding product. That is controlled testing.

Common testing mistakes

Calling a visual problem fixed without checking the real browser page.
Testing only appearance and never clicking the product.
Changing several unrelated things in one repair.
Covering a symptom instead of tracing what caused it.
Relying on memory instead of keeping a change record.
Fixing a bug but learning nothing from why it happened.
Trusting a repair without independently retesting it and checking for regressions.

Your understanding checkTesting Discipline — Open Book

Saved

Carried forward from Module 1Your Complete Testing Preparation State Is Here

Automatic · Nothing to re-enter

Checking Module 1 completion.

Complete Module 1 forwarding state

Complete Module 1 first.

Open bookExplain the seven testing actions

Use the study guide

Open-book understanding checkUse the matching open-book answer from the study guide in each answer box. Then click Check My Understanding once.

1. What does checking the visual rendering mean, and why do it?Explain what you inspect on the screen and why appearance needs its own check. 2. What does testing the functionality mean, and why do it?Explain how you use the controls and why a good-looking page is not enough. 3. Why do you fix one problem at a time?Explain how focused repairs help you understand cause and effect. 4. What is a root cause, and why should you find it instead of patching the symptom?Explain the difference between what you see and why it happened. 5. What is a running change log, and why keep one?Explain what gets recorded and why testing needs that history. 6. What does it mean to teach the project from its mistakes?Explain how a confirmed failure becomes useful knowledge for later builds and tests. 7. Why must every fix be retested?Explain why the original failure and nearby working behavior both need to be checked again.

Check your understandingTesting Discipline Check

One final check

Course 4 · Module 2

Use the study guide to complete the questions, then check your understanding.

Visual: Waiting for your answer.
Function: Waiting for your answer.
One problem: Waiting for your answer.
Root cause: Waiting for your answer.
Change log: Waiting for your answer.
Learn: Waiting for your answer.
Retest: Waiting for your answer.

Use the seven open-book answers from the study guide, then press Check My Understanding once.

TESTING AND MORE TESTING

Prepare the Product
for Real Testing.

Build the testing setup before you judge the product.

Request the Complete ZIP Build From the A.I.

Put the Build on a Live Host

Request a Real Live Chrome Preview

Make the Preview Self-Contained

Need the testing setup explained more simply?

Use the study guide to complete the questions, then check your understanding.

Your product testing setup makes sense.

Learn the Testing
Discipline.

Learn the testing habits before you test your product.

Check the Visual Rendering

Test the Functionality

Fix One Problem at a Time

Find the Root Cause

Keep a Running Change Log

Teach the Project From Its Mistakes

Retest Every Fix

Need the testing discipline explained more simply?

Use the study guide to complete the questions, then check your understanding.

You understand the testing discipline.