Plan and track quality work

Course

Level 2 · Web Construction

Module

Quality, SEO, and analytics

Expected effort

180–300 minutes

Estimate assumptions: You have a completed Level 2 web application in a private GitHub repository and can use issues, Markdown, Git, and browser testing from Level 1. The estimate includes choosing a delivery target, creating a quality-plan file and private GitHub Project, defining fields and views, writing six quality issues, scheduling a delivery buffer, completing one planning checkpoint, Git and GitHub updates, the self-check, and re-entry after an interruption. Optional extension work is not included.

Outcome

You will create a private GitHub Project that turns six quality risks for one web application into ordered, testable issues. You will connect that board to an agreed delivery date, protect time for final verification, and complete one planning checkpoint without starting all six work items at once.

Why this matters

Quality assurance is easier to act on when the expected result, evidence, owner, status, and deadline are visible. A project board cannot prove that an application works. It can make the next quality check clear, expose blocked work early, and preserve the plan when work stops and resumes.

What you will practice

• Separate a delivery plan from the test evidence that later proves a result.
• Write quality issues with a risk, condition, action, expected result, evidence requirement, and done signal.
• Use stable project fields for status, priority, quality area, and target date.
• Create table and board views that answer different planning questions.
• Limit active work to one quality issue while preserving later work in a visible queue.
• Place a start window, feedback point, verification buffer, and hard deadline on one delivery schedule.
• Record a blocker and a precise resume action without treating either as failure.

What is new and what is reused

• New: Quality risk, delivery target, GitHub Projects, project item, custom field, project view, priority, work-in-progress limit, start window, verification buffer, and resume note.
• Reused: The private Level 2 repository, GitHub issues, Markdown, quality-assurance terms, test conditions, expected results, evidence, Blocked status, Git commits, and GitHub pushes.

Starting point

Before you start

• The completed interactive-web-application repository, or the animated-responsive-interface repository if that is your chosen quality target.
• A clean local working tree on main and the latest verified version pushed to its private GitHub repository.
• A GitHub account with permission to create issues and a private personal project.
• The agreed delivery deadline from your teacher, or a teacher-approved practice deadline.
• VS Code, Git, a browser, and internet access.

Current state

The application has completed features, but its quality risks are not ordered into testable work, no project view shows the current quality state, and the deadline has no protected verification buffer.

First action

Open the chosen application, run its current version once, and write its visible product name plus hard deadline in a new quality-plan.md file.

First checkpoint

quality-plan.md names one product, one delivery result, one hard deadline, and the first quality issue that will enter In progress.

Help trigger

Use the recovery note or ask for help if the product will not run, the deadline is missing, an issue cannot be tested independently, more than one item seems urgent, the GitHub interface lacks a named control, or a blocker has no clear owner or next question.

Required result

You have completed the lesson when:

• one existing private Level 2 repository is the named quality target;
• quality-plan.md records the delivery result, hard deadline, verification buffer, test environment, first checkpoint, help trigger, and done signal;
• one private GitHub Project is connected to the repository;
• the project has Status, Priority, Area, and Target date fields with the required values;
• a table view shows issue title, status, priority, area, target date, and repository;
• a board view groups the same issues by status;
• six repository issues cover baseline, function, keyboard and focus, responsive layout and zoom, source and Console checks, and final regression evidence;
• each issue states the risk, test condition, action, expected result, required evidence, and close condition;
• every issue has a priority, area, target date, and current status;
• only one issue has In progress status;
• blocked work records the missing condition and next action instead of using Done;
• the schedule contains a start window, first checkpoint, optional feedback point, quality-ready target, final review, and hard deadline;
• final review and delivery have time reserved after the quality-ready target;
• one baseline issue has evidence, a final comment, Done status, and a closed repository issue;
• the remaining queue identifies one next Ready issue; and
• the verified quality-plan.md commit is pushed to the private repository.

Keep planning and evidence separate

A project item describes intended work and its current planning state. A test result records what happened in a named condition. These are different records.

