Test Plan & Coverage

Test Plan & Coverage

This document outlines our testing strategy and coverage to ensure both the technical correctness of our system and the user-level validity of our product across all milestones — from the MVP through the Final Deliverable.

---

1. Test Plan (Testing Strategy)

To maintain a robust codebase and prevent regressions, our testing strategy incorporates multiple layers of testing throughout the development lifecycle, heavily integrated into our PR review process.

1.1 Unit Testing

We will write unit tests for isolated, critical functions focusing on core business logic. Specifically:

• Routing Algorithm: Cost-calculation functions, graph construction from the street network, slope evaluation logic, and edge-weight adjustments based on active obstacles.
• Report Validation: Input validation for new obstacle reports (required photo, category selection, GPS coordinate format, outdoor/indoor classification).
• Report Lifecycle Engine: State transition logic ensuring reports follow the correct lifecycle (UNVERIFIED → VERIFIED → RESOLVED_AWAITING_VALIDATION → CLOSED), including PASSIVE timeout calculations.
• Trust Score Calculation: Incrementing trust scores on verification, threshold checks for granting "Trusted Contributor" role, and lowered verification threshold assignment.
• Verification Threshold Logic: Upvote counting, flag counting, and the automatic status change when the threshold is reached.
• Spam Detection: Logic that flags accounts submitting a high volume of unverified reports in a short timeframe as "Potential Spam."
• Notification Triggers: Functions that determine which users should be notified upon report status changes (original reporter, upvoters, affected route users).

Tools: Jest (frontend), pytest or unittest (backend, depending on framework choice).

1.2 API Testing

We will test all backend REST endpoints to ensure correct status codes, response bodies, authentication enforcement, and error handling. Key endpoints include:

• Authentication: POST /auth/register, POST /auth/login, POST /auth/logout, POST /auth/password-reset, POST /auth/refresh — verifying correct JWT token generation, error responses for invalid credentials (generic "invalid credentials" with no information leakage), password validation rules, and token refresh flow.
• User Profile: GET /users/me, PUT /users/me, GET /users/me/badges, PUT /users/me/notifications — verifying profile retrieval and update, badge listing, and notification toggle.
• Mobility Profiles: POST /users/me/mobility-profile, GET /users/me/mobility-profile, PUT /users/me/mobility-profile, DELETE /users/me/mobility-profile — verifying CRUD operations for mobility profiles (one per user constraint).
• Reports: POST /reports, GET /reports/{reportId}, GET /reports/{reportId}/photos, POST /reports/{reportId}/photos, GET /reports/{reportId}/status-history — verifying report creation with required fields (photo, context, GPS), proper 400/422 errors on missing fields, photo management, and status timeline retrieval.
• Map & Routing: GET /map/obstacles?bbox=...&status=...&includePassive=..., POST /routes/calculate, GET /map/search?q=... — verifying obstacle filtering by bounding box, passive report toggling, route calculation with preferences, and location search.
• Community Interactions: POST /reports/{reportId}/upvote, POST /reports/{reportId}/flag, POST /reports/{reportId}/confirm-resolution — verifying only authenticated users (role: User) can perform these, 409 Conflict on duplicate upvotes, and threshold-triggered status changes.
• Authority Dashboard: GET /authority/dashboard?status=..., PUT /authority/reports/{reportId}/resolve, POST /authority/reports/{reportId}/repair-photos — verifying Authority-role access, mandatory repair photo and notes (422 if missing), and status transition to RESOLVED_AWAITING_VALIDATION.
• Admin Moderation: GET /admin/moderation-queue, DELETE /admin/reports/{reportId}, POST /admin/users/{userId}/ban, POST /admin/users/{userId}/suspend, POST /admin/users/{userId}/unban — verifying Admin-role access, permanent deletion, and account status changes (BANNED/SUSPENDED).
• Notifications: GET /notifications?unreadOnly=..., PUT /notifications/{id}/read — verifying paginated notification retrieval and read status updates.

Tools: Postman collections (manual & automated), or automated HTTP test scripts (e.g., supertest for Node.js, requests + pytest for Python).

1.3 Integration Testing

We will test the interactions between our major system components to verify end-to-end data flow:

