Skip to content

Report 9 ‐ Requirements Review & Acceptance Testing

Jump to bottom
UlasSertan edited this page Apr 30, 2026 · 19 revisions

Lab 9 Report

Requirements Review

Status Legend

Symbol Meaning
✅ Done Fully implemented and working
🟡 Partial Code exists but incomplete or in mock mode
🔜 Issue opened Not yet implemented; issue created, targeting final delivery

Current Status Assessment

1.1.1 Registration & Authentication

ID Requirement Status Notes
1.1.1.1 Guest can browse the map without an account 🟡 Partial MapView internally supports guest mode (guest preferences overlay exists), but _layout.tsx redirects unauthenticated users to /auth/login before they reach the map. The routing gate needs to be lifted.
1.1.1.2 Guest can view existing obstacle pins 🟡 Partial Same root cause as 1.1.1.1 — obstacle fetching and rendering is implemented but unreachable for guests.
1.1.1.3 Register with email, full name, and birth date ✅ Done Fully implemented in app/auth/register.tsx with field-level validation.
1.1.1.4 Secure password required on registration ✅ Done Minimum 8-character validation enforced on the frontend.
1.1.1.5 Login with email and password ✅ Done Fully implemented with token-based auth and secure storage.
1.1.1.6 Logout ✅ Done Logout button on the profile tab clears tokens.
1.1.1.7 Password reset via email 🔜 Issue opened forgot-password.tsx is currently a "Coming soon" stub. Issue created for final delivery.

1.1.2 Profile & Accessibility Preferences

ID Requirement Status Notes
1.1.2.1 Create a permanent Mobility Profile 🟡 Partial UI fully built (MobilityProfileCard), but the API integration is in mock mode (MOCK=true). Needs backend endpoint connection.
1.1.2.2 Select primary mobility aid type ✅ Done 7 aid types available (Wheelchair, Electric Wheelchair, Walker, Crutches, Stroller, Hand Cart, None).
1.1.2.3 Guest temporary routing preferences 🟡 Partial Guest preferences are implemented inside MapView but unreachable because guests are redirected to login. Resolving 1.1.1.1 unblocks this.
1.1.2.4 Save frequent destinations ("Home", "Work") 🔜 Issue opened Not implemented. Backend and frontend issues created for final delivery.
1.1.2.5 View earned badges on profile 🔜 Issue opened Marked as "future feature – milestone 2" in the codebase. Issue created to implement for final delivery.
1.1.2.6 Toggle system notifications on/off 🔜 Issue opened Requirements updated and clarified. Backend and frontend issues created.

1.1.3 Map Interaction & Discovery

ID Requirement Status Notes
1.1.3.1 Pan and browse the map freely ✅ Done Leaflet map fully interactive on both web and native.
1.1.3.2 Zoom in and out ✅ Done Standard Leaflet zoom controls.
1.1.3.3 Click obstacle marker to view details ✅ Done Navigates to report/[id].tsx with photo carousel and interaction bar.
1.1.3.4 View indoor obstacles at high zoom ✅ Done HIGH_DETAIL_ZOOM threshold implemented; indoor markers rendered with distinct "i" label.
1.1.3.5 Toggle passive reports visibility 🟡 Partial API accepts includePassive parameter; a UI toggle button is missing from the map interface. Issue created.
1.1.3.6 Search for location by text ✅ Done Nominatim autocomplete with debounced search.
1.1.3.7 Manually drop a pin on the map ✅ Done Pin drop mode implemented in MapView.

1.1.4 Route Planning

ID Requirement Status Notes
1.1.4.1 Manually select a starting point ✅ Done Supported via search, pin drop, or current location.
1.1.4.2 Manually select a destination point ✅ Done Same input methods as origin.
1.1.4.3 Request route calculation ✅ Done POST /api/routes/calculate called with user accessibility preferences.
1.1.4.4 View route as a static visual path ✅ Done Route rendered as a Polyline on the Leaflet map.
1.1.4.5 View textual summary (distance, time) 🔜 Issue opened API already returns distance, estimatedTime, and avoidedObstaclesCount. UI panel not yet implemented. Issue created for final delivery.

1.1.5 Obstacle Reporting