Record	Question it answers	It does not prove
Quality issue	What must be checked, why, and what evidence is required?	That the check passed
Project status	Is the item ready, active, blocked, or done?	That the application works
Test evidence	What condition, action, expected result, and actual result were recorded?	That unrelated paths also work
Closed issue	Why did this planned item reach its done signal?	Complete product quality

Do not move an item to Done because the plan exists. Done requires the issue’s named evidence.

Choose one quality target

Use your completed interactive-web-application repository by default. You can use animated-responsive-interface when that is the more complete product and your teacher agrees.

Do not combine both products on one required board. One product keeps the risks, evidence, and deadline unambiguous.

Before planning, run the current application once:

1. Open the repository root in VS Code.
2. Use the documented run method.
3. Perform its primary interaction once.
4. Record the browser, version, and operating system.
5. Run git status and confirm that the working tree is clean.
6. Open the private GitHub repository and confirm that the latest verified commit is present.

If the product does not run, stop quality planning and record the exact launch blocker. Restore a runnable baseline before estimating later checks.

Create the delivery contract

Add quality-plan.md at the repository root with this structure:

quality-plan.md — delivery contract

# Quality plan: Product name

## Delivery

- Required result: A testable sentence that names the application behavior.
- Hard deadline: YYYY-MM-DD at HH:MM.
- Quality-ready target: YYYY-MM-DD at HH:MM.
- Optional feedback point: YYYY-MM-DD at HH:MM.
- Final review window: YYYY-MM-DD from HH:MM to HH:MM.
- Test environment: Browser and version, operating system.

## First checkpoint

- Start window: YYYY-MM-DD from HH:MM to HH:MM.
- First active issue: #ISSUE-NUMBER — issue title.
- Checkpoint result: The baseline issue has evidence and is closed.
- Help trigger: The app does not run, the test condition is unavailable,
  or the first issue remains blocked after one focused investigation.

## Required quality areas

- Baseline and environment
- Core function and input handling
- Keyboard use and visible focus
- Responsive layout and 200% zoom
- HTML, CSS, and JavaScript Console
- Final regression and evidence review

## Done signal

All six issues meet their evidence requirements. No required item remains
Ready, In progress, or Blocked. The final tested commit is identified, and
the delivery package is ready before the hard deadline.

## Resume note

- What works:
- What remains:
- Next action:
- Required setup:

Replace every placeholder. The quality-ready target must occur before the hard deadline. The final review window uses the reserved interval between them.

The effort estimate at the top of this lesson supports planning. It is not your deadline and does not measure ability. Use the agreed delivery date and the real scope of your product.

Checkpoint: The delivery boundary is visible

What now works

quality-plan.md names one product and environment, separates the quality-ready target from the hard deadline, reserves a final review window, defines the first checkpoint and help trigger, and states one stable done signal.

Files changed

quality-plan.md

What remains

Create the private GitHub Project, configure its fields and views, and turn the six areas into repository issues.

Next action

Open GitHub Projects from your account and create a private project named after the product plus Quality.

If it does not work

If the schedule has no real buffer, reduce optional scope or ask to renegotiate the delivery plan. Do not hide missing time by placing every task on the hard deadline.

Create a private GitHub Project

GitHub Projects can show issues in table, board, and roadmap layouts. This lesson uses one table for complete planning data and one board for the active work queue.

1. Open Your projects from your GitHub account.
2. Create a new project from a blank table.
3. Name it Product name · Quality.
4. Open the project settings and keep its visibility Private.
5. Open the private repository’s Projects tab, select Link a project, and choose the new project.
6. Open the project settings and set the private repository as its default repository.
7. Add a short description: Quality plan and evidence queue for Product name.

The project and repository can have different visibility settings. Confirm the project itself is private before adding product details. Do not put grades, private school links, personal contact data, access tokens, or real user data in an item.

If a menu label differs, use the current GitHub Projects documentation and search for the action. Do not create a public project to make a missing control easier to find.

Configure four planning fields

Keep the field set small. Add or edit these fields:

