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

AT-01: New user onboards, configures profile, and authenticates securely

Author: Muhammet Sami Çakmak

Covers

• User registration with real name, email, and password
• Email-uniqueness enforcement
• Password strength criteria
• Email verification before account activation
• Login with email and password
• Credential verification on login
• Error displayed when invalid credentials are submitted
• Logout
• Password reset / forgot-password recovery flow
• Mentee profile creation and editing
• Mentee specifies goals, interests, and background information
• Mentor profile creation and editing
• Mentor defines mentoring goals and preferred mentee criteria
• Profile fields populated: background, goals, skills, interests
• Profile mentoring preferences
• Profile visibility control
• Profile location field

Covered requirement meaning

A new user (mentor or mentee) must be able to register, verify their email, log in, recover access through the password-reset flow, configure their full role-appropriate profile (including location and visibility), and log out securely.

Requirement IDs covered

1.1.1.1.1, 1.1.1.1.2, 1.1.1.2.1, 1.1.1.2.2, 1.2.2.1, 1.2.2.2, 1.2.2.3, 1.2.2.5, 1.2.3.1, 1.2.3.2, 1.2.3.3, 1.2.3.4, 1.2.3.5, 1.2.3.6, 1.2.3.7, 1.2.3.8

Total: 16 requirements

---

Test 1 — User Onboarding & Authentication

Prerequisite: The system is running, and the user has access to a valid, unregistered email address.

#	Instruction	Expectation	Result	Notes
1	Attempt to register a new account using a real name, a new email, and a password that meets the system's strength criteria	Account is created in a pending state; a verification email is sent to the user
2	Attempt to register a second account using the exact same email address	Registration is blocked; the system enforces email uniqueness and displays an error
3	Attempt to register with a password that fails the strength criteria (e.g., too short, missing numbers)	Registration is blocked; the system displays a password strength criteria error
4	Click the verification link in the received email, navigate to the login page, and enter the valid credentials	Login is successful (credential verification passes); user is directed to the initial profile configuration
5	Attempt to log in using an incorrect password for the verified account	Login fails; the system displays an "Invalid credentials" error message
6	Navigate to the "Forgot Password" flow, request a reset link, set a new valid password via email, and log in	Password reset is successful; user can log in with the new password
7	As a Mentee, navigate to the profile configuration screen; fill out background information, goals, interests, location, and set profile visibility; save	Mentee profile is successfully created/edited with all specified fields populated correctly
8	As a Mentor, navigate to the profile configuration screen; define mentoring goals, preferred mentee criteria, background, skills, interests, mentoring preferences, location, and set visibility; save	Mentor profile is successfully created/edited with all specified fields and preferences populated correctly
9	Click the "Logout" button from the main navigation menu	User session is securely terminated; the user is redirected to the login or landing page

Beratcan Doğan — Example Acceptance Test (Test 2)

Author: Beratcan Doğan Feature: Mentorship Lifecycle & Blog Name: Mentor runs a complete mentorship lifecycle and publishes blog content Id: AT-02 Description: Verifies that a mentor can run the full mentorship lifecycle (availability, request handling, scheduling, goal/task management, feedback, termination) and publish blog content visible to other users.

Prerequisite:

• A verified mentor account with completed profile exists.
• The mentor is logged in.
• Seeded mentee candidate data is available in the system.

Test Steps

#	Instruction	Expectation	Result	Note
1	Open the mentor dashboard and define weekly availability slots.	The availability calendar accepts the entries and saves the mentor's weekly schedule successfully.
2	Open the candidate mentee profile from the recommendation notification.	The mentor receives a candidate recommendation notification and the mentee's full profile is displayed.
3	Accept the mentorship request and select a duration of 1, 3, or 6 months.	The request is accepted, the duration is recorded, and the mentee is notified of the acceptance.
4	Schedule recurring weekly meetings with the mentee using concrete dates.	The recurring meetings are saved and a confirmation notification is sent to both parties.
5	Define a shared goal jointly with the mentee and add milestones under it.	The shared goal and its milestones are saved and visible on both mentor and mentee mentorship pages.
6	Assign a weekly task with a deadline, then review the mentee's submission and provide structured feedback.	The task is delivered to the mentee with the correct deadline, the submission is reviewed, and feedback is recorded against the task.
7	Open the progress tracking view of the mentorship.	The system displays task history and progress over time across tasks and milestones with accurate completion indicators.
8	End the mentorship early after marking the goal as reached.	The mentorship is closed, the final status is recorded, and both users are notified.
9	Publish a new blog post from the mentor account, then edit it.	The blog post is published and visible to all authenticated users; edits are saved and reflected on the post.
10	Switch to another authenticated user, like and comment on the post, then open the mentor's public profile.	The like count and comment appear on the post, and the mentor's public profile lists their published blog posts.

