Test Plan & Coverage

Test Plan

1. Testing Strategy

Our testing strategy focuses on the test types that are most relevant for the MVP and practical to maintain during development.

We will use:

• Frontend: component testing, scenario-based testing
• Backend: unit testing, integration testing, API testing
• Overall system: end-to-end testing

This combination is sufficient to validate isolated backend logic, key frontend behaviors, realistic user flows, and complete system functionality.

2. Frontend Testing

Frontend testing will focus on validating user interface behavior and user-facing flows.

2.1 Component Testing

Component tests will verify isolated frontend behaviors such as:

• correct rendering of UI elements
• form input handling
• validation messages
• button enable/disable conditions
• loading, success, and error states

2.2 Scenario-Based Testing

Scenario-based testing will validate realistic user interactions and workflows from the frontend perspective.

These tests will focus on flows such as:

• completing registration and login
• editing profile information
• creating and viewing requests
• following assignment, cancellation, and resolution flows
• receiving correct feedback at each step

The goal is to ensure that the interface supports meaningful user journeys in a clear and usable way.

3. Backend Testing

Backend testing will focus on validating business logic, service interaction, and API behavior.

3.1 Unit Testing

Unit tests will verify isolated backend logic such as:

• validation rules
• assignment rules
• status transition rules
• sync-related decision logic

3.2 Integration Testing

Integration tests will verify that backend components work correctly together.

These tests will focus on flows such as:

• authentication and authorization
• profile and request operations
• assignment and cancellation flows
• resolution and admin actions

3.3 API Testing

API tests will verify:

• correct endpoint behavior
• correct request validation
• correct response payloads
• proper error responses
• consistency of backend state after requests

3.4 End-to-End Testing

End-to-end testing will verify complete workflows across the system, including frontend, backend, and final user-visible outcomes.

These tests will confirm that:

• users can complete critical MVP flows from start to finish
• frontend and backend communicate correctly
• final system behavior matches user expectations
• major workflows function without manual intervention

Test Plan Coverage

Our test plan coverage focuses on user acceptance criteria rather than only technical correctness. The goal is to validate that the MVP delivers the core value of the product and supports the main user journeys successfully, consistently, and in a usable way.

The MVP will be considered acceptable if users can complete the essential flows of the system with clear feedback, reliable state transitions, and without depending on manual intervention.

1. User Acceptance Criteria

From a user perspective, the MVP is acceptable if it satisfies the following criteria:

1.1 Account Access and Identity

Users must be able to register, log in, and access the application areas.

Acceptance will be based on whether:

• A new user can create an account successfully
• An existing user can log in again without issues
• Authenticated users can access protected features
• Admin users can access admin-only functionality
• Unauthorized users are prevented from accessing restricted actions

1.2 Profile Completeness and Usability

Users must be able to manage their profile information in a way that supports the core platform workflows.

Acceptance will be based on whether:

• users can edit core profile information
• users can define profession, availability, and location
• privacy-related settings are reflected correctly in the UI and flow
• profile data remains consistent after save, reload, and sync

1.3 Help Request Creation and Visibility

A requester must be able to create a help request and view relevant request information afterwards.

Acceptance will be based on whether:

• A help request can be created successfully
• The created request appears correctly in request views
• Request information is understandable and complete
• The request remains available through reloads and sync behavior

1.4 Assignment Flow

The system must support the basic MVP assignment flow in a way that is understandable and useful for the user.

Acceptance will be based on whether:

• A request can be assigned through the MVP flow
• The assigned state is visible to the relevant user
• Users can understand whether a request is pending, assigned, cancelled, or resolved

1.5 Cancellation and Resolution

The MVP must support the natural life cycle of a request after assignment.

Acceptance will be based on whether:

• An assignment can be cancelled successfully
• The system updates the visible status correctly after cancellation
• A request can be marked as resolved
• resolved requests are no longer treated as active requests

1.6 Web Information Access

The web MVP must provide public and administrative information clearly.

Acceptance will be based on whether:

• users can view the landing page and understand the purpose of the platform
• users can read announcements