Field	Type	Required values or format	Planning question
Status	Single select	Ready, In progress, Blocked, Done	What can happen next?
Priority	Single select	Must, Should, Could	What protects the required delivery first?
Area	Single select	Baseline, Function, Accessibility, Responsive, Source, Regression	Which quality boundary does this issue cover?
Target date	Date	Date before or on the quality-ready target	When must its evidence be ready?

Use Must for every issue needed by this lesson. Should and Could are available for later findings and optional improvements. Priority does not change because an item feels interesting or uncomfortable.

Blocked means the next required condition is unavailable. It is not a hidden form of In progress, and it does not judge the person doing the work.

Create two views

Configure these views from the same project items:

1. Rename the initial table view Quality plan.
2. Show Title, Status, Priority, Area, Target date, and Repository.
3. Sort by target date, then priority.
4. Create a second view named Work queue.
5. Set the second view to board layout and use Status for its columns.
6. Keep the columns in this order: Ready, In progress, Blocked, Done.

The table answers What is planned and when? The board answers What can I act on now? A third view is not required.

Write one testable quality issue

Create the first repository issue with this title:

QA: Confirm the stable starting state

Use this body pattern:

GitHub issue — quality work pattern

## Quality risk

Later results cannot be repeated if the starting commit, environment,
and launch path are unknown.

## Test condition and action

1. Start from the current main branch with a clean working tree.
2. Run the documented launch method.
3. Open the application in the named browser and operating system.
4. Perform the primary interaction once.

## Expected result

The application loads from the identified commit, the primary interaction
reaches its documented result, and the Console contains no startup error.

## Required evidence

- Full tested commit hash
- Browser and operating-system versions
- Launch command or file path
- Actual result of the primary interaction
- Console result

## Close condition

Add one final comment with every evidence item. Close this issue only when
the actual result matches the expected result or a separate defect issue
records the confirmed failure.

## If blocked

Record the missing condition, the last successful step, the exact next
question, and who can supply the missing access or information.

This issue is small enough to complete in one work interval, but it produces evidence needed by every later check.

Do not write Test the app as the complete issue. It omits the condition, observable result, and done signal.

Create the remaining quality queue

Create five more repository issues. Use the same headings and adapt the content to your application.

Issue title	Area	Required focus	Evidence example
QA: Verify the core interaction and input boundaries	Function	Primary path, empty or invalid input, repeated input, state result	Actual results for each named input path
QA: Verify keyboard use and visible focus	Accessibility	Tab order, activation, focus after state changes, status text	Ordered keyboard path and observed focus result
QA: Verify responsive layout and zoom	Responsive	About 320px, wide view, 200% zoom, long content	Viewport and zoom results with first failed element if any
QA: Check HTML, CSS, and the JavaScript Console	Source	Saved source, relevant validators, startup and interaction errors	Tool results with messages resolved or classified
QA: Run final regression and review evidence	Regression	All required paths on one identified commit	Final commit, pass or issue for each path, open limits

Every issue must name application-specific elements and behavior. Replace primary interaction with the real action, such as adding a task, filtering resources, or changing a completion state.

Do not solve defects while creating the queue. Record a new finding in the relevant issue or create a separate defect issue. Return to the active planning checkpoint.

Add and order the six issues

Add all six repository issues to the project. In the Quality plan table:

• set every required issue to Priority: Must;
• set the area shown in the issue table;
• give every issue a target date no later than the quality-ready target;
• set the baseline issue to In progress;
• set the other five issues to Ready; and
• confirm that no second issue is In progress.

Target dates should show a workable sequence. Do not assign all six to the hard deadline. Put the final regression issue on the quality-ready target and reserve the later interval for review, packaging, or a focused repair.

Treat the delivery section in quality-plan.md as the source of truth for the quality-ready target, review window, and hard deadline. Use project target dates only for individual issues. Do not create second hard-deadline fields that can drift from the delivery contract.

Checkpoint: The queue supports one next action

What now works

The private project contains six application-specific repository issues; the table exposes required fields and dates; the board has one In progress baseline issue and five Ready issues.

Files changed

quality-plan.md, six GitHub repository issues, one private GitHub Project

What remains

Make the deadline structure explicit, complete the baseline evidence, and preserve a precise resume point.

Next action

