REAL-LIFE LEARNINGS · 24 October 2026
SiteTick: building & QA
Use isolated synthetic tests and prove what the user actually receives.
LESSON 1
Protect the test boundary
A useful QA run must never disturb production or another tester’s work.
What worked
Checking the project, company and fixture IDs before a reset keeps tests repeatable and bounded.
What to avoid
A familiar URL or a company name is not sufficient proof of the target.
Next time
- Verify the exact QA project and synthetic company.
- Record fixture IDs and the starting state.
- Run only the agreed repeatable reset.
- Preserve other testers’ data and production; retain evidence.
Evidence & status: Practice established; every new reset still needs target verification.
Back to folder contents ↑LESSON 2
An export is more than a green button
A payroll export can look correct while the downloaded file or provider interpretation is wrong.
What worked
Inspecting real CSV bytes, columns, totals and file hash gives stronger evidence than screenshots alone.
What to avoid
Do not claim a browser download happened merely because a generated response exists.
Next time
- Record the test fixture and expected totals.
- Generate and inspect the actual CSV.
- Check paid breaks, voids, empty values and provider mapping.
- Record generated, downloaded and imported evidence separately.
Evidence & status: Export evidence lessons captured. Reproduced provider defects are not described as fixed.
Back to folder contents ↑LESSON 3
Test the whole worker week
Single happy-path shifts miss gaps across days, offline work and corrections.
What worked
A worker-week scenario exposes reconciliation and workflow gaps across multiple states.
What to avoid
Passing one online shift does not prove offline recovery or all payroll scenarios.
Next time
- Build a synthetic week with normal shifts, breaks and corrections.
- Include offline interruption and later recovery.
- Reconcile screen totals with the exported result.
- Record failed, not run and blocked cases rather than rounding them up to a pass.
Evidence & status: Coverage gaps remain explicit; this guide is not a release sign-off.
Back to folder contents ↑LESSON 4
Know exactly what was released
A fix, branch, saved version and live site can all refer to different code.
What worked
One active handover plus an exact commit and target prevents competing versions of the truth.
What to avoid
Do not call a local implementation deployed or a deployment verified without the matching evidence.
Next time
- Identify the source repository, commit and intended target.
- Check the required tests for that exact candidate.
- Record implemented, deployed and verified separately.
- Stop for a missing source or failed release gate instead of publishing a substitute.
Evidence & status: Source-of-truth documentation improved; no new SiteTick release is implied here.
Back to folder contents ↑