Note: Covers mentorship lifecycle (availability, requests, scheduling, goal/task/milestone management, feedback, progress, termination) and blog publishing/engagement on the mentor's public profile.

Test 3

Author: Övgü Su Afşar

Feature: Authentication & Profile Management

Name: User registration, login, logout, and profile management

ID: AT-03

Description: Verifies that a new user can register with valid information, log in with the created account, update profile information according to the selected role, log out successfully, and receive an error when attempting to log in with incorrect credentials.

Prerequisite: The application is running, and the user does not already have an account with the same email address.

Test Data:

• Name: Ayşe Demir
• Email: ayse.demir@test.com
• Password: ValidPass123
• Role: Mentee
• Interests: Data Science, Career Planning
• Background: Industrial Engineering student
• Location: Istanbul

#	Instruction	Expectation	Result	Notes
1	Navigate to the registration page	The registration screen is displayed with fields for name, email, password, role, and profile-related information
2	Enter a real name, unique email, valid password, role, interests, goals, background, and location	The system accepts all valid input values without validation errors
3	Submit the registration form	The user account is created successfully, and the system stores the new user with a unique email address		Covers requirement 1.1.1.1.1 and 1.1.1.1.2
4	Navigate to the login page and log in using the registered email and password	Login is successful, and the user is redirected to the authenticated area of the application		Covers requirement 1.1.1.2.1
5	Open the profile page	The profile screen is displayed with the current user information		Covers requirement 1.2.2.1
6	Edit profile fields such as bio, goals, skills, interests, visibility, and location	The system allows the user to modify the editable profile fields		Covers requirements 1.2.2.2, 1.2.2.3, 1.2.2.5, and 1.2.3.1–1.2.3.8
7	Save the updated profile information	The profile changes are stored successfully and remain visible after refresh or revisit		Covers persistence of profile management features
8	Log out from the application	The current session is terminated successfully, and the user is redirected out of the authenticated area		Covers requirement 2.2.1
9	Attempt to log in again using the same correct credentials	Login is successful, confirming that the account remains active after logout		Confirms account continuity after logout
10	Attempt to log in using the correct email but an incorrect password	Login fails, and the system displays an invalid credentials error message		Covers requirement 1.1.1.2.2; passwords should not be stored as plain text in the database

Test 4 — Community Lifecycle Management

Author: Mehmet Bora Sarıoğlu Feature: Communities Name: A community is created and operates through full posting, voting, feeds, anti-spam reputation gating, and visibility-aware membership lifecycle ID: AT-04

Description

Verifies the end-to-end lifecycle of a community on the platform via the web application. Covers community creation with all three visibility modes (public, restricted, private), unique-URL generation, immutable community names, automatic moderator assignment of the creator, multimedia post creation (text, image, video, link, poll), post edit/delete/save/share, platform-wide rule enforcement, moderator-gated post approval and pinning, threaded commenting (create, reply, edit, delete), comment voting, comment awards, post upvoting and downvoting, separated post-reputation and comment-reputation accrual, anti-spam reputation gating, personalized home feed, platform-wide popular feed, community-specific feed, all five sort modes (hot, new, top, rising, controversial), near-real-time feed updates, restricted-community write gating, private-community read gating, moderator approval of membership requests, and leaving a community.

Prerequisites

The following must hold before the teswlt begins. Each prerequisite is exact and verifiable.

• The production web application is reachable at <production server URL> over HTTPS in a Chromium-based browser at the latest released version, with the latest backend deployment serving requests.
• Five user accounts exist, are email-verified, can log in, are eligible to create communities per the platform's published role policy, and are independent (no membership relationships, no friend/follow relationships, no blocked relationships between any pair). Their credentials are known to the tester:
  • User A — community creator, will become the first moderator of Backend Engineering Hub.
  • User B — regular member, will create posts of all five types and be the upvote target for reputation accrual.
  • User C — regular member, will comment, reply, vote, send awards, and request membership to the private community.
  • User D — second creator, will create the Restricted Topic Hub and the Private Topic Hub.
  • User E — newly created low-reputation account (zero post-reputation, zero comment-reputation), will trigger the anti-spam gating path.