• Frontend ↔ Backend API: The map interface correctly sends viewport bounds and receives obstacle markers; the route request form sends origin/destination/preferences and correctly renders the returned path.
• Backend ↔ Database: Report creation persists correctly in the database; status updates (upvote thresholds, passive timeouts) are reflected in subsequent queries; trust score updates persist and affect future verification thresholds.
• Routing Engine ↔ Obstacle Data: The routing graph correctly excludes active outdoor obstacles, ignores indoor obstacles, and excludes passive reports from path calculations.
• Notification System ↔ Report Lifecycle: Status transitions correctly trigger asynchronous push notifications to the right set of users.
• Authentication ↔ Role-Based Access: Guest users are blocked from reporting; registered users can report; infrastructure authority users can access the dashboard; admin users can access moderation tools.

Tools: Integration test suites using the same frameworks as unit tests, running against a test database seeded with known data.

1.4 Mock Data Strategy

Since our MVP covers Boğaziçi University North and South Campuses, we will seed our development and test databases with realistic mock data:

• Campus Obstacles: Specific stairs, steep slopes, broken ramps, narrow sidewalks, and construction zones at real GPS coordinates on campus.
• Indoor Obstacles: Known buildings with accessibility issues (e.g., lack of elevator, narrow doorways) tagged as indoor with proper coordinates.
• User Accounts: Pre-created accounts for each role — GUEST sessions, REGISTERED_USER accounts with varying trust scores, a TRUSTED_CONTRIBUTOR, an INFRASTRUCTURE_AUTHORITY account, and an ADMINISTRATOR account.
• Report Lifecycle Data: Reports in every lifecycle state (UNVERIFIED, VERIFIED, PASSIVE, RESOLVED_AWAITING_VALIDATION, CLOSED) to test filtering, display, and transition logic.
• Route Test Fixtures: Known origin-destination pairs where the shortest path passes through an active obstacle, enabling deterministic testing of the avoidance algorithm.

1.5 Continuous Integration (PR Reviews)

All code must pass automated checks and be manually reviewed by at least one team member before being merged into the main development branch:

• Every PR triggers the full unit and API test suite.
• PRs that touch routing logic, report lifecycle, or trust system must include corresponding new or updated tests.
• Manual code review focuses on logic correctness, security considerations (e.g., SQL injection, XSS), and adherence to the agreed API contract.
• Testing is a prerequisite for PR approval — PRs with failing tests cannot be merged.

---

2. Test Plan Coverage (User Acceptance Criteria)

Our test coverage focuses heavily on User Acceptance Criteria (UAC) to validate that we are building "the right thing" from the user's perspective. The scenarios below cover both MVP and Final Deliverable features comprehensively.

---

Scenario 1: Guest Access & Browsing (MVP)

Criteria: The system must allow unregistered guests to browse the map and view existing data without logging in. (SRS: 1.1.1.1, 1.1.1.2, 1.1.3.1, 1.1.3.2)

Test ID	Test Case	Expected Result	SRS Ref
UAC-1.1	A guest user opens the app for the first time.	The interactive map loads centered on Boğaziçi University campus with no login prompt.	1.1.1.1, 1.2.1.1
UAC-1.2	A guest user pans and zooms the map.	Map responds fluidly; existing obstacle markers render at their correct GPS coordinates.	1.1.3.1, 1.1.3.2
UAC-1.3	A guest clicks on an obstacle marker.	A modal/popup opens showing the report's text description, photo evidence, category, and current status.	1.1.1.2, 1.1.3.3
UAC-1.4	A guest user sets temporary routing preferences (e.g., "Avoid Stairs") for the session.	Preferences are applied to subsequent route requests within the same session only; no persistence after session ends.	1.1.2.3
UAC-1.5	A guest attempts to submit an obstacle report.	The system denies submission and redirects the user to the registration/login page.	1.1.5.1, NFR-5.1
UAC-1.6	A guest attempts to upvote or flag a report.	The action is blocked and the user is prompted to register or log in.	1.1.6.1, 1.1.6.2, NFR-5.1

---

Scenario 2: Registration & Authentication (MVP)

Criteria: Users must be able to register, log in, log out, and recover their password securely. (SRS: 1.1.1.3–1.1.1.7)