ID Requirement Status Notes
1.1.5.1 Initiate report at current GPS location ✅ Done Expo Location integration with permission request.
1.1.5.2 Categorize report as Outdoor or Indoor ✅ Done Two-tab context selector in ReportForm.
1.1.5.3 Select an obstacle category ✅ Done 6 outdoor + 5 indoor categories.
1.1.5.4 Upload at least one photograph ✅ Done PhotoPicker with camera/gallery support (up to 3 photos). Photo requirement is enforced.
1.1.5.5 Add a text description ✅ Done Description field present in ReportForm.

1.1.6 Verification & Community Moderation

ID Requirement Status Notes
1.1.6.1 Upvote (Confirm) a report ✅ Done InteractionBar with optimistic UI and server sync. Disabled for report owner.
1.1.6.2 Flag a report as inaccurate ✅ Done Same InteractionBar.
1.1.6.3 Propose resolution by uploading a "Resolved" photo 🔜 Issue opened ConfirmResolutionButton exists but only transitions status — no photo upload flow for resolution evidence. Issue created for final delivery.
1.1.6.4 View status timeline (Reported → Resolved → Validating → Confirmed) 🟡 Partial Status badge shown on report detail; a visual sequential timeline component is not implemented. Issue created for final delivery.

1.1.7 Infrastructure Authority Operations

ID Requirement Status Notes
1.1.7.1 Authority dashboard for issue management 🔜 Issue opened No dedicated authority view exists in the frontend. Issue created for final delivery.
1.1.7.2 Filter reports by status 🔜 Issue opened Depends on authority dashboard (1.1.7.1).
1.1.7.3 Mark issue as "Resolved – Awaiting Validation" 🔜 Issue opened Depends on authority dashboard (1.1.7.1).
1.1.7.4 Upload post-repair verification photo 🔜 Issue opened Depends on authority dashboard (1.1.7.1).
1.1.7.5 Append official repair notes 🔜 Issue opened Depends on authority dashboard (1.1.7.1).

1.1.8 Administrator Operations

ID Requirement Status Notes
1.1.8.1 View queue of flagged reports 🔜 Issue opened No admin panel in the frontend. Issue created for final delivery.
1.1.8.2 Permanently delete malicious reports 🔜 Issue opened Depends on admin panel (1.1.8.1).
1.1.8.3 Suspend or ban user accounts 🔜 Issue opened Depends on admin panel (1.1.8.1).

1.2 System Requirements (frontend-relevant)

ID Requirement Status Notes
1.2.1.1 Default map view: Boğaziçi University campus 🟡 Partial Map renders correctly but default center coordinates targeting Boğaziçi need verification. Issue created.
1.2.1.2 Render standard geographic base layers ✅ Done TileLayer active on both web and native.
1.2.1.3 Hide indoor markers below high-detail zoom threshold ✅ Done Implemented via HIGH_DETAIL_ZOOM constant.
1.2.1.4 Passive reports rendered with distinct semi-transparent style 🟡 Partial includePassive API param works; distinct visual styling for passive markers needs verification. Issue created.
1.2.3.1 New reports start with "Unverified" status 🟡 Known MVP deviation Intentional: reports currently start as VERIFIED for MVP testing. Will be reverted to UNVERIFIED before final delivery.
1.2.4 Resolution/Validation workflow with notification trigger 🟡 Partial ConfirmResolutionButton handles status transition; notification delivery not yet wired. Covered by 1.2.6 issues.
1.2.5 Trust Score displayed on profile 🟡 Partial Trust score badge visible on profile screen; backend scoring logic and badge thresholds tracked separately.
1.2.6.2–1.2.6.4 Async notifications on status changes + notification list endpoint 🔜 Issue opened Requirements updated and clarified. Backend and frontend issues created.

Non-Functional Requirements