Compare each target date with the quality-ready target and hard deadline, then complete the active baseline issue.

If it does not work

If several issues seem equally urgent, keep final regression last, keep baseline first, and choose the earliest check whose evidence another issue depends on. Record the rest as Ready.

Make the deadline usable

A finish deadline does not tell you when to start or when testing must stop. Add these points to the delivery section in quality-plan.md and to the relevant issue target dates:

Planning point	Purpose
Start window	Opens the project and reaches the first evidence checkpoint
First checkpoint	Produces the stable baseline needed by later work
Optional feedback point	Leaves time to act on teacher or peer feedback
Quality-ready target	Ends required testing and identifies the delivery candidate
Final review window	Protects time for evidence review, packaging, and a focused repair
Hard deadline	Ends delivery work at the agreed time

Use exact dates and times. Later today, this week, and before class are not precise enough for a delivery plan.

The optional feedback point must accept incomplete work and occur early enough to change the result. It is not proof that you started, and skipping it does not add a hidden penalty unless your teacher’s assignment states otherwise.

Protect one active checkpoint

Use a work-in-progress limit of one for the required lesson:

1. Move one Ready issue to In progress.
2. Work only on its named condition and evidence.
3. Record a new idea in its issue or a later issue without switching work.
4. Move the active issue to Done only when its close condition is met.
5. Choose the next Ready item after the current item closes or becomes explicitly Blocked.

This limit reduces avoidable switching. It does not stop you from recording new information.

Choose support; do not add surveillance

You can choose a checkpoint-based session, a scheduled work interval, or a flow-protective check-in. You can also choose to hide unrelated notifications or keep an after-checkpoint list. None of these supports is required. Do not share browser history, screen recordings, activity reports, or personal routines as proof of work.

If an essential need or overload requires a stop, preserve the current state and stop. A plan must support safe re-entry; it must not compete with food, water, medication routines, movement, sensory regulation, or rest.

Complete the baseline issue

Return to QA: Confirm the stable starting state and perform only its named steps.

Add a final evidence comment with this structure:

Baseline issue — final evidence comment

## Actual result

- Tested commit: FULL-COMMIT-HASH
- Browser and version:
- Operating system:
- Launch method:
- Primary interaction:
- Actual visible result:
- Console result:

## Decision

Pass: The actual result matches the expected starting state.

## Next quality issue

#ISSUE-NUMBER — QA: Verify the core interaction and input boundaries

Use git rev-parse HEAD to obtain the tested commit hash. Record the full output, not only the short hash shown in a compact log.

If the actual result fails:

1. record the exact failure and reproduction step;
2. create or link a focused defect issue;
3. move the baseline item to Blocked when the failure prevents the later tests;
4. record who or what can supply the next missing condition; and
5. keep the baseline issue open.

Do not change Blocked to Done to make the board look complete.

When the baseline passes, close the repository issue and move its project item to Done. Move QA: Verify the core interaction and input boundaries to In progress. The board must still contain only one active item.

Write a resume note before stopping

Update the resume section in quality-plan.md every time you stop before the complete queue is done:

quality-plan.md — example resume note

## Resume note

- What works: Baseline issue #12 is closed with commit and environment evidence.
- What remains: Five required quality issues remain; #13 is In progress.
- Next action: Open #13 and run its empty-input path before changing source.
- Required setup: Start the app with npm run dev and open the documented local URL.

The note records project state, not a judgment about the work session. If time went to an unrelated activity, restore the board, read the current issue, and perform its next action. No explanation or penalty ritual is required.

Verify the planning system

Use this final matrix:

Check	Expected result
Product boundary	One private repository and one delivery result
Delivery boundary	Quality-ready target and review window occur before the hard deadline
Issue coverage	Six required quality areas have repository issues
Issue quality	Every issue has risk, condition, action, expectation, evidence, and close condition
Table view	Required fields and dates are visible and sortable
Board view	Status columns are ordered and only one item is In progress
Baseline evidence	Full commit, environment, launch, interaction, and Console result are recorded
Blocked path	Missing condition and next action remain visible; issue stays open
Resume path	Note identifies what works, what remains, next action, and setup
Privacy	Project is private and contains no secret, grade, private link, or real user data
Repository	quality-plan.md is committed and pushed