Test ID	Test Case	Expected Result	SRS Ref
UAC-2.1	A user registers with a valid email, full name, birth date, and secure password.	Account is created successfully; user is redirected to the map/profile.	1.1.1.3, 1.1.1.4
UAC-2.2	A user attempts to register with an already-used email address.	Registration fails with an appropriate error message.	1.1.1.3
UAC-2.3	A user attempts to register with a weak password (e.g., "123").	Registration fails with a password strength validation error.	1.1.1.4
UAC-2.4	A registered user logs in with correct credentials.	Login succeeds; user session is established and profile data is accessible.	1.1.1.5
UAC-2.5	A user attempts to log in with incorrect credentials.	Login fails with a generic "invalid credentials" error (no information leakage).	1.1.1.5, NFR-5.2
UAC-2.6	A logged-in user logs out.	Session is terminated; user is returned to guest mode.	1.1.1.6
UAC-2.7	A registered user requests a password reset.	A reset link is sent to the registered email address.	1.1.1.7

---

Scenario 3: Profile & Accessibility Preferences (MVP + Final)

Criteria: Registered users can manage their profile, mobility preferences, and saved destinations. (SRS: 1.1.2.1–1.1.2.6)

Test ID	Test Case	Expected Result	SRS Ref
UAC-3.1	A registered user creates a Mobility Profile selecting "Wheelchair" as primary mobility aid.	Profile is saved and persists across sessions.	1.1.2.1, 1.1.2.2
UAC-3.2	A registered user updates their mobility aid from "Wheelchair" to "Stroller."	The updated preference is reflected immediately and affects future route calculations.	1.1.2.1, 1.1.2.2
UAC-3.3	A registered user saves a frequent destination labeled "Home."	The destination appears in the user's saved list and can be used as a quick-select in route planning.	1.1.2.4
UAC-3.4	A registered user views their profile page.	Earned badges (if any), trust score, and contribution history are displayed.	1.1.2.5
UAC-3.5	A registered user toggles system notifications off.	The user no longer receives push notifications for report status changes.	1.1.2.6

---

Scenario 4: Map Interaction & Visualization (MVP + Final)

Criteria: The map must be interactive, display correct data layers, and handle indoor/outdoor distinction. (SRS: 1.1.3.1–1.1.3.7, 1.2.1.1–1.2.1.4)

Test ID	Test Case	Expected Result	SRS Ref
UAC-4.1	The application launches.	The map renders centered on the MVP scope (Boğaziçi University North/South Campuses) with standard base layers (roads, buildings, green areas).	1.2.1.1, 1.2.1.2
UAC-4.2	Active obstacle markers exist in the seeded data.	All markers render at correct GPS coordinates with the correct category icon.	1.1.3.3
UAC-4.3	A user zooms in on a building known to have indoor obstacles.	Indoor obstacle POI markers become visible only after the zoom level exceeds the High-Detail Threshold.	1.1.3.4, 1.2.1.3
UAC-4.4	A user zooms out below the High-Detail Threshold.	Indoor obstacle markers are hidden from the map.	1.2.1.3
UAC-4.5	Passive reports (stale/unverified) exist in the database.	They render with a distinct semi-transparent visual style, clearly differentiated from active issues.	1.2.1.4
UAC-4.6	A user toggles the "Show Passive Reports" visibility filter off.	Passive report markers are hidden from the map; only active/verified markers remain.	1.1.3.5
UAC-4.7	A user searches for "North Campus Library" using the text search.	The map pans/zooms to the matching location.	1.1.3.6
UAC-4.8	A user drops a pin manually on the map.	The pin is placed at the exact tapped/clicked location and its coordinates are captured.	1.1.3.7

---

Scenario 5: Accessibility Routing — Default Path (MVP)

Criteria: The system must generate a visual path that actively avoids reported outdoor obstacles. (SRS: 1.1.4.1–1.1.4.5, 1.2.2.1–1.2.2.4)

