Lab 9 Report - bounswe/bounswe2026group9 GitHub Wiki
Requirements Review
Where We Stand
Implemented and stable:
- All core FRU/FRS for event creation, lifecycle, visibility, comments, ratings, bookmarks, going, capacity, host profiles, notifications, multi-location storage, equipment, categories, past events, guest access control, auth/roles.
- FRS-4 discovery is now feature-complete on the backend (advanced filters, distance ranking, custom time windows, accessibility filtering, default-area persistence) on the
feat/advanced-discovery-filtersbranch. - NFR-03 (HTTPS), NFR-04 (private-event backend enforcement), NFR-08 (mobile-friendly), NFR-09 (no GPS persistence) are met.
Partial:
- FRS-8.2 ordered itinerary segments (#149 open).
- Discovery UI consumption on web (#156) and mobile (#159) — backend ready, clients in progress.
- NFR-01, NFR-05, NFR-06, NFR-07 — implemented but not yet measured/verified at scale.
Suspended (out of final scope, will be documented):
- FRS-9.1/9.2 reporting and admin tooling.
- Automated CI testing on web/Android.
- AI voice agent.
- Nice-to-haves: online meeting events (FRU-1.1.2.1), P2P messaging (FRU-3.1.2.2).
What We'll Cover for Final Delivery
Backend
- Merge advanced discovery filters → closes FRS-4 entirely.
- Itinerary segments (#149) → closes FRS-8.2.
- Backend hardening (#152): structured logging + request timing → satisfies NFR-05, NFR-07.
- E2E + performance suite (#153): 10K-event seed, golden-path scenarios, load test → verifies NFR-01, NFR-06.
- QR code attendance (#232) and detailed post-event review (#235).
- Three new committee features: notification-based recommendations, similar-events endpoint, suggested filter on Discovery.
Clients
- Web/mobile consumption of discovery filters, multi-location route mapper, QR code, review section, clickable profiles.
- Standards conformance issues (#243–#249, #251, #254): WCAG, JSON-LD, OpenAPI, RFC 3339, GeoJSON.
Out of scope (documented as scope cut): reporting, admin, automated web/Android CI, voice agent, online meetings, P2P messaging.
Plan for Unimplemented Requirements
| Gap | Plan |
|---|---|
| FRS-8.2 itinerary | Lock backend contract this week, hand to UI teams. |
| NFR-01 / NFR-06 | Seed 10K events, run query benchmark in #153; tune indexes if >2s. |
| NFR-05 / NFR-07 | Add structured logging middleware in #152; track 5xx rate. |
| New 3 features | Backend-light (1 endpoint each), ship in week 2; UI in week 3. |
| Suspended items | Justify in final report rather than implement. |
Sequencing: Week 1 — merge discovery PR, start hardening, open issues for new features. Week 2 — itinerary, QR, review, recommendations/similar/suggested. Week 3 — E2E + perf verification, freeze.
Acceptance Testing Strategy
Data Strategy
Example Acceptance Tests
AT01 - Battal
| Field | Description |
|---|---|
| Test Case ID | TC-ACC-DISC-MOB-01 |
| Title | Mobile Advanced Discovery Filtering |
| Priority | High |
| Related Requirements | FRU-2 / FRS-4, NFR-01, NFR-08 |
| Preconditions | The mobile app is installed and connected to the deployed backend. The user is logged in as a Registered User. The test database contains events with different categories, locations, dates, and accessibility values. |
| Test Data | Category: Music; Date: Today; Radius: 5 km; Accessibility: Wheelchair accessible; User location: seeded test location; Dataset: normal dataset or 10,000-event dataset for performance verification. |
| Test Steps | 1. Open the mobile application. 2. Log in as a registered user. 3. Navigate to the Discovery screen. 4. Apply category filter: Music. 5. Apply date filter: Today. 6. Apply distance radius: 5 km. 7. Enable wheelchair accessibility filter. 8. Submit the search/filter request. 9. Observe the returned event list and ordering. |
| Expected Result | The system displays only events matching all selected filters. Events outside the selected radius, category, time window, or accessibility condition are not shown. Results are ordered according to distance/ranking rules. The mobile UI remains usable and responsive. Search results are returned within 2 seconds when tested against the required dataset. |
| Actual Result | To be filled during execution. |
| Status | To be filled as Pass/Fail. |
| Defect ID | To be filled if the test fails. |
| Notes | This test validates mobile consumption of the advanced discovery backend and should be included in regression after discovery-related changes. |
AT02 - Can Emir
| Field | Description |
|---|---|
| Test Case ID | TC-ACC-DISCOVERY-01 |
| Title | Wheelchair user discovers a nearby event today, bookmarks it, and is notified when it changes |
| Priority | Critical |
| Related Requirements | FRU-2.1, FRU-2.1.1, FRU-3.1.1, FRU-4.1, FRS-3.1.3, FRS-4.2.1, FRS-4.2.2, FRS-4.3.2, FRS-4.3.3, FRS-5.1, FRS-7.1, FRS-7.2, FRS-10.1, FRS-10.3, NFR-01, NFR-03, NFR-04, NFR-06 |
| Preconditions | Production backend and web/mobile clients deployed over HTTPS. Database seeded with ≥ 10,000 published events. One target public event "Inclusive Jazz Night" exists today near Boğaziçi University with wheelchair_access = true. One private event exists hosted by a different user. Test account "Aylin" registered, signed out, and with no existing bookmarks. |
| Test Data | Filters: quick_filter = today, wheelchair_access = true, radius_km = 5. GPS: (41.0855, 29.0510). Aylin credentials. Private event ID for backend probe. |
| Test Steps | 1. As guest on the mobile app, tap any event card on the discovery list. 2. Sign in as Aylin and apply quick_filter = today, wheelchair_access = true, radius_km = 5 from current GPS. 3. Open the first result ("Inclusive Jazz Night") and tap Bookmark. 4. Sign in to the web client with the same account and open the bookmarks list. 5. Have the host edit the event title. 6. Have the host cancel the event. 7. Using Aylin's token, send GET /events/{private_event_id} directly to the backend. 8. After the event's end_datetime passes, reopen the discovery list and the host's profile page. |
| Expected Result | 1. Guest is redirected to sign-in; no event detail is shown. 2. Response returns within 2 seconds; every result is today, wheelchair-accessible, and within 5 km; results are sorted by ascending distance; the target event appears first. 3. Bookmark is saved successfully. 4. The bookmark appears on the web client. 5. Aylin receives an in-app update notification within 60 seconds. 6. Aylin receives an in-app cancellation notification within 60 seconds. 7. Backend returns HTTP 403 or 404 with no private fields in the body; entire session uses HTTPS only. 8. The event no longer appears in default discovery results but is visible on the host's profile under "Past events". |
| Actual Result | (to be filled by tester at execution) |
| Status | (Pass / Fail — to be filled by tester) |
| Defect ID | (linked issue ID if failed) |
| Notes | Single end-to-end scenario covering four requirement families (discovery, access control, bookmark + notifications, archiving) and four NFRs (latency at scale, transport security, private-event enforcement, dataset size) in one user journey. Performed by the customer in the customer environment, matching the strategy's black-box, requirements-based, scenario-driven, end-to-end approach. Steps 1 and 7 are blocking on failure (security invariants); step 2 latency and steps 5–6 propagation time are negotiable within agreed tolerance per Section 12. |
AT03 - Mustafa
| Field | Description |
|---|---|
| Test Case ID | TC-ACC-EVT-MOB-03 |
| Title | Private Event Creation for Unregistered User |
| Priority | High |
| Related Requirements | Event Creation & User Authentication |
| Preconditions | The application is installed on the target Android device. The user "Ali Kaymaz" does not have an existing account in the database. The application is in a fresh state and not logged in. |
| Test Data | User Email: [email protected]; Password: BounRunner2024!; Title: Boğaziçi Running Club: Sprint Session; Description: A private fast-paced sprint for club members from Aşiyan to Karaköy; Start: Aşiyan; End: Karaköy; Visibility: Private; Category: Sports / Sprinting. |
| Test Steps | 1. Launch the application and select the “Create Event” button. 2. Select the “Sign Up” option and enter the test email, password, and contact visibility settings. 3. Sign in using the newly created credentials. 4. Open the sidebar menu and select the “Create Event” option. 5. Enter the Event Title, Description, Start Time, and Duration. 6. Upload an Event Image from the device gallery. 7. Enter "Bebek" as the start point and "Sarıyer" as the end point. 8. Select the "Sports/Sprint" category and toggle the visibility setting to "Private." 9. Click the button to finalize the event creation. |
| Expected Result | The system prevents access initially and requires sign-up. Account creation redirects to the Log In page. Authentication leads to the main interface. The form accepts all data and provides an image preview. The system calculates and displays the suggested route. Upon submission, a success message is displayed. The event status is marked as “Published,” and it is visible in "My Events" but not in public search. |
| Actual Result | To be filled during execution. |
| Status | To be filled as Pass/Fail. |
| Defect ID | To be filled if the test fails. |
| Notes | This test validates the full end-to-end flow from registration to private event publishing for a new student user. |
AT04 - İbrahim Fırat Yoğurtçu
| Field | Description |
|---|---|
| Test Case ID | TC-ACC-EVENT-CAPACITY-01 |
| Title | Capacity Enforcement Blocks New "Going" When Event Is Full |
| Priority | Critical |
| Related Requirements | FRU-3 / FRS-5, FRS-6, NFR-04 |
| Preconditions | The web frontend is deployed and connected to the deployed backend over HTTPS. A host account has created and published a public event İstanbul Sahil Koşusu — Sabah Seansı (Sports, 2026-05-15 07:00, Caddebostan Sahil) with attendeeLimit = 2. One seeded registered user is already in the Going list, so goingCount = 1. Two additional registered users (User A and User B) exist, are verified, are not 18+ restricted, and are not yet in the Going list. |
| Test Data | Event title: İstanbul Sahil Koşusu — Sabah Seansı; Capacity: 2; Initial goingCount: 1; User A: [email protected] / User_A_Pass!23; User B: [email protected] / User_B_Pass!23. |
| Test Steps | 1. Open the web application and log in as User A. 2. Navigate to the event detail page for the seeded event. 3. Click the Going button while the capacity indicator shows 1 / 2. 4. Observe the updated event detail UI (capacity indicator, status badge, CTA state). 5. Log out User A and log in as User B. 6. Open the same event detail page and inspect the Going button state. 7. Issue a direct POST /api/events/<id>/going request with User B's auth token, bypassing the disabled UI. 8. Reload the event detail page as User B and re-check the attendee list. 9. Log in as the host and open the host dashboard view of the event. |
| Expected Result | After Step 3 the Going button transitions to the active state and goingCount becomes 2 / 2. From Step 4 onward the UI shows a FULL / Sold Out status badge and the Going CTA is disabled with a clear "Event is full" message. In Step 7 the backend rejects the request with HTTP 409 Conflict (or 400) and an error body such as {"detail": "Event is full"}, and goingCount remains 2. In Step 8 User B is not present in the attendee list and no confirmation notification is delivered to User B. In Step 9 the host dashboard shows attendee count 2 / 2 containing only the seeded user and User A. Capacity is enforced consistently in both the UI and the backend. |
| Actual Result | To be filled during execution. |
| Status | To be filled as Pass/Fail. |
| Defect ID | To be filled if the test fails. |
| Notes | This test simultaneously validates UI-level enforcement (Steps 4, 6) and backend-level enforcement (Step 7), as the Acceptance Testing Strategy requires both layers to enforce capacity. Should be included in regression after any change to the Going / capacity / event-detail flows. Can be automated with Playwright for the UI steps and an authenticated request.post() for the API bypass step. |
AT05 - Faik İhsan Südüpak
| Field | Description |
|---|---|
| Test Case ID | TC-ACC-EVT-LIFECYCLE-05 |
| Title | Event Edit and Cancellation Lifecycle Enforcement |
| Priority | High |
| Related Requirements | FRU-1.1.3, FRU-1.1.3.1, FRU-1.1.3.2, FRS-2.3.1, FRS-2.3.2, FRS-2.3.3, FRS-2.3.4, FRS-1.2.2, NFR-02 |
| Preconditions | The web application is connected to the deployed backend over HTTPS. The host account is registered, signed in, and is the creator of two published public events: Event A "Bebek Sahil Yürüyüşü" starts in 24 hours, and Event B "Kadıköy Açık Mikrofon" started 30 minutes ago and is currently ongoing. A second registered user "Aylin" has bookmarked both events. The discovery seed contains additional unrelated events for context. |
| Test Data | Event A: future-start, fully editable; Event B: ongoing, time and location fields locked; Title change for Event A: "Bebek Sahil Yürüyüşü — Updated Time"; New start time attempted for Event B: +2 hours from current; Cancellation reason for Event A: "Venue unavailable due to weather". |
| Test Steps | 1. Log in as the host and open Event A's edit page. 2. Change Event A's title and save the change. 3. Reopen Event A's detail page and confirm the new title is visible. 4. Open Event B's edit page and attempt to change its start time and location. 5. Return to Event A and select Cancel Event from the host menu, confirming with the cancellation reason. 6. Log in as Aylin on a separate session, open the Discovery page, and search for events. 7. As Aylin, open the cancelled Event A's detail page directly via its URL. |
| Expected Result | In Step 2 the title update is saved successfully and a confirmation is shown. In Step 3 the new title appears on Event A's detail page. In Step 4 the start-time and location fields are read-only or the save is rejected with a clear "Cannot modify time or location after the event has started" message, while non-locked fields such as description remain editable. In Step 5 Event A transitions to the Cancelled state and the host receives a confirmation. In Step 6 Event A no longer appears in Aylin's discovery results within 60 seconds, while Event B and unrelated events still appear normally. In Step 7 Event A's detail page is still accessible and clearly displays a "Cancelled" label together with the cancellation reason. |
| Actual Result | To be filled during execution. |
| Status | To be filled as Pass/Fail. |
| Defect ID | To be filled if the test fails. |
| Notes | This test validates the host-side event lifecycle rules — specifically that pre-start edits are allowed, post-start time and location edits are blocked, and cancellation removes the event from discovery within the NFR-02 propagation window while keeping the detail page accessible with a clear cancellation label so previously interested users can still see the final status. |
AT06 - Muhittin Köybaşı
| Field | Value |
|---|---|
| Test Case ID | TC-WEB-ACC-06 |
| Title | Suggested Discovery Filter Based on Previous Attendance |
| Priority | High |
| Related Requirements | FRS-4, FRS-7, Committee Feature: Suggested Discovery Filter |
| Preconditions | L3 scenario seed is loaded. The seeded user has previous attendance history in one interest cluster. Future events from multiple categories exist. User is not logged in at the start of the test. |
| Test Data | Seeded user: [email protected]. Attendance history: sports-related events. Dataset: 10,000 seeded events with sport, music, tech, and food clusters. |
| Test Steps | 1. Open the web application.2. Log in as [email protected].3. Navigate to the Discovery page.4. Open the filter panel.5. Select the Suggested filter.6. Apply the filter.7. Observe the first page of discovery results.8. Open the first suggested event detail page. |
| Expected Result | The Discovery page displays suggested events based on the user’s previous attendance history. Sports-related events are prioritized over unrelated categories. The first suggested event detail page opens successfully. Private, cancelled, ended, or unauthorized events are not exposed in the suggested results. |
| Actual Result | To be filled during execution |
| Status | Pass/Fail |
| Defect ID | To be filled if failed |
| Notes | This test is executed with Playwright using the L3 scenario seed. Screenshot and trace are attached as evidence in the Playwright report. |
Individual Contributions
Battal Hazar
- Created acceptance test example TC-ACC-DISC-MOB-01.
- Rewieved Requirements Review and Acceptance Test Strategy pages.
Can Emir Bora
- Created Lab Report 9 Page on wiki sidebar
- Wrote Requirements Review and put it on Lab Report 9
- Reviewed Data Strategy and Acceptance Testing Strategy Pages
- Created acceptance test example TC-ACC-DISCOVERY-01 / AT02.
Faik İhsan Südüpak
- Created acceptance test example TC-ACC-EVT-LIFECYCLE-05 (AT05) covering host-side event edit and cancellation lifecycle rules — pre-start edit allowed, post-start time/location lock, and discovery removal within the NFR-02 window while the detail page remains accessible with a "Cancelled" label.
- Fully completed issue 149 and pr 265 opened ci passed
İbrahim Fırat Yoğurtçu
- Opened issue #267 for the Data Strategy deliverable.
- Defined the project's data strategy and authored the Data Strategy wiki page. #267
- Created acceptance test example TC-ACC-EVENT-CAPACITY-01 covering capacity enforcement on the Going action (UI FULL badge + disabled CTA, plus backend 409 on direct API bypass), traced to FRU-3 / FRS-5 / FRS-6 / NFR-04.
Muhittin Köybaşı
- Defined the project's Acceptance Testing Strategy and authored the related wiki page. #266
- Reviewed the Requirement's Review part and Data Strategy. #267
- Created acceptance test example TC-WEB-ACC-06 / AT06.
Mustafa Koyuncu
- Created acceptance test example: TC-ACC-EVT-MOB-03