Lab 9 Report

Lab 9 Report

Date: April 30, 2026 Attendees: Amin Abu-Hilga, Övgü Su Afşar, Muhammet Sami Çakmak, Beratcan Doğan, İbrahim Kayan, Mehmet Bora Sarıoğlu, Burak Ögüt

---

Requirements Review

Methodology

We revisited every wiki requirement and tagged each as DONE, PARTIAL, or MISSING against the current code. All wiki requirements are committed to Final Delivery — none are deferred.

Scoping meeting for Blog, Community, and Profile-content requirements. Before implementing the Blog (1.1.6), Community (1.1.7–1.1.12 and 1.2.4), and Profile-content (1.2.2) clusters, we will hold a dedicated meeting with the instructor and a project stakeholder to confirm priorities, refine user-facing surfaces, and lock acceptance criteria. The meetings are scheduled this fridayand the second one in the final week of the project, after the smaller well-bounded features (mentorship lifecycle, meetings, tasks, advanced recommendation, notifications, admin) have shipped, so the community-style features are implemented against confirmed scope.

Status by Area

1.1.1.1 Mentees (13)

#	Status	Plan
1, 2, 3, 4, 5, 9, 10	DONE	Profile CRUD, recommendation list, mentorship requests, in-app messaging (#245), single-active-mentor enforcement, and keyword search are live
6	MISSING	Build Task entity with deadlines + a TaskSubmission upload endpoint (#248)
7	MISSING	Add feedback field on TaskSubmission plus a GET endpoint so the mentee can view it
8	MISSING	Build a Meeting entity (separate from AvailabilitySlot) with concrete dates, plus GET /api/meetings for the mentee (#284)
11	MISSING	Add POST /api/mentorships/{id}/rating, available only after the relationship reaches COMPLETED/TERMINATED
12	MISSING	Add POST /api/mentorships/{id}/cancel with cancel-reason tracking; trigger escalating auto-ban based on Mentee.cancelCount
13	MISSING	Build a unified Report entity (also reused for community reporting) with an admin review queue

1.1.1.2 Mentors (15)

#	Status	Plan
1–3, 5–7, 11, 12	DONE	Profile editing, candidate browsing, accept/reject, messaging, multi-mentee capacity, and predefined 1/3/6-month durations are all in production
4	PARTIAL	Match-found notification fires on every browse — fix per bug #273 to fire only when the top match actually changes
8	PARTIAL	Only weekly recurring availability slots exist; need an explicit Meeting entity with concrete dates to satisfy this requirement
9, 10	MISSING	Both unblocked by the Task entity work (#248) — assign weekly tasks with deadlines, review submissions, and provide structured feedback
13, 14	MISSING	Add POST /api/mentorships/{id}/extend and POST /api/mentorships/{id}/end with the appropriate state transitions and notifications
15	MISSING	Build the Blog feature (post + comment + like) — final scope confirmed in the stakeholder meeting

1.1.1.3 Admins (3) — All MISSING

AdminController is currently a stub (only the /me endpoint exists). For Final Delivery we will build admin endpoints to ban/unban users, list flagged accounts, and walk through the report review queue. All three requirements depend on the unified Report entity that is also used by 1.1.1.1.13 and 1.1.12.

1.1.2 Recommendation (8)

#	Status	Plan
6, 7	DONE	Surname and profile photo are hidden at the recommendation stage (to be re-verified by acceptance test); mentees cannot search or discover other mentees because no such endpoint exists
1, 2, 8	PARTIAL	(1) Background fields are not yet weighted into the matching score; (2) the match-found notification over-fires on every browse (bug #273); (8) the capacity check has a race condition (bug #270) — add a DB-level optimistic lock
3	MISSING	Add city (and optional lat/lng) to User, include a proximity bucket in the score, and expose a distance filter
4	MISSING	Add a "diverse pick" branch in rankMentors that surfaces ~10% out-of-primary-goal mentors via shared interests/skills
5	MISSING	Return a per-recommendation factor breakdown on MentorMatchResponse (e.g. "shared interest: ML; same major; 3 km away") to power the explanation card UI

1.1.3 Messaging (5)

#	Status	Plan
1–4	DONE	STOMP + REST messaging, paginated history, and document/link attachments via AttachmentController (#245)
5	PARTIAL	ConversationKind enum already supports mentor-to-mentor conversations; need to wire the entry point on web and mobile and confirm it works without an active mentorship requirement (#284)

1.1.4 Scheduling (6)

#	Status	Plan
1	DONE	Mentor weekly availability is fully managed via AvailabilityController
2	PARTIAL	Recurring meetings need a dedicated Meeting entity with concrete dates — the current AvailabilitySlot models only the weekly template, not actual scheduled meetings
3, 4	MISSING	Send a confirmation notification on meeting create/accept and a reminder via a @Scheduled job (the MEETING_REMINDER enum value already exists)
5	MISSING	Add a mentee reschedule-request flow: POST /api/meetings/{id}/reschedule with mentor approval
6	MISSING	Add a daily @Scheduled sweep that auto-terminates active mentorships once endDate < now

1.1.5 Tasks & Progress (8)

#	Status	Plan
6	DONE	Shared-goal field on Mentorship plus PUT /api/mentorships/{id}/goal for both parties
1–5	MISSING	Build Task entity with deadlines, submission upload (reusing AttachmentStorageService), structured feedback fields, per-mentorship task history, and a progress aggregation endpoint (#248)
7	MISSING	Build a Milestone entity tied to the mentorship with progress calculation across completed milestones
8	MISSING	Add a deadline + milestone reminder scheduler with per-user opt-in preference

1.1.6 Blog (4) — All MISSING

Build BlogPost, BlogComment, and BlogLike entities; expose /api/blogs CRUD with mentor-author authorization; integrate the published-posts list into the mentor public profile (#283). Final scope confirmed in the stakeholder meeting.

1.1.7–1.1.12 Communities (~60) — All MISSING

Final scope to be confirmed in the stakeholder meeting before last-week implementation. High-level plan, by subsection:

Subsection	Reqs	Plan
1.1.7 Creation & Membership	16	Community entity (immutable name, slug, visibility enum), Moderator + MembershipRequest entities, join/leave/approve endpoints
1.1.8 Posts & Comments	19	Post (TEXT/IMAGE/VIDEO/LINK/POLL via type enum + Poll sub-entity), Comment with parentId, Bookmark, Award; CRUD with author/mod checks
1.1.9 Voting & Reputation	6	PostVote/CommentVote (unique per user-target), cached postReputation/commentReputation on User, hot-score ranking
1.1.10 Feed & Discovery	5	/api/feed/home, /api/feed/popular, community feed; sort modes hot/new/top/rising/controversial
1.1.11 Moderation	14	mod management endpoints, CommunityBan/CommunityMute, AutomodRule (spam, keyword, flair, suspicious-activity flagging), admin override endpoints
1.1.12 Reporting	5	unified Report entity (polymorphic target) + ReportRoutingService (mod-first vs. admin-direct based on violation type)

1.2.1 Notifications (7)

#	Status	Plan
4, 5	DONE	Notifications are scoped to relevant users only; mentees receive a REQUEST_ACCEPTED notification when a mentor accepts their request
1, 2	PARTIAL	In-app delivery via the notification event bus is in place; FCM (mobile) push dispatch is missing — the User.deviceToken field exists but no FCM SDK or send path
3	MISSING	Add meeting confirmation/reminder dispatch alongside the new Meeting entity
6	MISSING	Add the REQUEST_SUBMITTED enum value and dispatch on mentorship-request creation
7	MISSING	Add TASK_DEADLINE_REMINDER and MILESTONE_REMINDER enum values plus the @Scheduled reminder job

1.2.2 Profiles (5)

Final scope confirmed in the stakeholder meeting (profile-content cluster).

#	Status	Plan
1, 2	DONE	Background, goals, skills, interests, and mentoring preferences are all stored on the Mentor/Mentee entities and rendered on profile pages
3	PARTIAL	Mentee.profileVisibility already exists; add an equivalent flag on Mentor and respect it in profile read endpoints
4	MISSING	Once Blog ships, embed the mentor's published posts in the public profile response
5	MISSING	Add city (and optional lat/lng) to User; surface it on profile cards and feed it into the recommendation proximity score

1.2.3 Sign-Up & Authentication (8) — All DONE

Registration with real name/email/password, unique-email enforcement, password strength via PasswordValidator, email verification via VerificationToken, JWT-based login, error response on bad credentials, and stateless logout via JWT discard are all live.

1.2.4 Community API (5) — All MISSING

Build public read endpoints for posts and comments (e.g. /api/v1/public/communities/{slug}/posts), scoped API tokens that moderators can issue for automated tooling, an API-key issuance flow for third-party integrations subject to platform terms, and apply the rate-limiting middleware from #252. Final scope confirmed in the stakeholder meeting.

2.1 Availability (2)

24/7 availability is PARTIAL — Docker Compose is in place for local/staging environments, but the production deployment plus monitoring (Prometheus/Grafana) are still planned by DevOps. Web + mobile access is DONE with both platforms in active development.

2.2 Security (8)

#	Status	Plan
1	DONE	Passwords are stored as BCrypt hashes
2	PARTIAL	HTTPS termination at the deployment layer is planned; messages-at-rest are not encrypted in the database (acceptable per stakeholder discussion)
3	MISSING	Add data-export and account-delete endpoints plus a consent flow at registration to comply with GDPR/KVKK
4	MISSING	Mentee.cancelCount is already tracked; add a bannedUntil field and escalating-ban logic on cancel events
5	MISSING	Apply rate limiting (#252), add a signup CAPTCHA, and run heuristic content checks (duplicate text, link density) on new posts
6	MISSING	Per-user/IP vote rate limiting, rapid-sequential-vote detection, and a sockpuppet similarity check across newly-created accounts
7	MISSING	Device-fingerprint, IP, and email-domain checks at registration cross-referenced against the active-bans table
8	MISSING	Time-window graph clustering on vote/post patterns; flag clusters above a threshold for admin review

2.3 Performance (5)

#	Status	Plan
1, 3	DONE	Notifications are dispatched event-driven well within the 5s budget; the recommendation pipeline analyzes user profiles and produces ranked suggestions
2, 4, 5	UNVERIFIED	Concurrent session capacity, near-real-time feed updates, and high-volume content handling will be validated by DevOps load tests prior to Final Delivery

Pre-existing Bug Fixes (Lab 8 Backlog)

Five backend bugs identified in Lab 8 must be closed before final delivery:

• #270 Mentor capacity race in MentorshipService.acceptRequest — add DB-level optimistic lock
• #271 NPE risk when JWT lacks userId/role claims — null-safe JwtAuthenticationFilter
• #272 Inconsistent timezone handling — standardize on Clock + UTC OffsetDateTime
• #273 Match-found notification fires on every browse — fire only on new top-match change
• #274 Missing per-resource authorization on GET /api/availability/{mentorId}

Plan to Address Unimplemented Requirements

The Final Milestone plan (wiki) is being expanded to cover every wiki requirement — none are deferred. Priority order for the remaining sprints:

1. Core mentorship lifecycle — end/extend/cancel/auto-terminate/auto-ban/rate
2. Meetings — Meeting entity + reminders + reschedule flow
3. Tasks & milestones — Task/Milestone entities, submissions, feedback, progress aggregation
4. Recommendation overhaul — location, diversity, explanation
5. Blog — full CRUD + mentor profile integration (#283)
6. Notifications — FCM dispatch, new types, reminder schedulers
7. Admin & moderation — admin endpoints (ban/list/reports), unified Report entity (shared with community reporting)
8. Communities — Phase A Community + membership + visibility + moderator role (1.1.7)
9. Communities — Phase B Posts (text/image/video/link/poll), edit/delete, share/save, mod approval, pin (1.1.8 posts)
10. Communities — Phase C Comments, replies, comment voting, awards (1.1.8 comments)
11. Communities — Phase D Voting + reputation scoring (1.1.9)
12. Communities — Phase E Feeds (home / popular / community-specific) + sort modes (1.1.10)
13. Communities — Phase F Moderation + automoderation rules + admin oversight (1.1.11)
14. Communities — Phase G Reporting flow (extends shared Report) (1.1.12)
15. Public Community API + integrations with rate-limiting middleware (1.2.4)
16. Anti-abuse hardening — spam-bot, vote-manipulation, ban-evasion, coordinated-abuse detectors (2.2.5–2.2.8)
17. GDPR/KVKK compliance — data-export + delete endpoints + consent UI
18. Lab 8 bug closures — five fixes (#270–#274)
19. DevOps hardening — production deploy, monitoring (Prometheus + Grafana), load testing for performance requirements 2.3.2 and 2.3.5---

As part of executing this plan, we will update the deadlines and descriptions of the relevant GitHub issues (#137, #243, #248–#292) to reflect the expanded final scope and the new phase sequencing, and we will open new issues for the community phases (1.1.7–1.1.12), the public Community API (1.2.4), the anti-abuse detectors (2.2.5–2.2.8), and GDPR/KVKK compliance work so that every wiki requirement is tracked against a concrete issue with an owner and a target date.

--

Acceptance Testing Strategy

Acceptance Testing Strategy

1. How will you structure your acceptance tests?

• We will structure our acceptance tests around specific user journeys (e.g., "Mentee registers -> verifies email -> logs in") and categorize them based on system roles (Mentee, Mentor, Admin).
• Following the structured test document format introduced in the lectures, each test will include specific fields such as a unique Test Case ID, Test Title, Pre-conditions, sequential Test Steps, Test Data, and Expected Results.
• To ensure complete traceability, every test case will be directly linked to a specific requirement ID or user story.
• For every critical workflow, we will design at least one "happy path" (normal operation) and 1-2 high-risk negative scenarios. We will utilize extreme or invalid data (e.g., full mentor capacity, unauthorized access attempts, invalid tokens) to expose potential defects.
• We will implement a seed or reset mechanism for test data isolation to ensure each test runs in a clean, predictable state.

2. What is your acceptance testing strategy?

• Our core strategy relies on requirements-based black-box testing, focusing on validating the system's functionality and performance from the user's perspective without needing to know the internal code structure.
• We will utilize Playwright for automated End-to-End (E2E) testing to verify realistic user flows within actual browser environments.
• System testing will be executed in an integrated environment (frontend combined with backend, such as local Docker or a staging server) to ensure all components interact correctly and transfer the right data across interfaces.
• We will prioritize critical workflows, business rules enforcement, and user-visible feedback mechanisms.
• Our coverage goal is 90-95% for critical paths. The primary success condition is that all critical flows pass seamlessly without yielding any significant UX degradation or regressions in previously working code.

3. What acceptance criteria will you use to validate that you are building "the right thing" from a stakeholder/user perspective?

• Core Goal Completion: Users must be able to successfully complete their primary objectives: registration, verification, login, mentor/mentee discovery, sending/answering requests, messaging, and receiving notifications.
• Business Rule Enforcement: The system must strictly apply and handle all defined business constraints, such as mentor capacity limits, role-based access restrictions, and accurate request status transitions.
• Clear User Feedback: The system must provide clear, understandable, and consistent user feedback (success or failure messages) for all inputs, particularly for borderline or incorrect input attempts.
• State Persistence and Integrity: System data must be persistent and accurate; the correct data must be displayed consistently across page reloads and different user sessions without data corruption.
• Zero Critical Regression: New updates or features must not break previously accepted and working workflows, which will be verified continuously.
• Stakeholder Meetings: We will conduct meetings with stakeholders to demonstrate the implemented features, gather direct feedback, and verify whether the delivered system truly aligns with their initial expectations and desired goals.

---

Data Strategy

Our data strategy is based on synthetic and scenario-based test data. Because the system handles personal profile information, we will not use real user data; instead, we will generate realistic mentor, mentee, community, and messaging data that reflects the two stakeholder personas the project targets — campus students and neighborhood professionals or retirees. The strategy extends the existing seed infrastructure in our repository (seed.sql and scripts/seed_mentors.py) rather than replacing it, and is organized into four layers: bulk synthetic generation, scenario fixtures, validation, and reproducibility.

Bulk Synthetic Generation

For high-volume data we will introduce a scripts/test-data/ package containing per-domain generators driven by a shared taxonomy.json (skills, majors, Istanbul districts and Anatolian cities, community topics) and a personas.json archetype file. The generators rely on the following tools, chosen so that data feels authentic rather than mechanically synthesized:

• Faker (Python, tr_TR locale) for names, emails, lorem text, and dates that match the Turkish character of the project and stay consistent with the style of the existing seed.sql.
• factory_boy for declarative factories with relationships, so a single MentorshipFactory can produce a coherent Mentor + Mentee + MentorshipRequest graph in one call.
• ESCO (European Skills, Competences, Qualifications and Occupations) REST API for standardized skill and occupation labels, reused from our Use of Standards page so that interests, expertise, and preferredMenteeSkills are anchored in a recognized taxonomy.
• Wikidata SPARQL for real Turkish university and tech-company names used in the affiliation field.
• NetworkX to generate community follower graphs and vote graphs with realistic power-law and preferential-attachment distributions, which we then sample to produce (user, post) and (user, comment) vote edges.
• Stack Exchange Data Dump (CC-BY-SA 4.0) as the source for community posts and threaded comments. We map Stack Exchange tags to our community topics (e.g. tag java → "Backend" community, tag react → "Frontend") and preserve native threading. This avoids the Reddit data-licensing constraints introduced in 2023.
• Wikipedia article extracts (wikipedia Python package) for blog post seed text.
• Templated conversation arcs for messaging — eight predefined arcs (introduction, weekly check-in, task feedback, schedule discussion, milestone celebration, blocker, off-topic chat, end-of-mentorship) slot-filled with Faker for fully deterministic generation. For higher-fidelity demo data we may use the Anthropic Claude Haiku API to generate roughly one hundred mentor–mentee dialogues conditioned on persona pairs and an arc, at a cost below one US dollar.
• bcrypt for password hashing prior to bulk SQL insertion, matching the format already used by seed.sql.

Scenario-Based Fixtures

In addition to bulk data, we will hand-craft a small set of named test accounts that drive acceptance-test scenarios: a verified mentor, a verified mentee, an unverified user, a mentor at full capacity, a mentee with an active mentorship, an admin, a banned mentee, and a mentor with published blog posts. We will also seed realistic recurring weekly availability entries for the scheduling features and a small set of curated communities (Backend, Frontend, ML, Mobile, Internship-Hunt, Career-Switch) populated with hand-picked posts so that the demo flow is predictable. These fixtures live as overlays on top of the bulk layer, following the pattern already established by scripts/seed_mentors.py.

Validation

To validate that the test data reflects realistic usage patterns we will:

1. Implement an audit script (scripts/test-data/audit.py) that enforces hard distribution thresholds — for example, at least five mentors at full capacity, ten mentees with an active mentorship, three expired or auto-terminated mentorships, fifty pending requests, one hundred posts in each curated community, and one banned account. The audit fails CI if any threshold drops.
2. Conduct a manual stakeholder walkthrough on the seeded staging environment before each milestone, confirming that profiles, capacities, interests, schedules, community discussions, and mentor–mentee conversations are coherent and that the system's matching and request results are meaningful from a user perspective. This continues the practice already used successfully for the Lab 7 MVP demo.
3. Produce distribution histograms (interests, majors, capacity utilization, mentorship state, vote counts, community sizes) as part of the audit output and flag drift greater than ten percent against target distributions.

Reproducibility

To keep test runs deterministic and cheap, the bulk generators use a fixed Faker.seed(42) in CI and a different seed in staging so that manual QA sees varied data. Generators are idempotent (INSERT ... ON CONFLICT DO NOTHING) so they can be re-run safely. After seeding, a pg_dump snapshot is committed as seed-snapshot.sql; CI restores from this snapshot in seconds rather than regenerating from scratch on each run.

---

Example Acceptance Tests

Test 2 — Password Recovery

Author: Muhammet Sami Çakmak

Feature: Authentication & Security

Name: User resets forgotten password via email

ID: AT-02

Description: Verifies the process of requesting a password reset link, receiving the email, enforcing password strength rules, and successfully setting and logging in with a new password.

Prerequisite: A registered user exists in the system with a valid email address. The user is currently logged out.

#	Instruction	Expectation	Result	Notes
1	Navigate to the Login page and click the "Forgot Password?" link	The Password Recovery screen is displayed, prompting the user for their registered email address
2	Enter an unregistered or invalid email address and submit	The system displays an appropriate error message (e.g., "No account found with this email" or invalid format warning)
3	Enter the valid, registered email address and submit	A success message is displayed indicating that a password reset link has been sent to the provided email
4	Open the corresponding email inbox, locate the password recovery email, and click the reset link	The user is redirected to the "Set New Password" screen, showing input fields for a new password and password confirmation
5	Enter a new password that does not meet the system's security requirements (e.g., too short, missing numbers) and submit	The system blocks the update and displays a validation error detailing the specific password requirements
6	Enter a valid new password, ensure it matches the confirmation field exactly, and submit	A success message confirms the password update, and the user is redirected back to the Login page
7	Attempt to log in using the old password	Login fails, and the system displays an "Invalid credentials" error message
8	Attempt to log in using the newly set password	Login is successful, and the user is routed to their Home dashboard

---

Test 7 — Cross-Platform Real-Time Messaging, Scheduling Reminders, and Notifications

Author: Burak Ögüt (2021400168)

Feature: Messaging, Notifications, and Scheduling Reminders

Name: Cross-platform real-time messaging, scheduling reminders, and notifications operate consistently

ID: AT-06

Description: Verifies that the in-app messaging system, push notification delivery, and scheduling reminder subsystems operate correctly and consistently across web and mobile. Covers mentor–mentee messaging, mentor–mentor messaging, message history pagination, file/link attachments, push notifications for new messages and recommendations, meeting reminder notifications, notification targeting (only relevant users), and the 5-second delivery performance budget.

Prerequisite:

• Mentor A has an active mentorship with Mentee X; both accounts are verified and can log in on mobile and web
• Mentor B exists with a complete public profile and is reachable for mentor–mentor messaging
• A third user (Unrelated User) exists with no connection to Mentor A, Mentee X, or the events being triggered — used to verify notification targeting
• A scheduled meeting between Mentor A and Mentee X is set up with a reminder configured (e.g., 5 minutes before the meeting time)
• Expo push notification tokens are registered for Mentor A and Mentee X on their mobile devices
• The backend messaging API is deployed and reachable at the production server

#	Instruction	Expectation	Result	Notes
1	Log in as Mentee X on the mobile app; remain on the Home screen	Mentee X receives a push notification: "A new mentor recommendation is available for you"
2	Log in as Mentor A on the mobile app; navigate to the Messages tab; start a new conversation with Mentee X and send: "Welcome! Let's start with your goals."	Message is sent; conversation thread with Mentee X appears in the Messages tab with the correct timestamp
3	On Mentee X's device, verify push notification delivery	Mentee X receives a push notification: "New message from Mentor A" within 5 seconds of the message being sent
4	Mentee X opens the notification and views the conversation	The conversation thread opens; Mentor A's message is visible; Mentee X can type and send a reply
5	Mentee X replies: "Hello! My goal is to improve my backend development skills." and sends	Message appears in the thread; Mentor A receives a push notification: "New message from Mentee X" within 5 seconds
6	Mentee X attaches a document (PDF or image) to a new message and sends	The attachment is uploaded and displayed in the conversation; Mentor A can open or preview the attachment
7	Mentee X sends a message containing a URL link	The link is displayed as tappable in the conversation thread; tapping it opens the URL in an in-app browser or the device browser
8	Scroll up in the conversation thread to load older messages	Older messages load correctly (paginated); the interface does not crash or show duplicates; a loading indicator is shown while fetching
9	Log in as Mentor A on the web platform and open the same conversation thread with Mentee X	All messages including the attachment and the link sent on mobile are visible on web; timestamps and read status are consistent across platforms
10	Log in as Mentor A on mobile; navigate to Mentor B's public profile; tap "Send Message" and send: "Hi, I'd like to discuss a shared mentoring strategy."	Message is sent; conversation thread with Mentor B appears in Mentor A's Messages tab
11	Log in as Mentor B on mobile and check for the push notification	Mentor B receives a push notification: "New message from Mentor A" within 5 seconds
12	Log in as Unrelated User on mobile and verify their notification inbox	Unrelated User has received no notifications related to the messages or recommendations triggered in previous steps
13	Wait until the scheduled meeting reminder time is reached (or simulate it); check Mentor A's and Mentee X's devices	Both Mentor A and Mentee X receive a push notification reminding them of the upcoming meeting (e.g., "Your meeting starts in 5 minutes"); Unrelated User receives no such notification
14	Verify all push notifications were delivered within 5 seconds of their triggering events (steps 3, 5, 11, 13)	Each notification timestamp is within 5 seconds of the event that triggered it; no notifications were delayed beyond the performance budget

---

Test 6 - Active Mentorship and Notifications

Author: İbrahim Kayan
Feature: Active Mentorship and Notifications
Name: Capacity Constraint Enforcement and Successful Request Notification Flow
Id: AT-06
Description: Verify that a mentee is blocked from requesting a mentor whose capacity is full. Upon finding an available mentor, verify the request succeeds and triggers the appropriate real-time notifications (REQUEST_RECEIVED and REQUEST_ACCEPTED) for both parties.
Requirements Covered:

• 1.1.1.1.4 (Mentees shall be able to send mentorship requests)
• 1.1.1.2.6 (Mentors shall be able to accept or reject requests)
• 1.1.2.8 (Mentors shall not accept mentees beyond their maximum capacity)
• 1.2.1.5 (System shall notify mentees when mentor accepts request)
• 2.3.1 (System shall deliver notifications within 5 seconds)

Prerequisite:

• User "Mentee A" is registered.
• User "Mentor FULL" is registered, has a max capacity of 1, and currently has 1 active mentee.
• User "Mentor AVAIL" is registered, has a max capacity of 3, and currently has 0 mentees.
• Both mentors are tagged with the "Software Engineering" expertise.
• All users have completely empty notification inboxes.

Test Steps

#	Instruction	Expectation	Result	Note
1	Navigate to the web application Login Page.	The login form is displayed.
2	Enter the email and password for Mentee A and click the "Login" button.	Mentee A is authenticated and redirected to the Home dashboard.
3	Click the "Explore Mentors" tab in the main navigation bar.	The mentor discovery page is displayed with a list of mentors.
4	Type "Software Engineering" into the keyword search bar and press "Enter".	The list filters to show only mentors matching "Software Engineering" (including Mentor FULL and Mentor AVAIL).
5	Click on the profile card for Mentor FULL.	The detailed profile page for Mentor FULL is displayed.
6	Click the "Send Mentorship Request" button.	The system rejects the action. An error message pops up stating: "Cannot send request, mentor capacity is full." The request is NOT created.
7	Click the "Back" button to return to the search results.	The filtered list of mentors is displayed again.
8	Click on the profile card for Mentor AVAIL.	The detailed profile page for Mentor AVAIL is displayed.
9	Click the "Send Mentorship Request" button.	The system accepts the action. A success message pops up stating: "Mentorship request sent successfully."
10	Click the "Logout" button in the top right menu.	Mentee A is logged out and returned to the Login Page.
11	Enter the email and password for Mentor AVAIL and click "Login".	Mentor AVAIL is authenticated and redirected to the Home dashboard.
12	Click the "Notifications" (Bell) icon in the navigation bar.	A new unread notification of type REQUEST_RECEIVED is visible, stating Mentee A sent a request.
13	Click the "Incoming Requests" tab in the navigation bar.	Mentee A's request is visible in the list with a "PENDING" status.
14	Click the "Accept" button next to Mentee A's request.	The request status updates to "ACCEPTED".
15	Click the "Logout" button.	Mentor AVAIL is logged out.
16	Enter the email and password for Mentee A and click "Login".	Mentee A is authenticated and redirected to the Home dashboard.
17	Click the "Notifications" (Bell) icon in the navigation bar.	A new unread notification of type REQUEST_ACCEPTED is visible, stating Mentor AVAIL has accepted the request.

Note:

---

---

Individual Contributions

Name	Task	Linked Issue
Mehmet Bora Sarıoğlu	to be filled	to be filled
	to be filled	to be filled
Amin Abu-Hilga	to be filled	to be filled
	to be filled	to be filled
Övgü Su Afşar	Scenario 1 — User Registration, Login, Logout, and Profile Management**. This contribution includes defining the test purpose, selecting the covered requirements, specifying preconditions and test data, and writing the step-by-step acceptance test case in the required format.	-
	to be filled	to be filled
Muhammet Sami Çakmak	Authored AT-02 (Password Recovery) — an 8-step acceptance test covering email validation, token usage, password strength enforcement, and successful login workflows.	—
	Contributed to the Acceptance Testing Strategy section, defining the E2E testing approach using Playwright and outlining the core acceptance criteria.	—
Beratcan Doğan	to be filled	to be filled
	to be filled	to be filled
İbrahim Kayan	to be filled	to be filled
	to be filled	to be filled
Burak Ögüt	Reviewed all requirements against mobile implementation; categorized status as Completed / In Progress / Not Yet Implemented	—
	Authored AT-05 (Mentorship Request Lifecycle) — 14-step end-to-end acceptance test covering request creation, duplicate prevention, surname anonymization, rejection, capacity enforcement, acceptance, and cross-platform notification	—
	Contributed to Acceptance Testing Strategy and Data Strategy sections	—