Test ID	Test Case	Expected Result	SRS Ref
UAC-5.1	A user selects an origin pin and a destination pin and requests a route with no obstacles on the path.	The system renders a static visual line (Blueprint) connecting the two points via the shortest accessible path.	1.1.4.1–1.1.4.4, 1.2.2.1
UAC-5.2	An active outdoor obstacle report is situated directly on the shortest path between origin and destination.	The generated route successfully detours around the obstacle, choosing an alternative accessible path.	1.2.2.1
UAC-5.3	An indoor obstacle exists near the route but is categorized as "Indoor."	The indoor obstacle is completely ignored by the routing algorithm; the route does not detour for it.	1.2.2.2
UAC-5.4	A passive report exists on the shortest path.	The passive report is excluded from route calculations; the route passes through that area normally.	1.2.2.3
UAC-5.5	The destination is inside a building.	The route is generated up to the building entrance, not to an internal room.	1.2.2.4
UAC-5.6	A user views the generated route details.	A textual summary displaying Total Distance and Estimated Time is shown alongside the visual path.	1.1.4.5

---

Scenario 6: Personalized Routing (Final)

Criteria: The system must customize routes based on individual mobility profiles. (SRS: 1.1.2.1, 1.1.2.2, Final Deliverable roadmap)

Test ID	Test Case	Expected Result	SRS Ref
UAC-6.1	A wheelchair user with "Avoid Stairs" preference requests a route that would normally go through stairs.	The system generates a route that avoids all stair segments and steep slopes exceeding the safe gradient.	1.1.2.1, 1.1.2.2
UAC-6.2	A user with no mobility restrictions requests the same route.	The system generates the shortest path, potentially including stairs if they are the fastest option.	1.2.2.1
UAC-6.3	A guest user sets "Avoid Stairs" as a temporary session preference and requests a route.	The route avoids stairs for that session; the preference is not persisted.	1.1.2.3

---

Scenario 7: Obstacle Reporting (MVP)

Criteria: Registered users must be able to submit verifiable obstacle reports with mandatory fields. (SRS: 1.1.5.1–1.1.5.5)

Test ID	Test Case	Expected Result	SRS Ref
UAC-7.1	A logged-in user drops a pin at their GPS location, selects context OUTDOOR, selects category BROKEN_RAMP, uploads a photo, adds a description, and submits via POST /reports.	The report is created with status UNVERIFIED; the new obstacle marker appears on the map immediately for all users. If a duplicate exists within 20m, duplicateCandidate is returned.	1.1.5.1–1.1.5.5, 1.2.3.1
UAC-7.2	A logged-in user attempts to submit a report without uploading a photo.	Submission is rejected with a validation error indicating at least one photo is required.	1.1.5.4
UAC-7.3	A logged-in user submits a report with context INDOOR.	The report is created; the marker only appears when other users zoom past the High-Detail Threshold.	1.1.5.2, 1.2.1.3
UAC-7.4	A guest user attempts to call POST /reports.	The API returns 401 Unauthorized; the user is redirected to registration/login.	NFR-5.1
UAC-7.5	A logged-in user submits a report without selecting an obstacle category.	Submission succeeds (category is optional); report is created under OTHER or uncategorized.	1.1.5.3

---

Scenario 8: Community Verification & Moderation (Final)

Criteria: Registered users can upvote, flag, and confirm resolutions; the system manages report lifecycle transitions automatically. (SRS: 1.1.6.1–1.1.6.4, 1.2.3.1–1.2.3.3)

Test ID	Test Case	Expected Result	SRS Ref
UAC-8.1	A registered user calls POST /reports/{reportId}/upvote on an unverified report.	The upvote count increments by one; response includes statusChanged: false if threshold not yet met.	1.1.6.1
UAC-8.2	An unverified report receives enough upvotes to reach the Verification Threshold.	The system automatically changes the report status to VERIFIED; response includes statusChanged: true and newStatus: "VERIFIED".	1.2.3.3
UAC-8.3	A registered user calls POST /reports/{reportId}/flag with a reason string.	The flag is recorded; if enough flags accumulate, queuedForModeration: true is returned.	1.1.6.2
UAC-8.4	A registered user attempts to upvote their own report or upvote the same report twice.	The API returns 409 Conflict.	1.1.6.1
UAC-8.5	An unverified report receives no interaction for the predefined timeout period.	The system automatically changes the report status to PASSIVE and renders it with semi-transparent styling.	1.2.3.2, 1.2.1.4
UAC-8.6	A user calls GET /reports/{reportId}/status-history.	The full history is displayed with from/to status transitions and timestamps.	1.1.6.4
UAC-8.7	A guest user attempts to upvote a report.	The API returns 401 Unauthorized; user is prompted to log in.	NFR-5.1

