Our project has successfully established its core foundation across the Backend, Web Frontend, and Mobile platforms. While the MVP focused on essential CRUD operations and basic event listing, we are now expanding the system to meet the comprehensive set of requirements defined for the final delivery.

• Core Systems: Authentication, user profile management, and basic event creation (Public/Protected) are fully operational.
• Discovery: Text-based search and distance filtering are active.
• Participation: Basic join request and approval flows are functional on both web and mobile.
• Infrastructure: The backend API is mature, supporting most business logic, while the mobile and web clients are synchronized for core event lifecycles.

The final delivery will introduce a wide array of advanced features that transition the platform from a basic event tool to a comprehensive social event management ecosystem:

• Map Integration: Full Map View integration on the Discovery pages (Mobile & Web) and mini-maps within Event Details with direct links to Google/Apple Maps for navigation.
• Smart Filtering: Discovery results will automatically filter events based on the user's age and gender restrictions. Advanced filters (e.g., child-friendly events) will also be added.
• Location Enhancements: Switching to a more robust location search provider, implementing Route Location support, and showing approximate locations for Protected events.

• Digital Ticketing & QR: A complete end-to-end ticketing flow, including ticket generation and a mobile QR scanning mechanism for secure event entry.
• Private & Invited Events: Implementation of the PRIVATE privacy level, supported by a full Invitation system.
• Join Request Enhancements: Ability to cancel join requests and support for attaching proof (Images/PDFs) to requests to satisfy specific event constraints.
• Reporting & Moderation: A reporting system for events and a dedicated Admin Panel to manage reported content and platform safety.

• Event Discussions: A two-phase discussion section (Pre-event Q&A and Post-event Comments) allowing reviews to be enriched with event photos.
• Enhanced Profiles: Publicly viewable profiles featuring a "blog-like" section for equipment and photo galleries, plus achievement badges.
• Notifications: Full implementation of In-app and Push notifications with user-controllable toggles for event updates and invitations.
• UI/UX Improvements: Dark Mode support, multi-language support (EN/TR), in-app SMS verification, and event draft support so users can save progress during creation.

• Monitoring & Validation: Integration with Sentry for real-time monitoring and implementation of missing constraint validations on the backend.
• Event Lifecycle: Implementation of event versioning (info change history), event deletion rules, and a reconfirmation flow for participants.

To ensure the successful delivery of these extensive features, our team is following a prioritized roadmap:

1. Entry & Privacy (High Priority): We are prioritizing the Ticketing/QR system and the Invitation logic for Private events as these are critical for the platform's unique value proposition.
2. Visual Discovery (Medium Priority): Map integrations and advanced filtering are being developed in parallel to enhance the core search experience.
3. Social & Polish (Ongoing): Discussion sections, profile enhancements, and Dark Mode are being integrated as we refine the frontend and mobile UI components.
4. Backend Hardening: Final constraint validations and monitoring setups are being scheduled for the final integration phase to ensure system stability.

Each acceptance test follows a structured format with a unique ID (TC__), title, priority, module name,
pre-conditions, ordered test steps with input data, expected result, actual result, post-condition, and a linked
requirement ID.

We use black-box, requirements-based acceptance testing. Tests are derived directly from functional requirements and executed manually on the shared dev server with synthetic test data. The goal is validation — confirming that the
system behaves correctly from the user's perspective.

1. Define acceptance criteria
2. Assign tests to team members by area of contribution
3. Derive and document concrete test cases
4. Execute on the shared dev server
5. Record Pass/Fail with actual results
6. Accept or reject the feature for final delivery

A feature is accepted when:

• A user can complete the primary flow without error
• Invalid inputs return the correct error response
• Performance targets are met (≤300ms for geospatial queries, ≤200ms for search)
• Behaviour is consistent across web and mobile surfaces

We will accumulate test data through a reusable synthetic dataset that covers the main user journeys of Social Event Mapper. The dataset will include predefined users, hosts, events, join requests, participations, tickets, favorite locations, and event lifecycle states.

The test data will be organized around realistic personas such as:

• hosts who create and manage events,
• participants who search for and join events,
• users with pending, approved, rejected, or canceled participation states.

We will create events with different privacy levels, categories, capacities, locations, and time intervals so that login, discovery, joining, approval, ticketing, and filtering flows can be tested consistently.

We will use synthetic data.

We will not use real production user data. Instead, we will generate controlled test data with realistic values such as Istanbul-based locations, believable event names, realistic dates, and valid user profiles. This allows us to test the system safely while keeping the data deterministic and easy to reset.

Example synthetic data will include:

• users with valid and invalid login credentials,
• public, protected, and private events,
• events in different categories such as Gaming, Wellness, Sports, and Music,
• locations with realistic coordinates,
• join requests in PENDING, APPROVED, and REJECTED states,
• tickets in ACTIVE, USED, CANCELED, and EXPIRED states.

We will use the following test data design methodologies:

• Requirements-based testing: Test data will be mapped to the functional requirements, especially login, discovery, participation, approval, and ticketing requirements.
• Use-case based testing: Data will be designed around real user flows such as logging in, discovering an event, requesting to join, host approval, and QR ticket scanning.
• Equivalence partitioning: We will group inputs into valid and invalid classes, such as valid login credentials vs. invalid credentials, public vs. protected events, and approved vs. pending participants.
• Boundary value analysis: We will include edge cases such as full event capacity, maximum allowed tags, events near the selected radius boundary, and expired tickets.
• State-transition testing: We will test transitions such as join request PENDING -> APPROVED, ticket ACTIVE -> USED, and event ACTIVE -> COMPLETED.
• Negative testing: We will include invalid credentials, duplicate join attempts, reused QR tickets, and unauthorized access attempts.

We will validate the realism of the synthetic data by comparing it with the project scenarios, requirements, and expected user behavior.

The data will be checked against the following criteria:

• each test user has a clear role and purpose,
• event names, categories, locations, and times are realistic,
• event capacities and participation states match normal platform usage,
• public, protected, and private event rules are represented,
• location data is realistic enough to test radius and map-based discovery,
• ticket and join request states follow valid lifecycle transitions,
• each dataset supports at least one concrete acceptance test.

We will also validate the dataset by running end-to-end acceptance scenarios manually. If a synthetic scenario feels unrealistic or does not map to a requirement, we will revise the data before using it in the final acceptance tests.

• Acceptance Test - Cansu Er
• Acceptance Test - Buğra Keser
• Acceptance Test - Emine Türk
• Acceptance Test - Sevde Pekköse
• Acceptance Test - Utku Yiğit Demir
• Acceptance Test - Mehmet Akif Yıldırım
• Acceptance Test - Mehmet Kaan Ünsel

• Created the Lab 9 Report Page with the template.
• Wrote the acceptance test.

• Wrote a concrete acceptance test.
• Explained the data strategy to support meaningful testing.

• Wrote a concrete acceptance test for the private event invitation acceptance and access control flow.

• Wrote a concrete acceptance test.
• Wrote Requirements Review part for Lab 9 Report.

• Wrote a concrete acceptance test.

• Wrote a detailed acceptance test for reconfirmation flow, which covers a scenario where a user cancel his participation after getting a notification regarding event's time change.
• Helped creating Acceptance Testing Strategy section for this report.

• Wrote a concrete acceptance test
• Wrote Acceptance Testing Strategy part for Lab 9 Report.

• Wrote a concrete acceptance test for the protected event join-request rejection flow.