ID Requirement Status Notes
NFR-1.1 Available as a web application ✅ Done Expo web build active.
NFR-1.2 Available as a mobile application ✅ Done iOS and Android via Expo.
NFR-2.1 Map renders without perceptible delay 🟡 Partial Leaflet with debounced obstacle fetching; not formally benchmarked.
NFR-2.2 Routes computed within a reasonable time frame 🟡 Partial Frontend displays results correctly; response time depends on backend routing engine performance.
NFR-2.3 Handles concurrent users without degradation 🟡 Partial Backend concern; frontend has no artificial bottlenecks.
NFR-4.1 WCAG 2.1 Level AA 🔜 Issue opened No explicit accessibility attributes or ARIA roles currently. Issue created for final delivery.
NFR-4.2 Usable on desktop and mobile screen sizes ✅ Done Web and native builds both functional.
NFR-4.3 Operable with screen readers 🔜 Issue opened No accessibility labels or semantic roles in components yet. Issue created for final delivery.
NFR-4.4 First-time user can submit a report without training ✅ Done ReportForm is self-guided with clear category selection and GPS auto-fill.
NFR-5.1 Authentication required before data modification ✅ Done Token check enforced on all mutation calls.
NFR-5.2 All data transmitted over encrypted connections ✅ Done Production backend on HTTPS (Render.com).
NFR-5.3 Role-based access control 🟡 Partial Citizen/guest separation implemented. Authority and Admin role UIs tracked under 1.1.7 and 1.1.8 issues.
NFR-6.1 Explicit user permission to access device location ✅ Done expo-location permission request before any GPS use.
NFR-6.2 No PII exposed for reporting users 🟡 Partial Reporter identity is not surfaced in the UI; full audit pending.
NFR-7.1 Works on all major modern browsers ✅ Done React/Expo web.
NFR-7.2 Supports current iOS and Android versions ✅ Done Expo managed workflow.

Requirements Covered for Final Delivery

The table below shows the delivery path for every item that is not yet fully implemented.

Immediate actions — unblock multiple requirements

Action Unlocks
Fix guest routing in _layout.tsx to allow unauthenticated map access 1.1.1.1, 1.1.1.2, 1.1.2.3
Disable mock mode in src/api/mobilityProfile.ts and connect to real endpoint 1.1.2.1
Revert report initial status from VERIFIED to UNVERIFIED 1.2.3.1

Acceptance Testing Strategy

1. Purpose

Acceptance testing answers the question: "Did we build the right thing?" It validates the system from the perspective of real users and stakeholders — confirming the platform meets their expectations as a whole, not just that individual components work in isolation. For the Neighborhood Accessibility Mapper, this is especially important because people with mobility challenges rely on the system for safe, real-world navigation.

2. User Roles Involved

Role Who Tests
Guest User Unregistered visitor — browses, views obstacles, plans routes
Registered User Community member — reports obstacles, upvotes, plans routes with mobility profile
Infrastructure Authority Municipal officer — reviews and resolves reported issues
Administrator System admin — manages flagged content and abusive accounts

Where possible, testers should be recruited users (e.g., students with mobility needs at Boğaziçi University campus) rather than developers, to avoid bias.

3. Acceptance Criteria

The system is accepted when actual behavior matches expected behavior across all critical and high-priority scenarios. Failures are classified as:

  • Critical: System crash, data loss, route failures, incorrect lifecycle transitions — must be fixed before release.
  • High: Missing features, wrong notifications, incorrect role behavior — should be fixed before release.
  • Medium/Low: Minor UI inconsistencies — can be patched post-release.

4. Acceptance Test Scenarios

Each scenario is end-to-end and framed from a user's perspective. The goal is to verify the system works as a whole for its intended users.

Scenario A1 — Disabled User Plans an Accessible Route on Campus

A wheelchair user opens the app, sets "Wheelchair" as their mobility aid, selects a start and destination on Boğaziçi University South Campus, and requests a route. The system generates a static visual path (Blueprint) that avoids stairs, steep slopes, and all confirmed obstacles. The user follows the route using the displayed distance and street summary. Indoor obstacles along the way do not affect the route.

Validates: SRS 1.1.2, 1.1.4, 1.2.2

Scenario A2 — Volunteer Reports a Broken Ramp and the Community Confirms It

A registered user spots a broken ramp near the library entrance. They open the app, initiate a report at their GPS location, select "Outdoor" and "Broken Ramp", upload a photo, and submit. A temporary warning marker appears on the map. Other users passing by upvote the report. Once the Verification Threshold is met, the report transitions to "Confirmed Obstacle", the original reporter receives a notification, and the ramp is now avoided in route calculations.

Validates: SRS 1.1.5, 1.1.6, 1.2.3, 1.2.5, 1.2.6

Scenario A3 — Municipality Officer Resolves a Reported Issue

An Infrastructure Authority user logs into the dashboard, filters for "Open" issues, and finds a confirmed broken ramp report. They perform the real-world repair, then upload a post-repair photo and mark the issue as "Resolved – Awaiting Validation." The reporter and all upvoters receive notifications. The warning marker remains on the map until enough citizens submit "Confirm Resolution" votes, after which the issue is closed and the marker is removed.

Validates: SRS 1.1.7, 1.2.4