Self-check

Complete these checks against the required result.

1. Explain why a Ready or Done project status is not test evidence.
2. Confirm that quality-plan.md names one product, test environment, quality-ready target, review window, and hard deadline.
3. Confirm that the private project has Status, Priority, Area, and Target date fields with the required values.
4. Open Quality plan and confirm that all six issues show their area, priority, status, target date, and repository.
5. Open Work queue and confirm that only one item is In progress.
6. Inspect every issue and confirm that its expected result and evidence can be observed in a named condition.
7. Confirm that target dates form a sequence and do not place all work on the hard deadline.
8. Compare the baseline issue comment with its close condition and confirm that each evidence item is present.
9. Describe what the board must show when a missing condition prevents a required test.
10. Read the resume note and confirm that its next action can be performed without reconstructing the session from memory.
11. Confirm that the project and repository are private and contain no private operational or personal data.
12. Run git status and confirm that the quality-plan commit is pushed and the working tree is clean.

Common planning failures

Symptom	Likely cause	Focused check
Board has many active items	Starting work is being used as a substitute for choosing order	Keep one item In progress and return the rest to Ready
Issue says only “test accessibility”	Scope and evidence are not executable	Name input method, elements, action, and observable result
Every target date equals the deadline	No verification or delivery buffer exists	Place final regression at quality-ready and reserve later review time
Done issue has no actual result	Status changed before evidence existed	Reopen the issue and complete its close condition
Blocked issue disappears	Blocked work was closed or moved to Ready without a new condition	Restore Blocked and record the missing input and next question
Planning continues without testing	The board is becoming the product	Stop after six issues and begin the active baseline checkpoint
New finding causes a task switch	No capture route exists	Add the finding to the relevant issue, then return to the active step
Resume takes a long time	The note names a topic instead of an action	Add the file, command, test path, and first executable action
Project exposes private information	Visibility or item content was not reviewed	Make the project private and remove data that is not required for QA

The smallest useful planning system has a clear outcome, one next action, one help route, and enough evidence to decide when work is done.

Optional quality-planning investigations

The required lesson is complete before these investigations. Do not add fields or automations only to make the project look more complex.

Add a defects view

Create a filtered view that shows open defect issues discovered during testing. Define the label or issue field that identifies a confirmed defect and keep planning status separate from defect severity.

Add one project automation

Research GitHub Projects built-in workflows. Add one automation that removes a repeated manual step, such as setting a newly added item to Ready. Test one issue entering and leaving the workflow before keeping it.

Model issue dependencies

Use GitHub issue dependencies or sub-issues to show why final regression waits for earlier checks. Keep the six required issues readable without opening a deep hierarchy.

Compare a roadmap view

Create a temporary roadmap from target dates. Compare what it reveals with the table and board, then keep it only if the short project needs a time-based overview.

Optional reference

• Planning and tracking with GitHub Projects introduces project items, fields, views, workflows, and project settings.
• Managing items in a project explains how issues, pull requests, and draft issues enter and change within a project.
• Customizing project views explains table, board, roadmap, filtering, sorting, and grouping options.
• Planning and tracking work with issues explains how repositories, issues, and projects work together.

Record the quality-planning checkpoint

After the required self-check passes, record the plan file in the chosen private product repository:

Commit and push the quality plan

git status
git diff -- quality-plan.md
git add quality-plan.md
git diff --staged
git commit -m "Add application quality plan"
git push
git status

Confirm that GitHub shows the quality-plan commit and that the local working tree is clean. The project board and issues remain GitHub records outside that commit.

Next step or safe stopping point

The required lesson is complete when one private board turns the six required quality risks into testable, dated issues; the schedule protects final verification; the baseline issue has evidence; and exactly one next issue is active.

Continue to Test an interactive web application to execute the planned function, input, keyboard, state, and regression paths.

If you stop here, leave yourself this resume note: The quality plan has one active issue and a protected verification buffer. Next, open the active issue and run its first named condition before changing source.