Booking module testing: screenshot capture checklist
Open the formatted screenshot checklist.
Use with the complete end-to-end testing tutorial. Revision: 4 November 2026.
Screenshots are not required to complete the written test specification. They will make the illustrated tutorial easier to follow. Capture the core states below using a deployed staging build whose version is recorded. If a required screen is missing, report the missing state instead of fabricating an example.
Capture settings
- Use fictional records matching the guide: MyClinic QA, Dr Alex QA, Alex QA, Sam QA, Consultation QA and the stated financial fixtures.
- Prefer desktop captures at roughly 1440px width, normal browser zoom, with the relevant panel fully visible. Use a 360–430px-wide viewport for mobile examples.
- Save JPEG at quality 80–85 where text remains crisp, preferably no more than 1800px wide. Use PNG if JPEG makes dense labels unreadable.
- Use one focused state per image. If a page is long, capture separate numbered panels; do not shrink an entire page until its text is unreadable. Stitch only adjacent portions of the same unchanged screen when necessary.
- Crop unrelated browser chrome. Preserve the navigation needed to find the page, field labels, selected dates, status and expected amounts.
- Mask phone/email details, sender identifiers, access tokens, receipt/recall/proposal tokens, secrets and unrelated notifications. Do not expose tokens in the address bar or QR codes that grant real access.
- Keep treatment and payment fixtures separate: pricing adjustment is ₹53,000, while the payment ledger is ₹50,000. Capture each image with the appropriate fixture.
- For handset evidence, show the workflow message, clinic-local timestamp and whether it is the patient or provider test phone. A settings screenshot cannot prove receipt.
- Supply a short manifest: filename, deployed commit/version, capture date/time with timezone, case ID, screen state and any masking performed. Keep full unmasked evidence in the authorized test system only.
Core tutorial images
Capture these first. The filenames indicate where the future article assets should be placed; the article does not reference nonexistent images today.
| ID / filename | Open this page and prepare this exact state | What must be visible | Place beside / case IDs |
|---|---|---|---|
S01 01-booking-navigation.jpg |
Booking module on Calendar, then Settings open if needed as a second image | Main navigation and settings subpages; clinic name; no real patients | Tutorial section 3; ENV-001 |
S02 02-first-appointment-setup.jpg |
Empty test module with setup fields completed, before submission | Location/timezone, provider, service, duration/price, working hours and confirmation | ENV-004 |
S03 03-booking-profile.jpg |
Settings → Booking Profile after save | Practice name, currency and patient-number prefix; mask emails | CFG-001/002 |
S04 04-service-type-form.jpg |
Settings → Services → Service types → Consultation QA editor | Category, duration, effective price and any buffer controls | CAT-001/002/003 |
S05 05-provider-assignments.jpg |
Service providers → Dr Alex QA editor/setup | Explicit selected services, branch/location, hours mode and confirmation | CAT-005/006 |
S06 06-working-hours.jpg |
Working Hours with split morning/afternoon periods | Provider/location context, weekday and 09:00–13:00 / 14:00–17:00 periods | HRS-002 |
S07 07-date-exception-and-block.jpg |
Working Hours → Specific Dates on a QA date | Exception/leave/block scope and date; no unrelated bookings | HRS-005/006 |
S08 08-booking-policies.jpg |
Policies & Rules, save completed | All six policies with units; use another image for customer cancellation policy if below fold | POL-001/006/007 |
S09 09-walk-in-registration.jpg |
Walk-ins with branch selected and fictional registration form | Name, DOB, mobile, source/branch context and registration action | PAT-001 |
S10 10-patient-search-and-family.jpg |
Patient lookup with two QA family members sharing a masked number | Distinct patient numbers/names/DOB and explicit selection | PAT-005/006 |
S11 11-patient-details.jpg |
Patient Management → Alex QA | Patient identity, Schedule appointment and grouped visit history | PAT-009/010 |
S12 12-guardian-relationships.jpg |
Sam QA patient details with two verified guardians | Relationship, primary contact indicator, add/revoke behavior; mask contact data | GUA-002/003 |
S13 13-public-slot-selection.jpg |
Signed-out QA public portal, date and doctor selected | Clinic/location identity, date/calendar, real available slots and selected time | BKG-002/006 |
S14 14-booking-review.jpg |
Final review before confirmation | Patient identity, service, doctor, location, date/time, price and explicit confirm action | BKG-001/003/008 |
S15 15-booking-ticket.jpg |
Successful QA booking ticket | Reference, selected patient/doctor/date/time and supported change/cancel actions | BKG-002; CAN-001; RSC-002 |
S16 16-appointments-filtered.jpg |
Appointments list filtered by date and doctor | Patient name/contact, status, filters and result; mask numbers | APT-002 |
S17 17-doctor-workspace.jpg |
Doctor Workspace with Dr Alex QA and an appointment day | Selected doctor/day, date counts, status/follow-up filters and open-consultation action | APT-004/005 |
S18 18-consultation-clinical-entry.jpg |
Appointment → Consultation & Clinical Records | Patient/appointment identity, clinical fields, allergy review and Save clinical entry | CLN-001/002 |
S19 19-clinical-history-saved.jpg |
Patient clinical history after saving | Attributed entry, appointment reference/time and latest explicit allergy summary | CLN-004/005 |
S20 20-treatment-type-form.jpg |
Settings → Services → Treatment types with fixed/range estimate editor | Name, estimate mode, amount(s), currency and scope/details | TRT-001 |
S21 21-patient-treatment-pricing.jpg |
Add treatment from catalogue with ₹50,000 + ₹5,000 − ₹2,000 | Selected type details, base/addition/discount, reason and ₹53,000 total | TRT-004/005 |
S22 22-treatment-pricing-history.jpg |
Linked treatment after a reasoned price revision | Saved agreement, course status and expanded Pricing history | TRT-006 |
S23 23-linked-follow-up-treatment.jpg |
Compatible follow-up linked to an ongoing course | Explicit link/course identity and shared cost/paid/balance | TRT-011; PAY-008 |
S24 24-payment-plan.jpg |
Payment tracker on the separate ₹50,000 fixture | Agreed cost, 3-instalment plan, currency and bill-send option | PAY-002 |
S25 25-record-payment.jpg |
First ₹10,000 UPI payment form, before save | Amount, method, reference QA-P1, label and receipt toggle | PAY-003 |
S26 26-payment-ledger.jpg |
Ledger after all three guide payments | ₹50,000 paid, zero balance, three distinct receipt rows | PAY-004 |
S27 27-printable-receipt.jpg |
First payment receipt / print preview | ₹10,000 amount, historical ₹40,000 balance, method/reference and clinic | PAY-010 |
S28 28-patient-billing-summary.jpg |
Patient Payments & Billing after shared-course follow-up | Aggregate totals, account/plan selector and ledger without double counting | PAY-011 |
S29 29-reschedule-proposal.jpg |
Reschedule flow with proposed exact slots | Original appointment, target choices, proposal/send action | RSC-003 |
S30 30-patient-proposal-response.jpg |
Patient proposal page before acceptance | Original versus proposed time and explicit accept/decline | RSC-004/005 |
S31 31-cancellation-confirmation.jpg |
Staff cancellation confirmation before final action | Correct booking identity, reason and consequence/notification wording | CAN-002/003 |
S32 32-notification-log-reminder.jpg |
Communications → Logs, reminder detail expanded | Appointment identity, scheduled time, message body, parameters, recipient role and status | COM-004/005 |
S33 33-recall-campaign-selection.jpg |
Reviews & Recalls campaign creation with fictional cohort | Eligibility filters, selected recipients, date/title and create/dispatch distinction | REV-003/004 |
S34 34-recall-history-and-booking.jpg |
Campaign details after invitation response/booking | Per-recipient state and reconciled total/confirmed/declined/booked counts | REV-006/009 |
S35 35-patient-provider-message-evidence.jpg |
Side-by-side masked test handset screenshots, or separate 35a/35b |
Same appointment confirmation received by patient and provider; role-labelled | COM-003 |
S36 36-cancellation-both-recipients.jpg |
Patient and provider handsets after cancellation; separate sets for patient/admin source | Correct cancelled appointment/time and recipient; source noted in manifest | CAN-001/002 |
The first documentation pass can use S01, S03–S06, S09–S11, S13–S18, S20–S21, S24–S26, S29, S31–S33 and S35–S36. The remaining core captures add detail to the corresponding workflows.
Additional regression and integration images
These are useful evidence or troubleshooting illustrations; capture them after the main flow is correct.
| Filename | Required state | Case / purpose |
|---|---|---|
37-slot-conflict.jpg |
Second tester loses the same-slot race, with clean recovery | BKG-009 |
38-configuration-impact.jpg |
Schedule/archive edit blocked by affected future appointments, with explicit resolution | IMP-001/002 |
39-price-revision-conflict.jpg |
Stale revision error without overwritten pricing | TRT-007 |
40-payment-send-failed.jpg |
Saved payment and separately failed/unqueued notification | PAY-009 |
41-specialist-visit.jpg |
Specialist visit dates/hours, cohort and immediate-send option | REV-010 |
42-recall-treatment-registry.jpg |
Registry entry showing dates/interval/status | REV-001 |
43-assistant-rules.jpg |
Saved response/redirect/location settings | INT-001/002 |
44-portal-branding-mobile.jpg |
QA portal on a 360–430px phone viewport | INT-004; SEC-008 |
45-upi-qr-test.jpg |
QA payment configuration/preview with non-production details and safe QR | INT-005 |
46-google-calendar-test.jpg |
Connected dedicated test calendar plus real corresponding test event | INT-007; mask account identity |
47-unknown-delivery-outcome.jpg |
Unknown outcome with no unsafe automatic resend | COM-008 |
48-admin-stepped-run.jpg |
Admin test run showing steps, pause/cancel and evidence state | Existing WhatsApp runner guide; never expose customer data |
Existing images under /docs/booking-whatsapp/ can illustrate sender selection, template editing, linking and delivery settings if they match the deployed build. Do not reuse a failed-message screenshot as evidence of successful delivery.
Handover
Send the filenames above with the capture manifest. For a broken state, include the case ID and expected/actual difference; keep that image as defect evidence until fixed. Once supplied, insert verified images beside the relevant tutorial case with descriptive alt text and confirm that each published asset URL loads. Image links must not be added before files exist.