Scenario A4 — Guest User Browses Without an Account

A visitor opens the platform without registering. They can pan and zoom the map around campus, view obstacle pins and their details, and request a route with a temporary "Avoid Stairs" preference. They cannot submit a report. Their preference is not saved after the session ends.

Validates: SRS 1.1.1.1, 1.1.3, 1.1.4, 1.1.2.3

Scenario A5 — Administrator Handles a Malicious Report

A community member flags a report as fake. The Admin reviews the flagged queue, determines the report is indeed malicious, deletes it permanently from the database, and suspends the submitting user's account. The marker disappears from the map and the user can no longer log in.

Validates: SRS 1.1.8

5. Acceptance Testing Process

  1. Define Acceptance Criteria — Derived from the SRS (done above).
  2. Plan Acceptance Testing — Schedule sessions, assign tester roles, prepare the deployed test environment.
  3. Derive Acceptance Tests — The scenarios above; each maps to SRS requirement IDs.
  4. Run Acceptance Tests — Execute in the target environment (deployed app + physical mobile devices on or near Boğaziçi University campus).
  5. Negotiate Test Results — Log defects with severity; team and stakeholders agree on what must be fixed before release.
  6. Reject / Accept System — System is accepted if all Critical and High scenarios pass; Medium/Low issues are scheduled for a patch.

6. Test Environment

  • Web: Deployed application (not localhost), tested on Chrome, Firefox, Safari, and Edge.
  • Mobile: Physical iOS and Android devices (current and recent OS versions).
  • Accounts: Pre-configured test accounts for each role (Guest, Registered User, Trusted Contributor, Infrastructure Authority, Admin).
  • Location: Real GPS coordinates on/near Boğaziçi University campus (MVP scope), or mocked coordinates for controlled testing.

Data Strategy

Test Data Accumulation Strategy

The test data strategy is layered across three sources, each serving a different testing need:

Pre-Seeded Synthetic Data (Primary)

Before running tests, a team member will manually populate the database with a representative set of users, reports, and obstacles to ensure the necessary pre-conditions are in place. This includes accounts covering all defined roles and reports spanning all obstacle categories and lifecycle states.

For data that does not depend on real-world photos — such as user accounts with varying Trust Score values or reports already in a specific lifecycle state — it may be feasible to generate these programmatically to save time. However, for obstacle reports specifically, since the system requires at least one real photograph as evidence, a fully automated approach is unlikely to be practical. In that case, team members will manually submit a set of representative reports through the app using real photos taken in the field, and these will serve as the baseline test dataset.

Live Data from Dev Team Contributions

During the weeks before the final milestone demo, all team members will actively use the deployed app to submit real obstacle reports using their own devices and GPS locations across a wider area. This produces organic, realistic data that reflects actual usage patterns — including varied photo quality, real GPS coordinate precision drift, and natural obstacle distribution across different urban environments.

Automated Test Fixtures

For the automated backend test suite, each test module creates its own isolated fixtures using framework-level scoping. This prevents test interference and ensures tests remain fully independent of one another.

Synthetic vs. Existing Datasets

Synthetic data is the primary approach because accessibility obstacle data, by definition, must be crowdsourced and cannot be sourced from a pre-existing dataset. The routing engine uses OpenStreetMap data for the street network, which is the one real-world dataset incorporated directly. All obstacle, user, and interaction data is generated specifically for the test environment to guarantee coverage of edge cases and lifecycle states that may not appear organically in a short testing window.

To test the community verification and Trust Score flows, team members will manually log in as separate test user accounts and upvote reports one by one until the verification threshold is reached. This manual approach ensures the behavior of the system is observed as a real user would experience it. For simpler data attributes — such as pre-assigning a user a specific reputation score — direct database edits or a helper script may be used to set up the required state without going through the full interaction flow each time.

Test Data Validation Methodologies

The following methods are used to validate that test data reflects realistic usage scenarios:

  • Coordinate validation: All seeded obstacle coordinates are manually verified against satellite imagery to ensure they fall on actual pathways, ramps, or building entrances rather than in the middle of buildings or off-road areas.
  • Category and role completeness: Every defined obstacle category and every user role must have at least one representative entry in the seed dataset. Tests that depend on a specific category or role will fail at setup rather than silently pass on missing data.
  • Lifecycle state coverage: At least one report exists in every lifecycle state so that tests exercising state transitions always have a valid pre-condition.
  • Photo fixture authenticity: Test photos are real photographs rather than placeholder images, ensuring the photo upload and storage pipeline tests exercise realistic file sizes and MIME types.
  • Geographic distribution check: Seeded obstacle coordinates are reviewed to confirm they are spread across different sub-areas of the test region, avoiding artificial clustering that would not reflect real-world usage.

