Acceptance Testing Strategy

Acceptance Testing Strategy

Purpose

The purpose of acceptance testing is to verify that the Neighborhood Emergency Preparedness Hub (NEPH) satisfies user and stakeholder expectations before it is considered ready for release.

Unit, integration, and system tests check whether the system is technically correct. Acceptance testing checks whether the team is building the right product from the perspective of residents, helpers, administrators, and other stakeholders.

Acceptance testing will focus on realistic scenarios involving:

• residents who need emergency help,
• helpers or volunteers who provide resources, skills, or assistance,
• administrators who manage emergency-related information and announcements.

Acceptance Testing Approach

The acceptance testing strategy will be both scenario-based and requirements-based. Each major user scenario will be converted into one or more acceptance test cases. These test cases will verify whether the implemented system supports the intended user goals under realistic conditions.

The strategy includes:

• Requirement-based testing: Each acceptance test will be linked to one or more functional or non-functional requirements.
• Scenario-based testing: Tests will follow realistic emergency preparedness and help-request flows.
• Role-based testing: Tests will be executed from the perspective of different roles such as requester, helper, administrator, and guest.
• End-to-end testing: Critical workflows will be tested from the mobile or web client through the backend, database, and notification behavior.
• Offline-first testing: Selected mobile tests will verify behavior under unavailable or unstable network conditions where offline support is implemented.
• Usability-oriented testing: Tests will check whether users can complete critical tasks without confusion and receive clear feedback after important actions.

Test Case Structure

Each acceptance test case will follow a consistent structure so that tests are easy to understand, execute, and trace.

Field	Description
Test Case ID	Unique identifier, such as AT-REQ-001
Test Title	Short name of the behavior being tested
Related Requirement(s)	Requirement IDs covered by the test
User Role	Requester, helper, administrator, or guest
Priority	High, Medium, or Low
Preconditions	Conditions that must be true before execution
Test Data	Specific data used during the test
Test Steps	Ordered steps followed by the tester
Expected Result	What the system should do
Actual Result	What actually happened during execution
Status	Pass, Fail, Blocked, or Not Run
Defect Link	Link to the GitHub issue if the test fails
Notes	Extra observations, questions, or follow-up items

Acceptance Criteria

The system will be considered acceptable if the following conditions are met:

• High-priority user flows can be completed successfully.
• Critical emergency workflows work on the mobile application.
• Help requests can be created, matched, updated, and resolved.
• Important notifications are delivered or shown through the correct channel.
• Offline-supported mobile features behave as documented.
• Users receive clear feedback after important actions.
• Unauthorized users cannot access protected features or data.
• Failed tests are documented with reproducible steps and linked defect reports.

Main Acceptance Test Areas

1. User Registration and Authentication

Acceptance tests will verify that users can create accounts, log in, log out, and access only the features allowed for their role.

Example criteria:

• A registered user shall be able to log in with valid credentials.
• A user shall not be able to log in with an incorrect password.
• A logged-in user shall be able to view and edit their profile.
• Unauthorized users shall not access protected pages or API endpoints.
• Admin-only pages and endpoints shall reject non-admin users.

2. User Profile and Preparedness Information

Acceptance tests will verify that users can maintain useful preparedness information, including contact information, health information, skills, expertise, location, and privacy settings.

Example criteria:

• A user shall be able to update profile information.
• A helper shall be able to specify relevant skills or expertise.
• Updated profile information shall be shown correctly after saving.
• Sensitive user information shall not be shown to unauthorized users.
• Location-sharing settings shall be clear and controllable by the user.

3. Helper Availability

Acceptance tests will verify that users who are willing to help can mark themselves as available or unavailable.

Example criteria:

• A helper shall be able to turn availability on.
• A helper shall be able to turn availability off.
• The system shall not match unavailable helpers with new help requests.
• The system should remind helpers if they remain available for a long time, where reminder functionality is enabled.