• No community currently exists with any of these names: Backend Engineering Hub, Frontend Engineering Hub, Restricted Topic Hub, Private Topic Hub. A read of the communities table (or the discovery page) confirms zero matching rows.
• Each of User A, B, C, D, E has post-reputation = 0 and comment-reputation = 0 at the start of the test (User B's reputation will increase during the test).
• A test image file test-image.jpg (JPEG, ≤ 5 MB, ≥ 800 × 600 px) is available on the test machine.
• A test video file test-video.mp4 (MP4 H.264, ≤ 50 MB, ≤ 60 seconds) is available on the test machine.
• A reachable external URL https://example.com/article-on-backend-engineering resolves to a public web page.
• The platform's published anti-spam threshold for low-reputation users is documented and is referenced as THROTTLE_AT_N_POSTS (the post count within a 60-second window after which the system throttles or routes to automod). For the test below, THROTTLE_AT_N_POSTS = 3; if the platform's actual configured value differs, substitute it in step 48.
• The tester has read access to the database (or to an admin panel) sufficient to verify reputation scores, post statuses (PENDING / APPROVED), and membership rows when those fields are not directly surfaced in the user UI.
• The browser session storage and cookies are cleared before the test begins so that no stale auth tokens are present.
• The system clock on the test machine is synchronized to within 2 seconds of NTP, so that the 5-second real-time-update assertion in step 46 is meaningful.

Steps

#	Instruction	Expectation	Result	Notes
1	Open the web application in the browser and log in as User A using their email and password.	The home dashboard loads within 3 seconds. The navigation bar displays User A's first name. The "My Communities" section is empty (User A is not yet a member of any community).
2	Navigate to the "Communities" section via the main navigation.	The communities discovery page loads. A "Create Community" button is visible.
3	Click "Create Community".	A community-creation form is displayed with required fields Name, Title, Description, Rules, Topic, and Visibility. The Name field shows helper text indicating the name must be unique platform-wide and is not editable after creation.
4	Enter Name = Backend Engineering Hub.	The Name field accepts the input with no validation error.
5	Enter Title = Backend Engineering Hub — A place to learn server-side development.	The Title field accepts the input.
6	Enter Description = Discussions about backend frameworks, databases, distributed systems, and software architecture.	The Description field accepts the input.
7	Enter Rules = 1. Be respectful. 2. No off-topic content. 3. Cite sources for technical claims.	The Rules field accepts the input.
8	Select Topic = Software Engineering from the topic dropdown.	The Topic dropdown lists at least one non-empty category and accepts the selection.
9	Select Visibility = Public.	The Visibility selector accepts Public.
10	Click "Create".	A success toast is displayed. The browser navigates to the new community page at a URL of the form <production server URL>/c/<slug> where <slug> is uniquely derived from Backend Engineering Hub (e.g. backend-engineering-hub). The community page header displays Name, Title, Description, Rules, Topic, and Visibility = Public exactly as entered in steps 4–9. The Members section lists User A with role Moderator.
11	On the community settings page, attempt to edit the Name field.	The Name field is read-only or disabled in the UI. Any direct API attempt to mutate the name returns HTTP 400, 403, or 409 and the stored name remains unchanged.
12	Edit the Description to Updated description text and click Save.	The description update is accepted. The page now displays Updated description text. A page refresh persists the change.
13	Open a second browser tab. Navigate to "Create Community" and submit the form with Name = Backend Engineering Hub and otherwise valid fields.	The submission is rejected with a clear inline error message stating the name is already in use. No second community with this name is created (the original community remains the only row with that name).
14	In the second tab, change the Name to Frontend Engineering Hub, set Topic = Frontend, Visibility = Public, and submit the otherwise valid form.	A new community is created at a different unique URL /c/frontend-engineering-hub. Both communities now appear in the discovery page list. Close the second tab.
15	Log out User A. Log in as User B. Navigate to the Backend Engineering Hub community via the discovery page.	The community page loads. A Join button is visible. User B is not in the member list.
16	Click Join.	The join action completes within 2 seconds with no approval step. The button changes to Leave (or Joined). User B appears in the member list with role Member.
17	Click Create Post, choose type Text, enter Title = Welcome to backend engineering and Body = What are your favorite backend frameworks?, then click Submit.	The post is published immediately. It appears at position 1 in the community feed when sorted by New. The post displays type Text, Title Welcome to backend engineering, Body matching the input, and author User B.
18	On the post created in step 17, click Edit. Change the body to What are your favorite backend frameworks in 2026? and save.	The body updates to the new text. An edited indicator appears on the post. A page refresh persists the change.
19	Click Create Post, choose type Image, upload test-image.jpg, enter Title = My desk setup, and submit.	The image post is created and the image renders inline in the feed at the post's preview area. Clicking it opens a full-size view.
20	Click Create Post, choose type Video, upload test-video.mp4, enter Title = 5-minute Spring Boot intro, and submit.	The video post is created. The video plays inline (or in a player overlay) when the play control is clicked.
21	Click Create Post, choose type Link, paste URL = https://example.com/article-on-backend-engineering, enter Title = Useful backend article, and submit.	The link post is created. The post displays the URL as a clickable link that opens the URL in a new tab when clicked.
22	Click Create Post, choose type Poll, enter Question = Best backend language? and Options = Java, Go, Python, Rust, then submit.	The poll post is created. The post displays the question and four selectable options.
23	Click Create Post, choose type Text, leave both Title and Body empty, and click Submit.	The submission is rejected with inline validation errors on the empty fields. The HTTP response is 400. No new post is created (verify by checking the feed contains no empty post).
24	On the Text post created in step 17, click Save (or Bookmark).	The post is added to User B's saved/bookmarks list. Navigating to My Profile > Saved displays the saved post.
25	On the Text post created in step 17, click Share.	A shareable URL is generated and either copied to the clipboard or displayed in a modal. The URL has the form <production server URL>/c/backend-engineering-hub/posts/<post id> and resolves to the post when opened in a new tab.
26	On the Image post created in step 19, click Delete and confirm.	The post is removed from the community feed within 2 seconds. A page refresh does not bring it back. The post no longer appears in any feed (home, popular, community-specific).
27	Log out User B. Log in as User C. Navigate to Backend Engineering Hub and click Join.	User C is added to the member list with role Member.
28	On User B's Text post (the one from step 17), click Comment, enter Spring Boot for me., and submit.	The comment is posted and appears under the post within 2 seconds. The comment author is User C.
29	On the comment created in step 28, click Reply, enter Why not Quarkus?, and submit.	The reply is nested visually under the parent comment. The reply author is User C.
30	On the reply created in step 29, click Edit. Change the text to Why not Quarkus or Micronaut? and save.	The reply text is updated. An edited indicator appears. A page refresh persists the change.
31	On the reply, click Delete and confirm.	The reply is removed from the thread within 2 seconds. A page refresh does not bring it back.
32	On User B's Text post, click the upvote control.	The post's net vote count increases by exactly 1 from its previous value. The upvote control reflects the active state. The change is persisted (a page refresh shows the same vote count). User B's post-reputation, as displayed on User B's profile or read from the database, is greater than its value before this step.
33	On User B's Link post (from step 21), click the downvote control.	The post's net vote count decreases by exactly 1 from its previous value. The downvote control reflects the active state.
34	On the comment created in step 28 (Spring Boot for me.), click the upvote control.	The comment's net vote count increases by exactly 1. User B's comment-reputation, as displayed on User B's profile or read from the database, is greater than its value before this step.
35	On the same comment, click Send Award and select any available award type. Confirm.	An award icon appears on the comment. The comment shows it has received 1 award (or more, if awarded previously).
36	Open User B's public profile.	The profile displays two distinct reputation values: a Post Reputation field with a value greater than 0 (from the upvote in step 32) and a Comment Reputation field with a value greater than 0 (from the upvote in step 34). The two values are displayed as separate fields and are not summed into a single combined reputation.
37	Navigate to Home Feed.	The feed lists posts only from communities User C is a member of (Backend Engineering Hub). No posts from Frontend Engineering Hub (which User C has not joined) appear. Posts are ordered by recent activity and engagement.
38	Navigate to Popular Feed.	The feed lists high-vote posts from across the entire platform regardless of membership. The feed includes posts from communities User C has not joined, if those communities contain high-vote posts.
39	Navigate to Backend Engineering Hub's community feed.	Only posts in Backend Engineering Hub are listed. No posts from Frontend Engineering Hub appear.
40	In the community feed, switch the sort mode to Hot.	Posts are re-ordered. The post at position 1 has higher hot-score (a function of vote count and recency) than every post at a lower position.
41	Switch the sort mode to New.	Posts are re-ordered strictly by descending creation timestamp: the post at position 1 has the most recent createdAt, and each subsequent post has a createdAt less than or equal to the one above it.
42	Switch the sort mode to Top.	Posts are re-ordered strictly by descending net vote count over the all-time period. The post at position 1 has the highest net votes; each subsequent post has a value less than or equal to the one above it.
43	Switch the sort mode to Rising.	Posts are re-ordered to surface recently-created posts that are accumulating votes quickly (a function of votes per unit time since creation). The order differs from both New and Top.
44	Switch the sort mode to Controversial.	Posts are re-ordered to surface posts with high vote volume and a near-equal upvote/downvote ratio (a function of total votes and the absolute distance of the upvote ratio from 0.5).
45	Open two browser windows side by side. In window 1, log in as User B. In window 2, remain logged in as User C. Both windows navigate to Backend Engineering Hub community feed sorted by New.	Both windows display identical content at the moment they finish loading.
46	In window 1 (User B), create a new Text post titled Real-time test with body Verifying near-real-time feed updates. and submit.	Within 5 seconds and without any manual refresh in window 2, the new Real-time test post appears at position 1 of the community feed in window 2 (User C).
47	Log out User B. Log in as User E (the new low-reputation account). Join Backend Engineering Hub.	User E is added to the member list with role Member and a confirmed reputation of 0 across both post-reputation and comment-reputation.
48	As User E, attempt to create 5 Text posts within 60 seconds. In a separate browser window, as User B (high reputation from step 32), attempt to create 5 Text posts within 60 seconds.	After User E's THROTTLE_AT_N_POSTS-th post (3rd, per prereqs), subsequent posts in the 60-second window are either (a) rejected with HTTP 429, or (b) created with status PENDING and routed to the automod approval queue rather than published immediately. User B's 5 posts all publish immediately with status APPROVED (no throttle). The two users' observable behavior differs, demonstrating reputation-based gating.
49	Log in as User A. Open the Backend Engineering Hub Settings and enable Require post approval before publishing. Save.	The setting is persisted (visible after page refresh). The community now displays a banner indicating posts require approval.
50	Log out User A. Log in as User B. In Backend Engineering Hub, create a new Text post titled Approval gate test.	The post is submitted with status PENDING. The post is not visible in the public community feed for any user (verify by checking the feed as User C). The submission UI confirms the post is awaiting moderator approval.
51	Log in as User A. Open the moderator approval queue for Backend Engineering Hub and approve User B's pending Approval gate test post.	The post status transitions from PENDING to APPROVED. The post appears in the public community feed within 5 seconds.
52	As User A, on the now-approved Approval gate test post, click Pin.	The post receives a visible pin indicator. The post appears at position 1 of the community feed regardless of which sort mode (Hot, New, Top, Rising, Controversial) is selected.
53	As User A, return to community Settings and disable Require post approval before publishing. Save.	The setting is reverted. New posts no longer require approval.
54	Log out User A. Log in as User D. Create a community with Name = Restricted Topic Hub, Title = Restricted Topic Hub — Approved Discussion, Description = For approved members to post about restricted topics., Rules = Members must be approved to post., Topic = Software Engineering, Visibility = Restricted. Submit.	The community is created at /c/restricted-topic-hub. User D is listed as the first Moderator. The visibility badge on the page reads Restricted.
55	Log out User D. Log in as User B. Navigate to /c/restricted-topic-hub directly.	The community page loads with full visibility of name, title, description, rules, and any existing posts. The Create Post UI is hidden or disabled, and instead a Request Membership button is shown.
56	As User B, click Request Membership.	The membership request is submitted. User B's membership status is set to Pending.
57	Log in as User D. Open the membership request queue for Restricted Topic Hub and approve User B.	User B's status transitions to Approved Member.
58	Log in as User B. In Restricted Topic Hub, create a Text post titled First approved post.	The post is published successfully (status APPROVED) and appears in the community feed.
59	Log in as User D. Create a community with Name = Private Topic Hub, Title = Private Topic Hub — Members Only, Description = Private community for approved members only., Rules = Members only., Topic = Software Engineering, Visibility = Private. Submit.	The community is created at /c/private-topic-hub. User D is listed as the first Moderator. The visibility badge reads Private.
60	Log out User D. Log in as User C. Navigate to /c/private-topic-hub directly.	Access is denied: the page returns HTTP 403 (or shows a "Members only" page). The community's name, description, rules, and posts are not revealed to User C in the response.
61	As User C, click the Request Membership button (which may appear on the access-denied page or via a discovery flow).	The request is submitted. User C's membership status for Private Topic Hub is Pending.
62	Log in as User D. Open the membership request queue for Private Topic Hub and approve User C.	User C's status transitions to Approved Member.
63	Log in as User C. Navigate to /c/private-topic-hub.	The community page now loads with full visibility of name, title, description, rules, and posts.
64	Log in as User A. Open Backend Engineering Hub, click Leave Community, and confirm.	User A is removed from the member list of Backend Engineering Hub within 2 seconds. The community itself remains. A page refresh confirms User A is no longer listed.

Requirement IDs covered

1.1.7.1.1, 1.1.7.1.2, 1.1.7.1.3, 1.1.7.1.4, 1.1.7.1.5, 1.1.7.1.6, 1.1.7.1.7, 1.1.7.1.8, 1.1.7.1.9, 1.1.7.1.10, 1.1.7.1.11, 1.1.7.1.12, 1.1.7.1.13, 1.1.7.1.14, 1.1.7.1.15, 1.1.7.1.16, 1.1.8.1.1, 1.1.8.1.2, 1.1.8.1.3, 1.1.8.1.4, 1.1.8.1.5, 1.1.8.1.6, 1.1.8.1.7, 1.1.8.1.8, 1.1.8.1.9, 1.1.8.1.10, 1.1.8.1.11, 1.1.8.1.12, 1.1.8.1.13, 1.1.8.2.1, 1.1.8.2.2, 1.1.8.2.3, 1.1.8.2.4, 1.1.8.2.5, 1.1.8.2.6, 1.1.9.1, 1.1.9.2, 1.1.9.3, 1.1.9.4, 1.1.9.5, 1.1.9.6, 1.1.10.1, 1.1.10.2, 1.1.10.3, 1.1.10.4, 1.1.10.5, 2.3.4

Total: 47 requirements

Step-to-requirement traceability

Requirement	Step(s)
1.1.7.1.1 Eligible users create communities	10
1.1.7.1.2 Unique community name	4, 13
1.1.7.1.3 Title required	5
1.1.7.1.4 Description required	6
1.1.7.1.5 Rules required	7
1.1.7.1.6 Topic required	8
1.1.7.1.7 Visibility public/restricted/private	9, 54, 59
1.1.7.1.8 Unique URL per community	10, 14
1.1.7.1.9 Names unique platform-wide	13
1.1.7.1.10 Names not editable after creation	11
1.1.7.1.11 Creator becomes first moderator	10, 54, 59
1.1.7.1.12 Public communities joinable without approval	16
1.1.7.1.13 Users can leave communities	64
1.1.7.1.14 Restricted: public read, mod-approved write	55, 56, 57, 58
1.1.7.1.15 Private: mod-approved read+write	60, 61, 62, 63
1.1.7.1.16 Mods approve/reject membership	57, 62
1.1.8.1.1 Create posts if rules allow	17
1.1.8.1.2 Text posts	17
1.1.8.1.3 Image posts	19
1.1.8.1.4 Video posts	20
1.1.8.1.5 Link posts	21
1.1.8.1.6 Poll posts	22
1.1.8.1.7 Edit own posts	18
1.1.8.1.8 Delete own posts	26
1.1.8.1.9 Share posts	25
1.1.8.1.10 Save/bookmark posts	24
1.1.8.1.11 Enforce platform + community rules pre-publish	23
1.1.8.1.12 Mod-approved posts	49, 50, 51
1.1.8.1.13 Mod pin posts	52
1.1.8.2.1 Comment on posts	28
1.1.8.2.2 Reply to comments	29
1.1.8.2.3 Edit own comments	30
1.1.8.2.4 Delete own comments	31
1.1.8.2.5 Up/downvote comments	34
1.1.8.2.6 Awards on comments	35
1.1.9.1 Upvote posts	32
1.1.9.2 Downvote posts	33
1.1.9.3 Visibility ranking by votes	40, 42
1.1.9.4 User reputation from upvotes	32, 34, 36
1.1.9.5 Separate post-reputation and comment-reputation	36
1.1.9.6 Reputation as anti-spam signal	48
1.1.10.1 Personalized home feed	37
1.1.10.2 Platform-wide popular feed	38
1.1.10.3 Community-specific feed	39
1.1.10.4 Sort modes hot/new/top/rising/controversial	40, 41, 42, 43, 44
1.1.10.5 Ranking factors: votes, engagement, freshness, subscriptions	37, 40, 43
2.3.4 Community feed near-real-time	46

Test 5

Author: İbrahim Kayan
Feature: Platform Moderation, Abuse Reporting, and Admin Oversight
Name: End-to-End Abuse Mitigation: Automated Detection, User Reporting, and Escalated Admin Resolution
Id: AT-05
Description: Verify the complete lifecycle of abuse mitigation. The test ensures that an abusive user is flagged by automated keyword filters, reported by community members, handled locally by Community Moderators (post removal, muting), and finally escalated to Platform Admins for a permanent ban.
Requirements Covered:

• 1.1.11.2.3, 1.1.11.2.5 (Automated filters detect prohibited words and flag suspicious activity)
• 1.1.12.1, 1.1.12.2 (Users can report community posts and comments)
• 1.1.11.1.2, 1.1.11.1.3, 1.1.11.1.5 (Community Mods can remove posts/comments and mute users)
• 2.2.8 (System detects coordinated abuse and surfaces clusters to Admins)
• 1.1.1.3.1, 1.1.1.3.2, 1.1.1.3.3, 1.1.11.3.4 (Admins investigate, review reports, ban users, and maintain ultimate authority)

Prerequisite:

• User "Spammer A" is registered.
• User "Member B" is registered and belongs to the "Tech Community".
• User "Mod C" is a Community Moderator for the "Tech Community".
• User "Admin D" is a Platform Administrator.
• The "Tech Community" has an automated moderation filter configured to block the word "HackTool".

Test Steps

#	Instruction	Expectation	Result	Note
1	Enter Spammer A's credentials on the Login Page and click "Login".	Spammer A is authenticated.
2	Navigate to the "Tech Community" page and click "Create Post".	The post creation form appears.
3	Enter the word "HackTool" in the post body and click "Submit".	The system accepts the post but automatically flags it. It does not appear on the public community feed.
4	Navigate to an existing post from another user and write an offensive comment, then click "Post".	The comment is successfully posted and visible on the thread.
5	Click the "Logout" button.	Spammer A is logged out.
6	Enter Member B's credentials on the Login Page and click "Login".	Member B is authenticated.
7	Navigate to the thread containing Spammer A's offensive comment.	The comment is visible.
8	Click the "Report" button next to Spammer A's comment, select "Abusive", and click "Submit".	A success message confirms the report was sent.
9	Click the "Logout" button.	Member B is logged out.
10	Enter Mod C's credentials on the Login Page and click "Login".	Mod C is authenticated.
11	Navigate to the "Community Moderation Queue".	The auto-flagged "HackTool" post and Member B's reported comment are both visible in the queue.
12	Click "Remove" on the flagged post, and "Remove" on the reported comment.	Both items are permanently deleted from the community.
13	Navigate to Spammer A's profile and click the "Mute User" button.	Spammer A is restricted from interacting in the Tech Community.
14	System Background Check: Wait 5 seconds for the system to process the multiple moderation actions against Spammer A.	The system generates a "Coordinated Abuse Cluster" ticket and escalates it to the Platform Admin queue.
15	Click the "Logout" button.	Mod C is logged out.
16	Enter Admin D's credentials on the Login Page and click "Login".	Admin D is authenticated.
17	Navigate to the "Platform Admin Dashboard" and click on the "Escalated Abuse" tab.	The system-generated ticket regarding Spammer A is visible.
18	Click "Review Ticket" for Spammer A.	A complete audit trail (removed post, reported comment, mute action) is clearly displayed.
19	Click the "Permanent Ban" button on Spammer A's profile and confirm.	A success message appears. Spammer A is banned.
20	Click the "Logout" button.	Admin D is logged out.
21	Attempt to log in again using Spammer A's credentials.	The login is blocked. The system displays: "Account permanently banned by an Administrator."

Test 6 — 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

Amin Abu-Hilga - Example Acceptance Test

Author: Amin Abu-Hilga
Feature: Non-functional Posture — Public Community API, Security Defenses, and Performance Under Load
Name: Comprehensive Non-Functional System Validation
Id: AT-07
Description: The system must satisfy its non-functional guarantees — defensive security (encryption, hashing, anti-abuse heuristics, regulatory compliance), the public Community API contract with rate limiting, and platform performance under concurrent and high-volume load.
Requirements Covered:

• ⁠ 1.2.4.1 ⁠, ⁠ 1.2.4.2 ⁠, ⁠ 1.2.4.3 ⁠, ⁠ 1.2.4.4 ⁠, ⁠ 1.2.4.5 ⁠ (Community APIs, Moderation Tools, Integrations, Rate Limiting)
• ⁠ 2.2.1 ⁠, ⁠ 2.2.2 ⁠, ⁠ 2.2.3 ⁠ (BCrypt Hashing, HTTPS Encryption, GDPR/KVKK Compliance)
• ⁠ 2.2.5 ⁠, ⁠ 2.2.6 ⁠, ⁠ 2.2.7 ⁠ (Spam bots, Vote Manipulation, Ban Evasion detection)
• ⁠ 2.1.1 ⁠, ⁠ 2.3.2 ⁠, ⁠ 2.3.3 ⁠, ⁠ 2.3.5 ⁠ (24/7 Availability, Concurrent mentor/mentee sessions, Recommendation pipeline load, High volume content creation)

Prerequisite:

• A QA testing environment is deployed with dummy seed data.
• Access to database querying tools, API testing tools (e.g., Postman), and load-testing scripts (e.g., JMeter/k6).
• Test accounts exist for a standard user and a community moderator.

Test Steps

#	Instruction	Expectation	Result	Note
1	[Security] Execute a SQL query directly against the database: ⁠ SELECT password FROM users WHERE id = 1 ⁠.	The returned string is a hashed value (e.g., BCrypt), ensuring passwords are never stored in plaintext.
2	[Security] Inspect network traffic using browser DevTools while logging into the platform.	All network requests strictly use HTTPS, ensuring data in transit is encrypted.
3	[Security] Log in to the web app, navigate to User Settings, and click "Export My Data".	The system generates and downloads a JSON file containing all user data in compliance with GDPR/KVKK.
4	[Security] Execute an automated script to register 100 fake accounts from the same IP address in 10 seconds.	The system detects the spam bot behavior and blocks the IP, rejecting the registrations.
5	[Security] Attempt to register a new account using an email address associated with an already banned account.	The system detects ban evasion and rejects the registration attempt.
6	[Security] Execute a script to send 500 upvotes to a single community post from newly created accounts within 5 seconds.	The system's anti-abuse heuristics flag the vote manipulation and nullify the artificial upvotes.
7	[API] Send an unauthenticated HTTP ⁠ GET ⁠ request to the public endpoint ⁠ /api/communities/{id}/posts ⁠.	The API returns a successful ⁠ 200 OK ⁠ response with a JSON array of community posts.
8	[API] Send an unauthenticated HTTP ⁠ GET ⁠ request to the public endpoint ⁠ /api/posts/{id}/comments ⁠.	The API returns a successful ⁠ 200 OK ⁠ response with a JSON array of comments.
9	[API] Using an automated tool, send 2,000 requests per minute to the public community API endpoints.	The API correctly enforces rate-limiting and returns ⁠ 429 Too Many Requests ⁠ after the threshold is breached.
10	[API] Issue a ⁠ DELETE ⁠ request to a post via the moderation API using a specifically scoped moderator API token.	The request succeeds, verifying third-party moderation tool integration support.
11	[Performance] Execute a load-testing script simulating 5,000 concurrent mentor-mentee messaging sessions.	The system sustains the load without performance degradation (latency remains under 2 seconds).
12	[Performance] Trigger the recommendation engine via API while the system is under the 5,000-user load.	The data pipeline analyzes profiles and returns diverse mentor suggestions without crashing.
13	[Performance] Execute a script simulating high-volume, concurrent content creation (1,000 posts/second).	The platform processes and saves the community posts successfully, proving high-volume scalability.

---

Note:

---

---

Individual Contributions

Name	Task	Linked Issue
Mehmet Bora Sarıoğlu	Wrote the Requirements Review, designed all seven Acceptance Tests with full requirement coverage, authored AT-04 (Community Lifecycle Management), and reviewed the Data Strategy and Acceptance Testing Strategy sections.	#310
Amin Abu-Hilga	Authored AT-07 (Non-functional Posture) covering the public Community API, security defenses, GDPR/KVKK compliance, and platform performance under load — 15 requirements total.	#310
Ö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.	-
Muhammet Sami Çakmak	Authored AT-01 (User Onboarding & Authentication) — a 9-step acceptance test covering registration, email uniqueness, password recovery, login/logout workflows, and role-specific profile configuration (covering 16 requirements).	—
	Contributed to the Acceptance Testing Strategy section, defining the test structure, E2E testing approach using Playwright, and core acceptance criteria.	—
Beratcan Doğan	Wrote Acceptance Test AT-04 (Mentor Discovery and Matching), covering the mentee discovery flow: browsing mentors, keyword search, filtering, matching, ranked results, and profile viewing.	to be filled
	to be filled	to be filled
İbrahim Kayan	Designed an end-to-end acceptance test validating the platform's complete abuse mitigation lifecycle, including automated moderation, user reporting, and admin escalation.
	to be filled	to be filled
Burak Ögüt	Reviewed all requirements against the current mobile implementation and categorized their status as Completed, In Progress, or Not Yet Implemented	—
	Authored AT-06 (Cross-Platform Messaging, Scheduling Reminders, and Notifications) — 14-step end-to-end acceptance test covering mentor–mentee messaging, mentor–mentor messaging, message history pagination, file/link attachments, push notifications, meeting reminder notifications, notification targeting, and 5-second delivery budget	—
	Contributed to the Acceptance Testing Strategy and Data Strategy sections	—