Example Acceptance Tests

Each test below follows the structured test document format introduced in the lecture (Test Case ID, Module, Designed By, Priority, Pre/Post-conditions, Test Data, Steps, Expected Result, Status), combined with a Given / When / Then narrative for readability. Tests are traceable to specific SRS requirements and cover both happy paths (✅) and edge cases (⚠️).

ET-01 — Successful User Registration ✅

Test Case ID: TC_AT_01 | Module: Authentication / Registration | Designed By: Ali Akkaya | Date Designed: 2026-04-30 | Priority: High | Type: Happy Path | Requirement: SRS 1.1.1.3, 1.1.1.4 | Automated: No | Dependencies: None

Description: Verify that a new visitor can successfully register with valid credentials and is redirected to the map view.

Pre-condition: The visitor has no existing account and is on the registration page; the registration service is available.

Test Data: Full name Ali Test, email ali.test@boun.edu.tr, birth date 2000-05-15, password Secure#2026
Given A visitor has no existing account and is on the registration page
When They enter the test data above and click "Register"
Then The account is created, the user is redirected to the map view, and a success confirmation is displayed

Expected Result: User is redirected to the map and can immediately log in with the registered credentials. Post-condition: A new user record exists in the database; the user has an active session. Pass / Fail Conditions: Pass if redirected to map and login works; fail if an error is shown, the account is not created, or the user is not redirected.

ET-02 — Obstacle Report Blocked Without Photo ⚠️

Test Case ID: TC_AT_02 | Module: Obstacle Reporting | Designed By: Bora Aydemir | Date Designed: 2026-04-30 | Priority: High | Type: Edge Case | Requirement: SRS 1.1.5.4 | Automated: No | Dependencies: TC_AT_01 (user must be registered)

Description: Verify that the obstacle reporting form rejects submissions without a photo and shows an informative error message.

Pre-condition: A registered user is logged in and has the obstacle reporting form open with GPS location set.

Test Data: Category = Broken Ramp; Description = provided; Photo = (none uploaded)
Given A registered user is logged in and has the obstacle reporting form open with GPS location set
When They fill in category Broken Ramp, add a description, but submit the form without uploading any photo
Then The submission is rejected and an error message is shown: "At least one photo is required"

Expected Result: Form does not submit; error message is clearly displayed. Post-condition: No new obstacle report exists in the database; the form remains open with entered data preserved. Pass / Fail Conditions: Pass if the report is not created and the error is shown; fail if the report is created without a photo, or no error feedback is given.

ET-03 — Route Avoids a Confirmed Obstacle ✅

Test Case ID: TC_AT_03 | Module: Routing Engine | Designed By: Ömer Belemir Delier | Date Designed: 2026-04-30 | Priority: High | Type: Happy Path | Requirement: SRS 1.2.2.1, 1.2.3.3 | Automated: No | Dependencies: A confirmed obstacle exists in the routing graph

Description: Verify that routing for a Wheelchair mobility profile bypasses confirmed obstacles on the direct path.

Pre-condition: A confirmed obstacle exists on the direct path between South Gate and Kennedy Lodge; the user is logged in with a Wheelchair mobility profile selected.

Test Data: Origin = South Gate; Destination = Kennedy Lodge; Mobility profile = Wheelchair
Given A confirmed obstacle exists on the direct path between South Gate and Kennedy Lodge, and the user has a Wheelchair mobility profile
When The user requests a route from South Gate to Kennedy Lodge
Then The returned route does not pass through the blocked segment and provides an accessible alternative path

Expected Result: Route visibly bypasses the obstacle segment; no stairs or blocked paths are included. Post-condition: The routing engine returns a valid alternative path; no state changes to the obstacle data. Pass / Fail Conditions: Pass if the alternative route excludes the obstacle and is wheelchair-accessible; fail if the route passes through the confirmed obstacle, or no alternative is returned.

ET-04 — Trust Score Increments After Report Is Verified ✅

