Acceptance Testing Strategy

Acceptance Testing Strategy

How We Structure Acceptance Tests

Each acceptance test is documented as a standalone wiki page under the Acceptance Tests section of the project wiki.

• Header — test case name, author, related issues, feature under test.
• Description — what the feature does and what the test verifies.
• Prerequisites — environment, deployment URL, seeded data, user role.
• Scenario tables — one table per scenario, with the columns # | Instruction | Expectation | Result | Note.
• Instruction — a specific, step-by-step user action.
• Expectation — the observable system behaviour.
• Result and Note are intentionally left blank for the tester to fill in during execution.

This shape is uniform across web and mobile features. Each test references the deployed application, not internal code paths, so it can be executed by any team member or external stakeholder without reading the implementation.

Strategy

Our acceptance testing strategy rests on five principles:

• User-perspective only. Tests describe what an end user does and sees on the deployed app. No mocks, no internal API assertions, no test-only shortcuts.
• Per-feature, not per-component. One acceptance test document covers one user-visible feature end-to-end, such as registration, profile setup, emergency help request submission, gathering areas, notifications, admin announcements, or admin emergency overview, not isolated UI pieces.
• Manual execution, with automated regression where coverage exists. Where the web frontend end-to-end tests and backend Jest tests already cover a feature, those runs back up the manual acceptance scenarios and catch regressions on every PR. UX-heavy, mobile-specific, offline, notification, or visual flows stay manual unless reliable automated coverage exists.
• Milestone gates for the Final Release. Before the Final Release tag, the full acceptance suite for in-scope features will be executed manually and the results recorded in the Result / Note columns. A feature is only considered "shippable" when all its in-scope acceptance scenarios pass.
• Cross-platform parity. Features that exist on both web and mobile have separate acceptance tests per platform, even when they share the same backend, because the user interaction is genuinely different.

Acceptance Criteria — "The Right Thing"

We validate that we are building the right product, not just building something correctly, by holding every test to four stakeholder-facing criteria:

• Traceability to requirements. Every functional requirement in the project requirements document maps to at least one acceptance test. A requirement with no acceptance test is treated as not delivered.
• Realistic data. Scenarios use realistic emergency-preparedness data, such as Istanbul-anchored locations, plausible Turkish phone numbers, meaningful help request categories, believable risk flags, and realistic admin workflows, so passing the test demonstrates that the feature actually serves the Neighborhood Emergency Preparedness Hub use case, not a synthetic happy path.
• Demo-grade pass criterion. A scenario passes only if the behaviour could be shown live to the instructor, TA, jury, or customer without scripted environment resets or hidden setup. If the tester needs to reload, refresh state, manually patch data, or "know a trick", the scenario fails.
• Negative path coverage. Each feature has at least one scenario for invalid input, empty state, provider failure, unavailable network, or permission boundary. Building the right thing means the system also fails gracefully where the user expects pushback, such as invalid phone numbers, unauthenticated actions, unavailable gathering-area provider responses, or non-admin access attempts.