---

Scenario 9: Trust Score & Gamification (Final)

Criteria: The system tracks user reliability and rewards accurate contributors. (SRS: 1.2.5.1–1.2.5.5)

Test ID	Test Case	Expected Result	SRS Ref
UAC-9.1	A registered user's report transitions from UNVERIFIED to VERIFIED.	The user's Trust Score is incremented.	1.2.5.1, 1.2.5.2
UAC-9.2	A guest user submits a report (if somehow allowed in a future edge case).	No Trust Score is awarded.	1.2.5.3
UAC-9.3	A user's Trust Score exceeds the defined threshold.	The user is automatically granted the TRUSTED_CONTRIBUTOR role; GET /users/me/trust-score reflects the new role and a lowered verificationThreshold. The corresponding badge appears on their profile via GET /users/me/badges.	1.2.5.4, 1.1.2.5
UAC-9.4	A Trusted Contributor submits a new report.	The report may be auto-verified (autoVerified: true in the POST /reports response); the verification threshold is lower than for standard users.	1.2.5.5

---

Scenario 10: Infrastructure Authority Operations (Final)

Criteria: Municipality officers can manage, resolve, and provide evidence for reported issues. (SRS: 1.1.7.1–1.1.7.5)

Test ID	Test Case	Expected Result	SRS Ref
UAC-10.1	An Infrastructure Authority user logs in and calls GET /authority/dashboard.	A paginated list of reports loads with filtering options by status.	1.1.7.1, 1.1.7.2
UAC-10.2	An authority filters reports by status=VERIFIED.	Only verified, unresolved reports are displayed.	1.1.7.2
UAC-10.3	An authority calls PUT /authority/reports/{reportId}/resolve with repairNotes and repairPhoto.	The status transitions to RESOLVED_AWAITING_VALIDATION; the obstacle marker is NOT immediately removed from the map; notificationsSent count is returned.	1.1.7.3, 1.1.7.4, 1.1.7.5, 1.2.4.1, 1.2.4.2
UAC-10.4	An authority attempts to mark an issue as resolved without uploading a repair photo.	The API returns 422 Unprocessable; both repairPhoto and repairNotes are mandatory.	1.1.7.4
UAC-10.5	After an authority resolves an issue, the original reporter and all upvoters check GET /notifications.	Both the original reporter and upvoters have received notifications of type REPORT_RESOLVED.	1.2.4.3, 1.2.4.4
UAC-10.6	A regular REGISTERED_USER attempts to call GET /authority/dashboard.	The API returns 403 Forbidden due to insufficient role.	NFR-5.3

---

Scenario 11: Resolution Validation & Closure (Final)

Criteria: Resolved issues require citizen confirmation before permanent closure. (SRS: 1.2.4.1–1.2.4.5)

Test ID	Test Case	Expected Result	SRS Ref
UAC-11.1	A report is in RESOLVED_AWAITING_VALIDATION status. Citizens call POST /reports/{reportId}/confirm-resolution.	Votes are tallied correctly; response includes statusChanged: false until threshold is met.	1.1.6.3, 1.2.4.5
UAC-11.2	The required number of CONFIRM_RESOLUTION interactions is reached.	The system transitions the report to CLOSED status (statusChanged: true, newStatus: "CLOSED"); the obstacle marker is removed from the map.	1.2.4.5
UAC-11.3	An insufficient number of confirmation votes are cast within the validation period.	The report remains in RESOLVED_AWAITING_VALIDATION until enough votes are received or an admin intervenes.	1.2.4.5

---

Scenario 12: Administrator Moderation (Final)

Criteria: Admins can manage flagged content, delete malicious reports, and ban abusive users. (SRS: 1.1.8.1–1.1.8.3, 1.2.6.1)

Test ID	Test Case	Expected Result	SRS Ref
UAC-12.1	An admin calls GET /admin/moderation-queue.	All community-flagged reports are listed with flagCount, spamScore, and reporter details.	1.1.8.1
UAC-12.2	An admin calls DELETE /admin/reports/{reportId} with a reason.	The report is permanently removed; response returns deleted: true. The marker disappears from the map for all users.	1.1.8.2
UAC-12.3	An admin calls POST /admin/users/{userId}/ban with a reason.	The user's account status changes to BANNED; a SPAM_WARNING notification is sent to the user. The user can no longer log in.	1.1.8.3
UAC-12.4	The system detects a user submitting a high volume of unverified reports in a short timeframe.	The account is automatically flagged as "Potential Spam" (elevated spamScore) and appears in the admin moderation queue.	1.2.6.1