Test Case ID: TC_AT_04 | Module: Reputation / Verification | Designed By: Arif Evren | Date Designed: 2026-04-30 | Priority: Medium | Type: Happy Path | Requirement: SRS 1.2.5.2 | Automated: No | Dependencies: Three additional registered users available for upvoting

Description: Verify that a report transitions to "Confirmed Obstacle" once the verification threshold is reached, the reporter's Trust Score increases, and a notification is sent.

Pre-condition: User arif.test@boun.edu.tr has Trust Score = 0 and one report in "Unverified" status; the Verification Threshold is 3; three other registered users are available.

Test Data: Reporter = arif.test@boun.edu.tr; Initial Trust Score = 0; Threshold = 3; Upvoters = three distinct registered users
Given User arif.test@boun.edu.tr has a Trust Score of 0 and one report in "Unverified" status; the Verification Threshold is 3
When Three other registered users each upvote the report
Then The report transitions to "Confirmed Obstacle", Arif's Trust Score increases by 1, and a push notification is sent to Arif

Expected Result: Trust Score = 1, report status = "Confirmed Obstacle", notification delivered. Post-condition: Report status is permanently updated; Trust Score change is persisted; notification is logged in the system. Pass / Fail Conditions: Pass if all three changes occur (status, score, notification); fail if score stays at 0, status does not change, or notification is not sent.

ET-05 — Resolve Issue Without Photo Is Blocked ⚠️

Test Case ID: TC_AT_05 | Module: Authority Dashboard | Designed By: Ulaş Sertan Kemeç | Date Designed: 2026-04-30 | Priority: High | Type: Edge Case | Requirement: SRS 1.1.7.4 | Automated: No | Dependencies: A verified obstacle report exists in the dashboard

Description: Verify that an Infrastructure Authority cannot mark an issue as resolved without uploading a post-repair photo.

Pre-condition: An Infrastructure Authority user is logged in; a verified obstacle report is open in the dashboard.

Test Data: User role = Infrastructure Authority; Action = Mark as Resolved; Post-repair photo = (none uploaded)
Given An Infrastructure Authority user is logged in and a verified obstacle report is open in the dashboard
When The user clicks "Mark as Resolved" and attempts to confirm the status change without uploading a post-repair photo
Then The status change is blocked and a warning is displayed: "A post-repair photo is required to mark this issue as resolved"

Expected Result: Issue status remains unchanged; warning message is shown. Post-condition: Report status remains "Verified"; no resolution record is created. Pass / Fail Conditions: Pass if the status change is blocked and the warning is shown; fail if the issue is marked as resolved without a photo being attached.

ET-06 — Passive Report Is Not Treated as an Obstacle in Routing ⚠️

Test Case ID: TC_AT_06 | Module: Routing Engine | Designed By: Ekin Kılıç | Date Designed: 2026-04-30 | Priority: Medium | Type: Edge Case | Requirement: SRS 1.2.2.3, 1.2.3.2 | Automated: No | Dependencies: A report has aged into "Passive" status

Description: Verify that reports in "Passive" status are excluded from the routing graph and do not affect shortest-path calculations.

Pre-condition: A report on a path segment has transitioned to "Passive" status (no interactions within the inactivity period); the segment lies on the shortest route between North Campus Entrance and the Rectorate Building.

Test Data: Origin = North Campus Entrance; Destination = Rectorate Building; Segment status = Passive
Given A report on a path segment has transitioned to "Passive" status, and it lies on the shortest route between North Campus Entrance and the Rectorate Building
When A user requests a route between those two points
Then The route uses the shortest path through the passive-report segment, since passive reports are excluded from the routing graph

Expected Result: Route passes through the segment; passive report is not treated as a blockage. Post-condition: No state change to the passive report; the routing engine returns the shortest valid path. Pass / Fail Conditions: Pass if the route uses the segment and is the shortest path; fail if the route unnecessarily avoids the segment as if the passive report were an active obstacle.

ET-07 — Suspended User Cannot Log In ⚠️

Test Case ID: TC_AT_07 | Module: Authentication / Admin | Designed By: Baran Önder | Date Designed: 2026-04-30 | Priority: High | Type: Edge Case | Requirement: SRS 1.1.8.3 | Automated: No | Dependencies: Admin has previously suspended the target account

Description: Verify that a suspended user is denied login and shown an informative suspension message.

Pre-condition: An Admin has suspended the account spammer@test.com via the admin panel; the account credentials remain valid.

