Self-use worksheets
Theme change and launch QA pack
Preserve behavior through a theme change, compare expected and observed results, and plan recovery across shared dependencies.
Illustrative data, separate blank downloads.
Examples are fictional. They are not client results, live tests, quotations or product claims. Use the blank CSV files for your own records.
How to use this pack
- Capture the exact current and candidate theme versions and approved change scope. Inventory behaviors, dependencies and content, not just filenames.
- Run acceptance cases on the approved candidate in a permitted test environment. Keep observed behavior, expected behavior and evidence separate.
- Reconcile late content and configuration edits before deciding to release. Mark unresolved mandatory cases held.
- Assign a release decision owner and recovery owners. Reverting a theme does not restore shared app settings, data or integrations.
Import CSV as UTF-8 with comma delimiters. The blank files contain headers and five empty editable rows. Add rows as needed. Preserve stable IDs. Keep secrets, passwords, payment details and personal customer data out of these sheets.
CSV files contain values only and no executable formulas or macros. Calculated example values are static. After changing inputs, recompute the calculated columns using the recipes shown below. Blank means unknown, while zero means a confirmed zero. Formula-like text and negative numbers are prefixed with an apostrophe for safer spreadsheet imports; remove the apostrophe only from verified numeric inputs when you calculate. Your own later edits are outside the generated-file safety checks.
Customization preservation register
Trace paid features from entry point to result.
- Walk with merchandising, support and operations. Link one feature to all code, setting, data and app dependencies.
- Record the transfer result separately from behavior acceptance. Existing code can still be unused or connected incorrectly.
Blank editable CSV: Customization preservation register (208 bytes)Illustrative completed CSV: Customization preservation register (598 bytes)
Field guide
- Feature ID
- Stable preservation ID.
- Business behavior
- Task that must continue to work.
- Baseline and candidate
- Exact versions or internal revisions.
- Dependency chain
- Input, storage, invocation and display.
- Transfer result
- Included, conflicted, not transferred or unknown.
- Observed candidate behavior
- Record only what was actually observed.
- Repair and acceptance owners
- Roles for repair and decision.
- Acceptance state
- Held until evidence confirms behavior.
Illustrative data
Fictional teaching example only. Replace it with your own verified records in the separate blank sheet.
| Feature ID | Business behavior | Baseline and candidate | Dependency chain | Transfer result | Observed candidate behavior | Repair and acceptance owners | Acceptance state |
|---|---|---|---|---|---|---|---|
| F-CARE | Correct care badge | Fictional theme v1 to v2 | Snippet, invocation and product care value | Assumed included | Illustrative: file present, badge absent | Developer / content owner | Held |
| F-ENGRAVE | Per-line engraving visible | Fictional candidate C2 | Input, line data, drawer and full cart | Assumed included | Illustrative: full cart hides engraving | Developer / store owner | Held |
Promotion, cart and account acceptance
Test critical customer and editor paths under their actual conditions.
- Write preconditions and exact steps before observing. Include desktop, narrow screen, keyboard and failure states.
- Promotion, cart and account rows are separate because they depend on different systems. Never enter real customer records or credentials.
Blank editable CSV: Promotion, cart and account acceptance (168 bytes)Illustrative completed CSV: Promotion, cart and account acceptance (896 bytes)
Field guide
- Case ID
- Link to a requirement or feature.
- Area
- Promotion, cart, account or editor.
- Candidate and preconditions
- Version, market, device and synthetic inputs.
- Steps
- Repeatable action sequence.
- Expected result
- Specific observable accepted behavior.
- Observed result
- Empty until run, or explicitly illustrative.
- Evidence reference
- Permissioned recording or redacted log.
- Reviewer
- Role authorized to accept.
- Result
- Not run, failed, passed or blocked.
Illustrative data
Fictional teaching example only. Replace it with your own verified records in the separate blank sheet.
| Case ID | Area | Candidate and preconditions | Steps | Expected result | Observed result | Evidence reference | Reviewer | Result |
|---|---|---|---|---|---|---|---|---|
| QA-PROMO-01 | Promotion | Fictional draft, US market, 390px | Open campaign; follow offer link; check expiry | Approved current offer and valid destination | Illustrative: earlier banner revision | Fictional E-P1 | Content owner | Failed in example |
| QA-CART-01 | Cart | Synthetic engraving lines A and B | Add both lines; change quantity; reload drawer/full cart | Each line keeps and shows its own value | Illustrative: full cart hides values | Fictional E-C1 | Store owner | Failed in example |
| QA-ACCOUNT-01 | Account | Permitted synthetic buyer, signed out and signed in | Follow account link; sign in; open permitted record | Correct account route with no other buyer data | Illustrative: not run | No evidence | Operations owner | Not run |
Late content and configuration changes
Keep candidate edits aligned with the approved source.
- Record edits made after the baseline snapshot. Identify whether the value is theme-local, shared template, resource data or app configuration.
- Retest the changed campaign and a deliberately unchanged page when a source is shared.
Blank editable CSV: Late content and configuration changes (227 bytes)Illustrative completed CSV: Late content and configuration changes (422 bytes)
Field guide
- Change ID
- Stable delta record.
- Captured UTC
- Timestamp including timezone.
- Record and source scope
- Exact non-sensitive object or revision.
- Baseline value or revision
- Original snapshot reference.
- Approved intended revision
- Authority for the change.
- Candidate revision
- Actual observed value.
- Other consumers to retest
- Shared pages or systems.
- Reconciliation owner
- Role approving the data delta.
- State
- Pending, reconciled or held.
Illustrative data
Fictional teaching example only. Replace it with your own verified records in the separate blank sheet.
| Change ID | Captured UTC | Record and source scope | Baseline value or revision | Approved intended revision | Candidate revision | Other consumers to retest | Reconciliation owner | State |
|---|---|---|---|---|---|---|---|---|
| D-01 | 2026-10-31T12:00:00Z | Campaign banner, theme setting | Fictional copy revision 4 | Fictional approved revision 5 | Fictional revision 4 | Gift campaign and support page | Content owner | Held: stale candidate |
Release and recovery ownership
Set explicit hold conditions and reversibility boundaries.
- Record exact candidate, baseline snapshot and evidence location without passwords or private keys.
- Define a measurable trigger, decision owner and restoration verification for each recovery boundary. A named owner is not evidence recovery has been rehearsed.
Blank editable CSV: Release and recovery ownership (241 bytes)Illustrative completed CSV: Release and recovery ownership (777 bytes)
Field guide
- Recovery boundary
- Theme, shared data, app, integration or content.
- Candidate and baseline refs
- Exact version/snapshot identifiers.
- Release hold condition
- What prevents release.
- Recovery trigger
- Specific observed failure.
- Decision owner
- Who may release or revert.
- Recovery action
- Scoped restoration including later-change guard.
- Recovery operator
- Who can perform the action.
- Restoration acceptance
- Behavior and data checks after restore.
- Rehearsal evidence and state
- Do not imply a drill occurred.
Illustrative data
Fictional teaching example only. Replace it with your own verified records in the separate blank sheet.
| Recovery boundary | Candidate and baseline refs | Release hold condition | Recovery trigger | Decision owner | Recovery action | Recovery operator | Restoration acceptance | Rehearsal evidence and state |
|---|---|---|---|---|---|---|---|---|
| Theme files | Fictional C2 / B1 | Mandatory cart case unresolved | Accepted cart behavior fails after release | Store owner | Restore B1 only after checking later changes | Developer | Repeat cart and campaign cases | Fictional plan; not rehearsed |
| Shared content and apps | Fictional snapshot S1 | Missing data rollback owner | Shared setting differs from approved baseline | Operations owner | Restore authorized values from S1; reconcile later edits | Content/app owner | Compare data consumers and downstream side effects | Fictional plan; not rehearsed |
Assumptions
- All feature IDs, observations and evidence references are fictional planning examples. No theme was updated or order placed.
- Tests that create orders, send notifications or change shared data require the store owner's applicable authorization and synthetic data.
Known limits
- A checklist row is not a completed test. Only record pass after a reviewer inspects the exact candidate evidence.
- Recovery must cover shared data and side effects as well as theme files. Do not run a live release from this worksheet alone.
Source and method notes
- Approved growth program DESIGN: pack 2.
- Draft guides SC02 and SC21 inform preservation, shared-template isolation, candidate deltas and retirement.