---

Scenario 13: Notification System (Final)

Criteria: The system sends asynchronous notifications to relevant users upon report status changes. (SRS: 1.2.6.2, 1.2.6.3, 1.2.4.3, 1.2.4.4)

Test ID	Test Case	Expected Result	SRS Ref
UAC-13.1	A report achieves VERIFIED status.	The original reporter receives a notification of type REPORT_VERIFIED via GET /notifications.	1.2.6.2
UAC-13.2	An Infrastructure Authority marks a report as resolved.	The original reporter AND all users who upvoted the report receive notifications of type REPORT_RESOLVED.	1.2.6.3, 1.2.4.3, 1.2.4.4
UAC-13.3	A user who has toggled notifications off via PUT /users/me/notifications.	That user does NOT receive any push notifications, even when their reports change status.	1.1.2.6

---

Scenario 14: Non-Functional Requirements Validation

These tests validate system-wide quality attributes.

Test ID	Test Case	Expected Result	NFR Ref
UAC-14.1	The application is accessed via a modern web browser (Chrome, Firefox, Safari, Edge).	The full application loads and functions correctly on all major browsers.	NFR-1.1, NFR-7.1
UAC-14.2	The application is accessed on a mobile device (iOS/Android).	The mobile application loads and functions correctly on current and recent OS versions.	NFR-1.2, NFR-7.2
UAC-14.3	A user requests a route calculation for a complex path with multiple obstacles.	The route is computed and displayed within a reasonable time frame (target: under 3 seconds).	NFR-2.2
UAC-14.4	Multiple concurrent users browse the map and request routes simultaneously.	Response times do not degrade significantly under concurrent load.	NFR-2.3
UAC-14.5	All data transmitted between client and server is inspected.	All communication occurs over HTTPS (encrypted connections).	NFR-5.2
UAC-14.6	A user submits a report; the server crashes immediately after.	Upon recovery, the report is present in the database and not lost.	NFR-3.1, NFR-3.4
UAC-14.7	A screen reader user navigates the map interface and submits a report.	All interactive elements are accessible via screen reader; WCAG 2.1 Level AA compliance is met.	NFR-4.1, NFR-4.3
UAC-14.8	The application is used on both a desktop and a mobile screen.	The UI is responsive and fully usable on both form factors.	NFR-4.2
UAC-14.9	A first-time user with no prior training attempts to submit a report.	The user can complete the full reporting flow without external guidance.	NFR-4.4
UAC-14.10	A user submits a report. Their identity is checked from the perspective of other users viewing the report.	No personally identifiable information (full name, email) is exposed to other users.	NFR-6.2
UAC-14.11	The application requests device location access.	An explicit permission dialog is shown to the user before any location data is accessed.	NFR-6.1

---

3. Requirements Traceability Matrix (Summary)

The table below maps each SRS requirement section to the test scenarios that cover it.

SRS Section	Description	Covered By
1.1.1	Registration & Authentication	Scenarios 1, 2
1.1.2	Profile & Accessibility Preferences	Scenarios 3, 6
1.1.3	Map Interaction & Discovery	Scenarios 1, 4
1.1.4	Route Planning	Scenarios 5, 6
1.1.5	Obstacle Reporting	Scenario 7
1.1.6	Verification & Community Moderation	Scenarios 8, 11
1.1.7	Infrastructure Authority Operations	Scenario 10
1.1.8	Administrator Operations	Scenario 12
1.2.1	General Visualization & UI	Scenario 4
1.2.2	Routing Engine Logic	Scenarios 5, 6
1.2.3	Report Lifecycle & State Management	Scenarios 7, 8
1.2.4	Resolution & Validation Workflow	Scenarios 10, 11
1.2.5	Trust & Gamification System	Scenario 9
1.2.6	Data Moderation & Alerts	Scenarios 12, 13
NFR 1–8	Non-Functional Requirements	Scenario 14