Test Data: Email = spammer@test.com; Password = (valid suspended credentials); Account status = Suspended
Given An Admin has suspended the account spammer@test.com via the admin panel
When The suspended user attempts to log in with their valid email and password
Then Login is denied and a message is displayed: "Your account has been suspended"

Expected Result: Login fails with an informative suspension message; user cannot access any features. Post-condition: No session is created for the suspended account; the failed attempt may be logged for audit. Pass / Fail Conditions: Pass if login is denied and the suspension message is shown; fail if the suspended user is able to log in, or the error message is absent or misleading.

Individual Contributions

Bora Aydemir

  • Helped organize the Lab 9 documentation by opening the Wiki page and the main report issue #197
  • Contributed to writing the Data Strategy section of the Lab 9 Report #205
  • Drafted an example acceptance test for the Acceptance Testing section #206

Ekin Kılıç

  • Requirements Review — I wrote the requirements review section for the milestone. I went through our original requirements together with the issue list we opened for this phase, decided which ones we will realistically cover for the final delivery (authority role, upvote/flag, trust score and badges, spam moderation, passive reports, suspend/ban), and noted the ones we are scoping down (real push delivery, full indoor routing).

  • Example Acceptance Test — I wrote an acceptance test (ET-06) covering the passive report behavior in the routing engine. It checks that a route between two campus points still uses the shortest path even when a passive report sits on that segment, confirming that passive reports are excluded from route calculations as specified in the SRS.

Arif Evren

  • Example Acceptance Test — I wrote an acceptance test (ET-04) covering the trust score behavior after a report is verified by the community. It checks that when three registered users upvote an unverified report, the reporter's Trust Score increments by 1 and the report transitions to "Confirmed Obstacle" status, confirming the gamification logic specified in SRS 1.2.5.2. #206

  • Acceptance Testing Strategy — I wrote the acceptance testing strategy section for the lab. I defined the acceptance criteria, identified the relevant user roles for testing, and derived five end-to-end acceptance test scenarios covering the core user journeys of the platform — including accessible route planning, obstacle reporting and community verification, municipality resolution workflow, guest user access, and admin moderation. Each scenario was traced back to the corresponding SRS requirements. #202

  • Requirements Review — I participated in the requirements review discussion, collaborating with the team to align on which requirements are in scope for the final delivery.

Ömer Belemir Delier

  • Data Strategy — Together with Bora Aydemir, I wrote the data strategy section. I outlined our approach to test data accumulation, discussed the trade-offs around manual versus programmatic data generation, and defined the validation methodologies to ensure test data reflects realistic usage scenarios.

Ali Akkaya

  • Backend Implementation — I implemented #196 (PR #203), adding
    reporterId, userUpvoted, and userFlagged to GET /api/map/obstacles/{id}/ so the obstacle detail UI can disable upvote/flag on own reports and
    restore already-upvoted state. Includes select_related("reporter") to avoid an N+1 and five new tests.
  • Code Review — I reviewed PR #144 (Mobility Profile endpoint) as the assigned reviewer and flagged URL namespace placement, field-name drift
    with the existing register flow, a race condition in the POST duplicate-check (500 instead of 409), and the matching frontend path
    update.
  • Deployment Fixes — I landed production deploy fixes on deploy/production (commit ab870e4): --legacy-peer-deps for the frontend Docker build,
    dynamic PORT for Railway, and removal of a duplicate users URL namespace causing routing collisions.

Baran Önder

  • Reviewed all functional and non-functional requirements individually, identified missing, incorrect, and ambiguous entries, and applied the necessary corrections and clarifications.

  • Identified untracked requirements with no corresponding issues and opened the missing GitHub issues to ensure full coverage before final delivery.

  • Wrote the Requirements Review section of the lab report, covering the current implementation status of all requirements, the final delivery commitment, and the plan to address every remaining gap.

Ulaş Sertan Kemeç

  • Reviewed all functional and non-functional requirements individually, identified missing, incorrect, and ambiguous entries, and applied the necessary corrections and clarifications.

  • Identified untracked requirements with no corresponding issues and opened the missing GitHub issues to ensure full coverage before final delivery.

  • Wrote the Requirements Review section of the lab report, covering the current implementation status of all requirements, the final delivery commitment, and the plan to address every remaining gap.

Project

Team Members

Lab Reports

Weekly Meetings

Scenarios and Mock ups

Use Case Diagrams

Class Diagram

Sequence Diagrams

Milestone Review

Clone this wiki locally