4. Help Request Creation

Acceptance tests will verify that users can create help requests with the required information.

Example criteria:

• A requester shall be able to create a request with category, description, location, contact details, and urgency-related information.
• The system shall reject a request if required fields are missing.
• The requester shall see confirmation after the request is created.
• The created request shall appear in the relevant request list.
• Guest-created requests shall behave according to the supported guest flow.

5. Help Request Matching and Assignment

Acceptance tests will verify that the system connects users who need help with suitable helpers.

Example criteria:

• The system shall match requests with helpers based on location, availability, and relevant skills or resources.
• The system shall not match helpers who are unavailable.
• The helper shall be able to see assigned requests.
• The helper shall be able to cancel or resolve an assignment according to the supported workflow.
• Request status changes shall be reflected correctly for the requester and helper.

6. Notifications

Acceptance tests will verify in-app notifications and push-notification behavior where push delivery is enabled.

Push notifications should be used for urgent or externally relevant events, such as:

• emergency announcements near the user,
• a help request being matched with a possible helper,
• someone responding to the user's help request,
• important request status changes.

In-app notifications should be used for lower-priority or app-visible events, such as:

• helper availability reminders,
• resource or request expiration reminders,
• general request status changes.

Example criteria:

• A user shall be able to view their in-app notifications.
• A user shall be able to mark one notification or all notifications as read.
• Notification preferences shall be saved and respected.
• Delivery failures shall not prevent the underlying emergency workflow from continuing.

7. Offline and Synchronization Behavior

Acceptance tests will verify that the mobile application behaves reasonably during network problems.

Example criteria:

• The user shall be able to view supported cached emergency-critical information while offline.
• The user shall receive clear feedback when trying to perform an action that requires network access.
• Locally stored changes shall synchronize when connectivity returns, where offline synchronization is supported.
• Synchronization conflicts shall not silently overwrite important user data.
• Failed sync operations shall remain visible or recoverable where supported.

8. Gathering Areas and Location Features

Acceptance tests will verify that users can discover location-based emergency information.

Example criteria:

• A user shall be able to view nearby gathering areas for their current or selected location.
• The system shall show a clear message if the external gathering-area provider is unavailable.
• The user shall be able to retry loading nearby gathering areas.
• Location search and reverse-geocoding behavior shall provide usable feedback when the provider is unavailable or returns no result.

9. Admin Announcements and Emergency Information

Acceptance tests will verify that administrators can manage emergency-related information and that non-admin users cannot perform admin actions.

Example criteria:

• An administrator shall be able to create or manage an emergency announcement where announcement-management functionality is implemented.
• The announcement shall be visible to relevant users.
• Users in the affected area shall receive the appropriate notification where targeted notification behavior is implemented.
• Non-admin users shall not create official announcements.

10. Admin Emergency Dashboard

Acceptance tests will verify that administrators can monitor emergency activity and operational status.

Example criteria:

• An administrator shall be able to view the emergency overview.
• An administrator shall be able to view emergency history.
• An administrator shall be able to view emergency insights and analytics.
• An administrator shall be able to view deployment-monitoring signals.
• Empty states shall be handled clearly when no emergency data exists.
• Backend errors shall be shown with retry options and linked to defect reports when they block acceptance testing.

Defect Handling

When an acceptance test fails:

1. The tester will record the actual result.
2. The tester will create or link a GitHub issue.
3. The issue will include reproduction steps, test data, screenshots or logs if available, expected behavior, and observed behavior.
4. The test case status will be marked as Fail or Blocked.
5. The test will be re-run after the defect is fixed.

Release Readiness Decision

Acceptance testing should produce a release decision based on test results:

• Ready: All high-priority acceptance tests pass and no critical defects remain open.
• Conditionally ready: High-priority flows pass, but medium- or low-priority defects remain and are documented.
• Not ready: One or more critical emergency, authentication, privacy, notification, or admin workflows fail.