AppzCart Clinic · Manual UI testing

Test strategy

For everyone who tests a release before it is deployed · Updated 02-11-2026

Every release is tested by hand, in the browser, as each role before it is deployed. This page says what kinds of testing we do, what is left out, how a test run goes, and when a release is ready. The cases themselves are in the high-level scenarios and the detailed scenarios.

1. Scope

In scope	Out of scope
Manual testing of the web app's screens, for every role in this release The patient flows across roles: Reception → Nurse → DMO / Doctor → Lab Sign-in, roles and permissions, and what each role can and can't see Clinic Admin set-up tools and the Excel workbook Reports, notifications, themes and the doctor's Aura / Classic designs	Performance, load and stress testing Security / penetration testing Automated tests (the developers run those separately) Modules switched off in this release: Pharmacy, Billing, Follow-ups & Reminders, Patient portal (`apps/web/src/lib/release.ts`). They come into scope in the release that switches them on.

2. Kinds of testing

Only these eight. They are listed in the order a test run uses them.

#	Kind	What it checks	When
T1	Smoke test	The app opens, every role can sign in and lands on its home screen, and each main screen loads with no error. If this fails, stop: the build goes back.	First, on every build
T2	End-to-end flow	A patient's whole journey across roles, with the hand-off at each step: the patient appears in the next role's queue, the stage and status change, and the notification arrives. See the high-level scenarios.	Every release
T3	Role-based functional	Every tab, button and Actions menu item of a role's screens does what it says. See the detailed scenarios.	Every release
T4	Validation and messages	Required fields: Save with one empty names the field, rings it in red and puts the cursor in it. Wrong-order actions are refused with a clear message (for example, rescheduling a patient who is already in care).	Every release
T5	Role access	Each role sees only its own screens and data. A part the role has no View for shows as "Hidden by your role". A changed permission takes effect.	Every release
T6	Saved data	After a save: refresh the page (and sign in on a second browser). The change is still there and the other role sees it.	Every release
T7	Look and layout	Modern Aqua by default, and one other theme from Settings. The Doctor's Aura and Classic show the same data. The screen works at phone width with no sideways scroll. Labels aren't cut off.	Every release, a sample of screens
T8	Regression	All Critical and High cases from earlier releases still pass, not only the new features.	Every release

Browsers: Google Chrome (main) and Microsoft Edge, latest versions, on a laptop screen. Phone width is checked with the browser's device toolbar (F12 › device icon), at 390 px wide.

3. Test data and accounts

Use a test database, never the clinic's live data.
Sign in as admin › Clinic Admin › Tools › Download test data, then Import from Excel › Replace everything. This loads a complete fictional clinic: staff, 30 patients and today's visits at every stage.

Test staff accounts (password: ask the test lead; it is never written in these pages):

Role	Accounts
Receptionist	`rahul.verma`, `kavya.reddy` (also Front Desk Lead)
Nurse	`priya.nair`, `anjali.pawar`, `rekha.more`
DMO	`kavita.desai`, `sameer.gupta`
Doctor	The eight doctors in the test data (see the team plan)
Lab Technician	`suresh.kale`, `deepa.sawant`
Report Viewer	`nikhil.bhat`
Clinic Admin	`admin`, `pooja.mehta`

Use a new patient for each end-to-end scenario, named so it is easy to find: Test-<scenario>-<your initials>, for example Test-HL01-RV.
If the data gets mixed up, the test lead re-imports the test data (Replace everything) and everyone signs in again.

4. A release test run

Build ready
Load test data
Smoke (T1)
End-to-end flows (T2)
Role screens (T3–T7)
Regression (T8)
Retest fixes
Sign-off

Entry: the developers say which build and which features are in it. The API and the web app run, and the test data is loaded.
Plan: the test lead gives each tester one role (see the team plan). The end-to-end flows are run together, in hand-off order: Reception starts the patient, then tells the Nurse, and so on.
Run: work through the assigned cases and mark each one in the team plan page. On a Fail, write what happened and take a screenshot.
Report: at the end, press Export to Excel on the team plan page and send the file to the test lead. The lead combines the files; the Dashboard sheet shows the totals.
Retest: after fixes, re-run the failed cases and the end-to-end flow they belong to.

5. Results and defects

Status	Meaning
Pass	Everything in "Expected" happened.
Fail	Something in "Expected" didn't happen, or an error appeared. Write a defect.
Blocked	Couldn't be tested: an earlier step failed, or the data or account was missing. Say what blocked it.
Not run	Not done yet.

A good defect has the case ID, the account used, the steps, what was expected, what happened, the exact message on screen, and a screenshot.

Severity	Meaning	Example
Critical	A main flow can't continue, data is lost or wrong, or a role sees what it mustn't.	The nurse can't hand the patient to the doctor; a nurse can open the admin tools.
High	A feature doesn't work, but there is a way around it.	Reschedule fails from the Actions menu but works from the row menu.
Medium	Wrong message, wrong label, or validation that doesn't point at the field.	Save with an empty Sex says "Error" instead of naming the field.
Low	Look only.	Misaligned column, wrong colour in one theme.

6. When a release is ready

Every smoke test passes.
Every end-to-end scenario passes.
No open Critical or High defect.
Every case is run (nothing left as Not run). Blocked cases are explained and accepted by the owner.
Medium and Low defects are listed, and the owner accepts them for this release.
The owner signs off: name, date, build. The Excel file is kept with the release.

7. Keeping the cases up to date

This is ongoing work. When a feature is added or changed, its cases are added or changed in test/cases.js in the same piece of work. The detailed page and the team plan both read that one file. When a module is switched on in release.ts, its cases move into scope. Case IDs are never reused.