-
Notifications
You must be signed in to change notification settings - Fork 0
Lab 9 Report
Ebubekir Erden edited this page May 5, 2026
·
7 revisions
| # | Requirement | Status |
|---|---|---|
| 1.1.1.1 | There shall be 3 types of users: guests, users, and admins. | Implemented |
| 1.1.1.1.1 | Guests shall not be able to initiate communication (e.g., messages) with registered users. | Will Be Implemented |
| 1.1.1.1.2 | Guests shall be able to register as a user account. | Implemented |
| 1.1.1.2.1 | Users shall be able to authenticate using an email and password. | Implemented |
| 1.1.1.2.2 | A user shall have only one role (Mentor or Mentee) per account. Users wishing to perform both roles must register with separate email addresses. | Implemented |
| 1.1.1.2.3 | Users shall be able to have multiple mentorship relationships concurrently. | Implemented |
| 1.1.1.3.1 | Admins shall be able to manage user accounts (e.g., suspend/ban). | Will Be Implemented |
| 1.1.1.3.2 | Admins shall be able to review and process user reports. | Will Be Implemented |
| 1.1.1.3.3 | Admins shall not be able to read private user-to-user messages by default. | Will Be Implemented |
| 1.1.2.1 | Users shall be able to sign up by providing an email address and a password. | Implemented |
| 1.1.2.2 | Email addresses shall be unique across all accounts. | Implemented |
| 1.1.2.3 | User passwords shall meet minimum safety criteria. | Implemented |
| 1.1.2.4 | Users shall be able to log in and log out of the system. | Implemented |
| 1.1.2.5 | The system shall support user authentication via third-party OAuth providers (e.g., Google, Apple, Facebook) in addition to email and password. | Will Be Implemented |
| 1.1.3.1 | Users shall have profile pages. | Implemented |
| 1.1.3.2 | Users shall be able to provide profile information including a description/about section. | Implemented |
| 1.1.3.3 | The system shall support profile fields with visibility settings (public vs. hidden/optional). | Will Be Implemented |
| 1.1.3.4 | Guests shall be able to view only the public parts of user profiles. | Implemented |
| 1.1.3.5 | Users shall be able to edit their profile information. | Implemented |
| 1.1.3.6 | User profiles should include a picture field. | Implemented |
| 1.1.3.7 | The system shall allow users to choose to display only their initials publicly, revealing their full name only to matched users. | Implemented |
| 1.1.4.1 | The system shall support many-to-many mentorship relationships (a user may have multiple mentors |
Implemented |
| 1.1.4.2 | The system shall allow mutual mentorship between two users (a user may mentor another user in one skill while being mentored by the same user in another skill). | Won't Be Implemented |
| 1.1.4.3 | The system shall support mentorship topics/skills as metadata for matching and discovery. | Implemented |
| 1.1.4.4 | The system shall allow users to send mentorship requests to mentors. | Implemented |
| 1.1.4.5 | The system shall allow mentors to accept or reject received mentorship requests. | Implemented |
| 1.1.4.6 | The system shall allow mentors to create specific mentorship "packages" or listings, detailing distinct academic/skill levels and custom cover photos. | Won't Be Implemented |
| 1.1.4.7 | The system shall allow mentees to include a text-based introductory note (cover letter) when submitting a mentorship request, but shall accept submissions where this field is left empty (an empty string). | Implemented |
| 1.1.4.8 | The system shall restrict mentees to having only one active or pending mentorship request per mentor at any given time to prevent spam. | Implemented |
| 1.1.5.1 | Users shall be able to exchange messages with other users. | Implemented |
| 1.1.5.2 | Messages shall be private between the communicating users. | Implemented |
| 1.1.5.3 | The system shall provide a mechanism for users to report problematic communication. | Will Be Implemented |
| 1.1.5.4 | The system shall allow users to share files (e.g., PDFs, images, text, and audio) within the messaging interface and display these files directly within the message history. | Will Be Implemented |
| 1.1.5.5 | The system shall support Markdown formatting for user messages and simple note-taking areas. | Will Be Implemented |
| 1.1.6.1 | The system shall allow mentors and mentees to provide feedback to each other after an interaction. | Implemented |
| 1.1.6.2 | Feedback shall be associated with the relevant mentorship relationship. | Implemented |
| 1.1.6.3 | The system shall update and display a mentor's average public rating only after receiving a defined threshold of new feedback entries (e.g., every 5 reviews) to preserve user anonymity. | Implemented |
| 1.1.6.4 | Feedback shall be anonymized. | Implemented |
| 1.1.7.1 | The system shall provide a notification mechanism to inform users about relevant events. | Implemented |
| 1.1.7.2 | Notifications shall be delivered only to users directly affected by the triggering event. | Implemented |
| 1.1.7.3 | Following events shall create a notification for the Mentor: Receiving a new mentorship request, a Mentee booking a meeting, a Mentee canceling a meeting, a Mentee rescheduling a meeting, a match with a Mentee being deactivated, a new batch of feedback becoming available. | Implemented |
| 1.1.7.4 | Following events shall create a notification for the Mentee: Rejection of a mentorship request, acception of a mentorship request, A Mentor cancelling a meeting, a match with a Mentor being deactivated. | Implemented |
| 1.1.7.5 | Following events shall create a notification for all users: New message received. | Will Be Implemented |
| 1.1.7.6 | Following events shall create a notification for Admins: New report received. | Will Be Implemented |
| 1.1.8.1 |
|
Implemented |
| 1.1.8.2 | Users shall be able to view their upcoming mentorship sessions in the form of a calendar. | Implemented |
| 1.1.8.3 |
|
Implemented |
| 1.1.8.4 | Users shall be able to cancel their upcoming mentorship sessions from the calendar. | Implemented |
| 1.1.8.5 | Users should be able to open the mentor's profile page from the classes shown on the calendar. | Won't Be Implemented |
| 1.1.8.6 | The system should integrate with external calendar services (e.g., Google Calendar) to sync availability and appointments. | Won't Be Implemented |
| 1.1.8.7 | The system shall support scheduling for both one-time meetings and recurring mentorship sessions. | Might Be Implemented |
| 1.1.9.1 | The system should allow mentors to create and schedule collective training sessions (workshops). | Will Be Implemented |
| 1.1.9.2 | The system should allow mentors to define minimum and maximum participant thresholds for workshops. | Will Be Implemented |
| 1.1.9.3 | The system should allow mentees to request group attendance (e.g., bringing friends) for a session, subject to mentor approval. | Will Be Implemented |
| 1.1.10.1 | The system shall allow authenticated users to retrieve their current account context (e.g., id, email, role/mode flags). | Implemented |
| 1.1.10.2 | The system shall allow users to set their active usage mode preference (mentor, mentee, or both) for UI personalization. | Won't Be Implemented |
| 1.1.11.1 | The system shall prevent users from sending mentorship requests to themselves. | Implemented |
| 1.1.11.2 | The system shall support a clear request lifecycle with status transitions (at minimum: pending, accepted, rejected). | Implemented |
| 1.1.11.3 | When a mentor accepts a mentorship request tied to a specific slot, the system shall mark that slot as booked. | Implemented |
| 1.1.11.4 | When a mentorship request is accepted, the system shall create a corresponding match record linking mentor and mentee. | Implemented |
| 1.1.11.5 | When a mentorship request is rejected, the system shall not create a match. | Implemented |
| 1.1.12.1 | The system shall reject availability slots where end time is earlier than or equal to start time. | Implemented |
| 1.1.12.2 | The system shall prevent overlapping availability slots for the same mentor. | Implemented |
| 1.1.12.3 | The system shall not allow booking of an already booked slot. | Implemented |
| 1.1.12.4 | The system shall allow cancellation of booked slots only by authorized users (e.g., booked mentee and/or slot owner). | Implemented |
| 1.1.12.5 | The system shall preserve booking metadata (e.g., who booked and when booked) for booked slots. | Implemented |
| 1.1.13.1 | The system shall provide clear success and failure notifications (e.g., Toast messages or alerts) for all key actions, such as sending mentorship requests, profile updates, or form errors. | Implemented |
| 1.1.13.2 | The system shall enforce stricter validation on all forms to prevent the use of special characters in name fields and numeric-only names. | Will Be Implemented |
| 1.1.14.1 | The system shall provide a "Time Tunnel" interface for matches to visualize their mentorship history. | Will Be Implemented |
| 1.1.14.2 | The Time Tunnel shall display specific data points including session dates, major milestones (e.g., "Learned Python basics," "Hired at Tech Corp"), and human-dimension encounters (e.g., "Met for coffee"). | Will Be Implemented |
| 1.1.15.1 | The system shall issue notifications or warnings to Mentees if they exceed a reasonable number of active mentorships, though no hard limit will be enforced. | Will Be Implemented |
| 1.1.15.2 | The system shall rely on a natural balancing mechanism where Mentor ratings and feedback reflect their capacity to handle multiple mentees. | Implemented |
| 1.2.1.1 | The system shall allow searching mentors by skill/topic. | Implemented |
| 1.2.1.2 | The system shall allow viewing mentor profiles as search results. | Implemented |
| 1.2.1.3 | The system shall allow guests to search and view mentors without authentication. | Will Be Implemented |
| 1.2.1.4 | The system shall allow filtering the mentors by criteria. | Implemented |
| 1.2.1.5 | The system should allow users to view mentor listings on an interactive map interface. | Might Be Implemented |
| 1.2.1.6 | The system should allow users to filter mentors by geographical distance or radius. | Will Be Implemented |
| 1.2.1.7 | The system shall feature dynamic UI lists to improve discovery, such as "Recently Added Listings" and "Popular Mentors". | Implemented |
| 1.2.1.8 | The system shall treat "Groups" or "Campuses" as public tags to facilitate discovery and real-world encounters (e.g., workshops) rather than strictly isolated silos. | Will Be Implemented |
| 1.2.1.9 | The system shall support the creation of "virtual communities" to bridge geographical gaps between users with similar interests. | Will Be Implemented |
| 1.2.2.1 | The system shall provide admins with a report review interface. | Will Be Implemented |
| 1.2.2.2 | The system shall not provide admins direct access to read user messages unless required by a report workflow. | Will Be Implemented |
| 1.2.3.1 | The system shall include a forum feature. | Will Be Implemented |
| 1.2.3.2 | The forum shall support reading content by guests and posting by users. | Will Be Implemented |
| 1.2.4.1 | The system shall provide a web application interface. | Implemented |
| 1.2.4.2 | The system shall provide a mobile application interface. | Implemented |
| 1.2.5.1 | The system should utilize a mapping API (e.g., Google Maps API, OpenStreetMap, or Mapbox) to render location-based mentor discovery. | Might Be Implemented |
| 1.2.6.1 | The system shall issue both access and refresh tokens upon successful authentication. | Implemented |
| 1.2.6.2 | The system shall allow users to refresh expired access tokens using a valid refresh token. | Implemented |
| 1.2.6.3 | The system shall allow admins to view a manageable list of user accounts for moderation workflows. | Will Be Implemented |
| 1.2.6.4 | The system shall support account-level moderation actions such as banning/suspending users. | Will Be Implemented |
| 1.2.6.5 | The system shall prevent banned/suspended users from continuing normal platform interactions according to policy. | Will Be Implemented |
| 1.2.7.1 | The system shall provide OpenAPI-compatible API documentation for backend endpoints. | Implemented |
| 1.2.7.2 | The system shall enforce authorization and ownership checks on protected API endpoints. | Implemented |
| 2.1.1 | The system shall not include monetization features. | Implemented |
| 2.1.2 | The system shall not include skill verification mechanisms (e.g., certification checks). | Implemented |
| 2.1.3 | All third-party libraries used in the project shall be open-source. | Implemented |
| 2.2.1 | Private messages shall not be publicly visible. | Implemented |
| 2.2.2 | The system shall allow users to control the visibility of optional profile fields. | Won't Be Implemented |
| 2.2.3 | The system shall allow users to control the visibility of their profile page | Implemented |
| 2.3.1 | User passwords shall be stored as hashed in the database. | Implemented |
| 2.3.2 | The system shall ensure that one email corresponds to one account. | Implemented |
| 2.4.1 | The system shall comply with the WCAG 2.1 AA accessibility standards. | Implemented |
| 2.5.1 | Critical lifecycle operations (e.g., request acceptance and slot booking) shall be executed atomically to avoid inconsistent states. | Implemented |
| 2.5.2 | Core entities (e.g., mentorship requests, matches, slots, reports) shall include auditable timestamps. | Implemented |
| 2.5.3 | The system shall enforce data integrity constraints to prevent duplicate or conflicting lifecycle records. | Implemented |
- Prioritization by sprint: Unimplemented requirements are categorized and assigned to upcoming sprints based on stakeholder priority and dependency order
- "Will Be Implemented" items (e.g., OAuth login, admin moderation, file sharing, forum, notifications) are scheduled in the next development cycles with defined acceptance criteria already established
- "Might Be Implemented" items (e.g., map-based mentor discovery, recurring sessions) will be evaluated based on remaining time and team capacity before the final release
- "Won't Be Implemented" items (e.g., mutual mentorship, Google Calendar sync, monetization) have been formally documented and communicated to stakeholders as out of scope for the current release
- Regression safety: As new requirements are implemented, the existing Playwright test suite will be extended to ensure previously passing functionality is not broken
- Stakeholder transparency: Implementation status is tracked and reported to stakeholders after each sprint, ensuring no surprises at final delivery
Acceptance Test Details:
- Feature/Epic: [Epic Name]
- Name: [Test Case Name focusing on User Goal]
- Id: [e.g., AT-001]
- Description: [A business-oriented explanation of the user value being verified]
- Prerequisite: [The required system/user state, e.g., "A registered user with a 'Mentee' role is logged in, and there is at least one active Mentor offering 'Python' skills."]
Test Steps:
Generate a markdown table with the following columns: #, Instruction, Expectation, Result, and Note.
| # | Instruction | Expectation | Result | Note |
|---|---|---|---|---|
| 1 | [e.g., As a Mentee, navigate to the mentor discovery page and filter by the 'Python' skill.] | [e.g., The system lists active Python mentors. The user can view their public profile cards.] | ||
| 2 | [e.g., Click 'Request Mentorship' on a mentor's profile, leave the cover letter empty, and submit.] | [e.g., The system successfully submits the request, shows a success notification, and limits the mentee to one active request per mentor (Req: 1.1.4.7 & 1.1.4.8).] |
We will implement a Behavior-Driven Testing (BDD) approach with the following characteristics:
-
Core Principles:
- Stakeholder-centric: Writing tests from customer and user perspectives
- Real-world scenarios: Simulating genuine user workflows and edge cases
- Automated verification: All tests run automatically on every deployment
- Test-first mentality: Acceptance criteria defined before feature development starts
-
Test Execution Cycle:
- Sprint Planning: Acceptance criteria defined collaboratively with stakeholders
- Feature Development: Implementation guided by acceptance criteria
- Acceptance Testing: Automated test suite executes against the feature
- Reporting: Test results documented with pass/fail status and notes
-
Testing Methodologies:
- Functional Testing: Verify that features work as specified
- Regression Testing: Ensure new changes don't break existing functionality
- User Journey Testing: Test complete workflows from user perspective
- Edge Case Testing: Test boundary conditions and error scenarios
- Performance Testing: Verify response times and system performance (<2s for searches)
-
Testing Tools:
-
Playright: Primary end-to-end and acceptance testing framework
- Cross-browser testing (Chromium, Firefox, WebKit)
- Headless & headed execution modes
- Built-in test runner (@playwright/test) with parallel execution support
- Screenshot & video capture on test failure for debugging
- Network interception for mocking API responses
- Accessibility testing via axe-core integration
-
Comparing Playwright Against Selenium:
-
Waiting mechanism: Auto-wait built-in vs manual
WebDriverWaitin Selenium - Speed: Faster execution via CDP protocol vs Selenium's slower WebDriver protocol
-
Test runner: Built-in
@playwright/testvs requires separate JUnit/pytest/TestNG setup - Network mocking: Native support vs requires BrowserMob Proxy in Selenium
- Browser drivers: No separate drivers needed vs chromedriver/geckodriver per browser
- Failure debugging: Auto screenshot, video & trace viewer vs manual implementation in Selenium
- TypeScript support: First-class support vs limited in Selenium
- Flakiness: Low (smart waiting) vs high (timing sensitive) in Selenium
- Cross-browser API: Single unified API vs inconsistent across browsers in Selenium
-
Waiting mechanism: Auto-wait built-in vs manual
-
What acceptance criteria will you use to validate that you are building "the right thing" from a stakeholder/user perspective?
-
Stakeholder-defined criteria: Acceptance criteria are defined collaboratively with stakeholders during sprint planning meetings, ensuring alignment with business goals before development begins
-
Requirement traceability: Each acceptance criterion is directly mapped to a functional requirement gathered from stakeholder meetings, ensuring no requirement is left unverified
-
User story validation: Criteria are written in user story format ("As a [user], I want [feature], so that [benefit]") reflecting real stakeholder needs discussed in meetings
-
Iterative refinement: Acceptance criteria are reviewed and updated after each stakeholder meeting to incorporate feedback and changing requirements
Our project will use fully synthetic data for testing. We avoid using real user data due to privacy and ethical concerns, as mentor–mentee platforms may include sensitive personal information such as profiles, schedules, and interactions.
We do not consider this a limitation, since from a system perspective, test data primarily acts as structured input to exercise functionality. Whether a mentor has 1 skill or 50, or whether a mentee searches for a specific topic, does not affect system correctness. However, to ensure meaningful testing, our synthetic data will still reflect realistic usage patterns.
We will generate synthetic data for:
- mentors and mentees,
- skills and expertise areas,
- biographies and interests,
- availability slots,
- bookings (various states),
- reviews and ratings.
We will use the following methodologies:
-
Scenario-Based Generation:
Data is created around realistic user flows (searching mentors, booking sessions, reviewing mentors). -
Relational Consistency Modeling:
All data respects relationships (e.g., bookings reference valid users and availability). -
Domain-Constrained Randomization:
Random data is limited to realistic domains (e.g., predefined skills in database, working hours, rating distributions). -
Edge Case Injection:
Includes cases such as empty profiles, no availability, fully booked mentors, and extreme ratings. -
Lifecycle-Based Modeling:
Data represents different stages (new users, active bookings, completed sessions). -
Reproducible Generation:
Seeded scripts ensure datasets can be recreated for consistent testing.
We will validate the test data in two ways: technical correctness and realistic structure.
For technical correctness, we will check that:
- required fields are filled,
- user roles are valid,
- mentor and mentee profiles are correctly linked to users,
- availability slots have valid start and end times,
- bookings reference valid users and slots,
- unavailable or already-booked slots cannot be booked again,
- ratings stay within the allowed range.
For realism, we will check that:
- mentor skills match their biographies,
- mentee interests are plausible,
- availability slots resemble real work hours,
- ratings and reviews are not all perfect,
- the dataset includes both new and experienced mentors,
- the dataset includes incomplete, hidden, or low-activity profiles for edge-case testing.
We use fully synthetic but realistic data to avoid ethical concerns while still enabling effective testing. By combining structured generation, realistic constraints, and validation, the dataset supports both functional correctness and realistic usage scenarios.
| Field | Value |
|---|---|
| Feature / Epic | Authentication & Onboarding |
| Name | New User Registers, Completes Profile Onboarding, and Accesses the Platform |
| Id | AT-001 |
| Description | Validates that a brand-new guest can create an account with a unique email and strong password, is guided through a step-by-step onboarding wizard to set up their profile (name, role, bio, skills, username), and is then granted access to the main dashboard. Additionally, validates that a returning user can log in, log out, and that the system enforces role immutability and rejects banned users. This test ensures the platform delivers a seamless first-time experience while enforcing all registration, security, and onboarding requirements defined in the SRS. |
| Prerequisite | 1. The system is running (web frontend + backend API + database). 2. No existing account uses the email alice.newuser@university.edu. 3. At least one skill (e.g., "Python") exists in the skill catalog. 4. An admin account is available for the ban-verification sub-scenario. |
| # | Instruction | Expectation | Result | Note |
|---|---|---|---|---|
| 1 | As a Guest, open the application root URL (/). |
The system displays the landing page. The top navigation bar shows an "UnauthorizedHeader" with links to 'Login' and 'Register'. The guest is not redirected to /dashboard (Req: 1.1.1.1.1, 1.1.1.1.2). |
||
| 2 | Click the 'Register' link or navigate directly to /register. |
The system displays the registration form with the heading "Create your account" containing fields: Email, Password, Confirm password, a Terms of Service checkbox, and a 'Create Account' button (Req: 1.1.2.1). | ||
| 3 | Leave all fields empty and click the 'Create Account' button. | The system does not submit the form. Inline validation errors appear below the Email ("Email is required"), Password ("Password is required"), and Confirm password ("Please confirm your password") fields, plus a terms error. No network request is made (Req: 1.1.13.1). | ||
| 4 | Enter alice.newuser@university.edu in the Email field, type short in the Password field, type short in the Confirm password field, check the Terms checkbox, and click 'Create Account'. |
The system rejects the submission and displays a validation error indicating the password must be at least 8 characters. The form is not submitted to the backend (Req: 1.1.2.3). | ||
| 5 | Clear the Password and Confirm password fields. Enter SecurePass123! in the Password field and DifferentPass456! in the Confirm password field, and click 'Create Account'. |
The system displays an inline validation error: "Passwords do not match" below the Confirm password field. The form does not submit (Req: 1.1.2.3). | ||
| 6 | Correct the Confirm password field to SecurePass123! so both password fields match, and click 'Create Account'. |
The system submits the registration request. The button text changes to "Creating account..." while the request is in flight. Upon success, the system: 1. Returns an access_token and refresh_token in the response (Req: 1.2.6.1). 2. Sets HttpOnly auth cookies for the tokens. 3. Auto-generates a username from the email prefix (e.g., alice_newuser). 4. Creates a Profile record with a display_name derived from the email (e.g., "Alice Newuser"). 5. Redirects the user to the /gettingToKnowYou onboarding page (Req: 1.1.2.1, 1.1.3.1, 2.3.1). |
Password is stored as a hash, not plaintext (Req: 2.3.1). | |
| 7 | Open a second browser tab and attempt to register again with the same email alice.newuser@university.edu. |
The system rejects the registration with a validation error: "A user with this email already exists." The second registration is not created (Req: 1.1.2.2, 2.3.2). |
Important
The user should be at the /gettingToKnowYou route after a successful registration from Part A.
| # | Instruction | Expectation | Result | Note |
|---|---|---|---|---|
| 8 | Verify the onboarding page has loaded at /gettingToKnowYou. |
The system displays a wizard-style interface with a progress bar at the top. The first question shown is: "What's your first name?" with the clarification text "This will appear on your profile." A 'Continue →' button and a '← Back' button are visible (Req: 1.1.3.1, 1.1.3.2). | ||
| 9 | Leave the first name field empty and click 'Continue →'. | The system displays an inline error: "First name must be at least 2 characters." The wizard does not advance to the next step (Req: 1.1.13.1, 1.1.13.2). | ||
| 10 | Type Alice in the first name field and click 'Continue →'. |
The wizard advances. The progress bar updates. The second question is shown: "What's your last name?" (Req: 1.1.3.2). | ||
| 11 | Type Newuser in the last name field and click 'Continue →'. |
The wizard advances to the third question: "How will you use Campus Tutor?" Two large option buttons are shown: 'mentee' and 'mentor' (Req: 1.1.1.2.2). | ||
| 12 | Click 'Continue →' without selecting either option. | The system displays an inline error: "Please select an option." The wizard does not advance (Req: 1.1.13.1). | ||
| 13 | Click the 'mentee' button to select the Mentee role. | The 'mentee' button becomes visually highlighted (primary color, filled background). The 'mentor' button remains unselected (Req: 1.1.1.2.2). | ||
| 14 | Click 'Continue →'. | The wizard advances to the fourth question: "Tell us a bit about yourself." A textarea is shown with placeholder text "Write a short bio..." (Req: 1.1.3.2). | ||
| 15 | Type Short (fewer than 10 characters) and click 'Continue →'. |
The system displays an inline error: "Bio must be at least 10 characters." The wizard does not advance (Req: 1.1.13.1). | ||
| 16 | Clear the bio field and type I am a computer science student looking for mentorship in Python and algorithms. Click 'Continue →'. |
The wizard advances to the skills question: "What topics do you want to learn?" A SkillPicker component is displayed showing available skills from the catalog. Because the user selected 'mentee', the question is specifically about learning topics (Req: 1.1.4.3). | ||
| 17 | Click 'Continue →' without selecting any skill. | The system displays an inline error: "Please select at least one topic." The wizard does not advance. | ||
| 18 | Select the skill 'Python' from the skill picker (and optionally additional skills), then click 'Continue →'. | The wizard advances to the final question: "Choose a username." An input field is pre-populated with the email prefix (e.g., alice_newuser). Below it, a preview shows: https://neighborship.app/profiles/alice_newuser (Req: 1.1.3.1). |
||
| 19 | Clear the username field and type a (fewer than 3 characters), then click 'Continue →' (now labeled 'Finish'). |
The system displays an inline error: "Username must be at least 3 characters." The wizard does not submit (Req: 1.1.13.2). | ||
| 20 | Clear the username field and type alice@invalid! (contains special characters), then click 'Finish'. |
The system displays an inline error: "Username can only contain letters, numbers, underscores, and hyphens." The wizard does not submit (Req: 1.1.13.2). | ||
| 21 | Clear the username field and type alice_newuser, then click 'Finish'. |
The system sequentially: 1. Calls PATCH /api/auth/me/role/ to set app_usage_mode to MENTEE (Req: 1.1.1.2.2). 2. Calls PATCH /api/profiles/me/ to update display_name to "Alice Newuser", bio, and skills (Req: 1.1.3.2, 1.1.3.5). 3. Calls PATCH /api/profiles/me/username/ to set the username (Req: 1.1.3.1). 4. Redirects the user to /dashboard. The button shows "Saving..." during submission (Req: 1.1.13.1). |
||
| 22 | Verify the /dashboard page has loaded. |
The system displays the main authorized layout with the AuthorizedHeader navigation bar. The user's avatar/initials and the dashboard content are visible. The user has completed onboarding successfully (Req: 1.1.10.1, 1.2.4.1). |
Important
Prerequisite: The user alice.newuser@university.edu exists with password SecurePass123!, role MENTEE, and has completed onboarding.
| # | Instruction | Expectation | Result | Note |
|---|---|---|---|---|
| 23 | Log out from the current session by triggering the logout action. | The system: 1. Blacklists the current refresh token on the backend (HTTP 205). 2. Clears auth cookies from the browser. 3. Removes the stored user from local storage. 4. Redirects the user to /login (Req: 1.1.2.4). |
||
| 24 | While logged out, attempt to navigate directly to /dashboard by typing the URL in the address bar. |
The system redirects the user to /login because no stored user/token is present. The dashboard content is not accessible to unauthenticated users (Req: 1.2.7.2). |
||
| 25 | On the /login page, verify the form structure. |
The system displays a card with the title "Login to your account", an Email input, a Password input, a 'Sign in' button, a 'Continue with Google' OAuth button, and a "No account yet? Sign up free" link (Req: 1.1.2.4, 1.1.2.5). | ||
| 26 | Enter wrong@university.edu in the Email field and SecurePass123! in the Password field, then click 'Sign in'. |
The system displays an error message: "Invalid email or password." The user is not authenticated (Req: 1.1.2.4, 1.1.13.1). | ||
| 27 | Correct the email to alice.newuser@university.edu but enter the wrong password WrongPassword!, then click 'Sign in'. |
The system displays an error message: "Invalid email or password." The user is not authenticated. The system does not reveal whether the email or password was incorrect (Req: 1.1.2.4). | ||
| 28 | Enter the correct password SecurePass123! and click 'Sign in'. |
The system: 1. Returns access_token and refresh_token (Req: 1.2.6.1). 2. Sets HttpOnly auth cookies. 3. The button shows "Signing in..." during the request. 4. Redirects the user directly to /dashboard (since app_usage_mode is already set, the onboarding page is skipped) (Req: 1.1.2.4, 1.1.10.1). |
||
| 29 | On the dashboard, verify the account context by calling GET /api/auth/me/. |
The response includes: id, email (alice.newuser@university.edu), username (alice_newuser), role (USER), app_usage_mode (MENTEE), is_active (true), and created_at timestamp (Req: 1.1.10.1, 2.5.2). |
Important
The user alice.newuser@university.edu is logged in with app_usage_mode = MENTEE.
| # | Instruction | Expectation | Result | Note |
|---|---|---|---|---|
| 30 | As Alice (a Mentee), attempt to change role to Mentor by sending PATCH /api/auth/me/role/ with {"app_usage_mode": "MENTOR"}. |
The system rejects the request with a 400 Bad Request and error message: "Account role is immutable. Create a separate account to use the other role." The app_usage_mode remains MENTEE (Req: 1.1.1.2.2). |
This enforces the one-role-per-account policy. | |
| 31 | Send the same PATCH request but with {"app_usage_mode": "MENTEE"} (the current role). |
The system accepts the request with 200 OK and returns the user object unchanged. Setting the same role is idempotent (Req: 1.1.1.2.2). |
Important
Prerequisite: An admin bans the account alice.newuser@university.edu via PUT /api/auth/admin/users/ or the admin panel.
| # | Instruction | Expectation | Result | Note |
|---|---|---|---|---|
| 32 | As an Admin, ban Alice's account by setting is_banned = true. |
The admin action succeeds. Alice's is_banned field is now true in the database (Req: 1.1.1.3.1, 1.2.6.4). |
||
| 33 | As Alice (using her existing tokens), attempt to call GET /api/auth/me/. |
The system returns 403 Forbidden because the IsNotBanned permission check blocks the request (Req: 1.2.6.5). |
||
| 34 | As Alice, attempt to refresh the access token by calling POST /api/auth/token/refresh/ with a valid refresh token. |
The system returns 403 Forbidden with message: "This account has been banned." The BannedAwareTokenRefreshSerializer blocks token refresh for banned users (Req: 1.2.6.2, 1.2.6.5). |
||
| 35 | Clear Alice's local tokens/cookies and attempt a fresh login at /login with the correct email and password. |
The system rejects the login with the error: "This account is banned." No tokens are issued. The user cannot access any authenticated route (Req: 1.2.6.5). |
| Requirement ID | Requirement Summary | Covered in Step(s) |
|---|---|---|
| 1.1.1.1 | Three user types (guests, users, admins) | 1, 32 |
| 1.1.1.1.1 | Guests cannot initiate communication | 1 |
| 1.1.1.1.2 | Guests can register | 2, 6 |
| 1.1.1.2.1 | Users authenticate with email and password | 28 |
| 1.1.1.2.2 | One role per account (Mentor or Mentee) | 13, 21, 30, 31 |
| 1.1.1.3.1 | Admins manage user accounts | 32 |
| 1.1.2.1 | Sign up with email and password | 2, 6 |
| 1.1.2.2 | Email uniqueness | 7 |
| 1.1.2.3 | Password minimum safety criteria | 4, 5 |
| 1.1.2.4 | Login and logout | 23, 25, 28 |
| 1.1.2.5 | Third-party OAuth support | 25 |
| 1.1.3.1 | Users have profile pages | 6, 18, 22 |
| 1.1.3.2 | Profile description/about section | 8, 10, 11, 14, 16, 21 |
| 1.1.3.5 | Users can edit profile information | 21 |
| 1.1.4.3 | Skills/topics as metadata | 16, 18 |
| 1.1.10.1 | Retrieve current account context | 22, 29 |
| 1.1.13.1 | Clear success/failure notifications | 3, 9, 12, 15, 21, 26 |
| 1.1.13.2 | Stricter form validation | 9, 19, 20 |
| 1.2.4.1 | Web application interface | 22 |
| 1.2.6.1 | Access and refresh tokens upon auth | 6, 28 |
| 1.2.6.2 | Refresh expired tokens | 34 |
| 1.2.6.4 | Account-level moderation (ban/suspend) | 32 |
| 1.2.6.5 | Banned users blocked from interactions | 33, 34, 35 |
| 1.2.7.2 | Authorization on protected endpoints | 24, 33 |
| 2.3.1 | Passwords stored as hashes | 6 |
| 2.3.2 | One email per account | 7 |
| 2.5.2 | Auditable timestamps on entities | 29 |
Acceptance Test Details:
- Feature/Epic: Notifications: Checking and marking real-time alerts
- Name: Mentor reviews a new mentorship request alert and clears it after checking
- Id: AT-002
- Description: This test verifies that a mentor can notice a newly arrived alert for an important mentorship event, review it quickly, continue to the related workflow, and keep a readable history after the alert is checked. This confirms the notification flow supports timely mentor response and reduces the risk of missed requests.
-
Prerequisite: A registered user with a
Mentorrole is logged in on the mobile app, has no unread notifications, has at least one older read notification in history, and aMenteeaccount is ready to submit a new mentorship request to that mentor.
Test Steps:
| # | Instruction | Expectation | Result | Note |
|---|---|---|---|---|
| 1 | As a Mentor, remain signed in on any app page while the Mentee submits a new mentorship request to you from another account. | The system should show a notification bell badge with 1 unread alert shortly after the request is submitted, without requiring the mentor to sign in again or restart the app (Req: real-time alert delivery for a new mentorship request). |
||
| 2 | As a Mentor, tap the notification bell. | The system should open the /notifications screen and show the mentor's notifications only. The new mentorship request alert should appear before older read items because unread alerts are prioritized (Req: authenticated notification access, unread-first ordering, recent notification history). |
||
| 3 | As a Mentor, review the first notification item in the list. | The system should show a clear request-related title and message, display the item as unread, and provide an obvious next action such as View details so the mentor understands what happened and what to do next (Req: meaningful and actionable notification content). |
||
| 4 | As a Mentor, tap the new mentorship request notification. | The system should open the Connections area so the mentor can review the incoming request, and it should mark the notification as read as part of checking it (Req: checking a notification marks it as read and opens the related workflow). |
||
| 5 | As a Mentor, return to the /notifications screen. |
The system should keep the same notification in recent history, but it should now appear as read and no longer count toward unread alerts (Req: read-state persistence and read history retention). | ||
| 6 | As a Mentor, wait for the normal refresh cycle or revisit the notifications screen after navigating away and back. | The system should keep the notification in the read state and should not show it as unread again unless a new event occurs (Req: stable persistence of notification status across refreshes). |
Acceptance Test Details:
- Feature/Epic: Meeting Session Management
- Name: Participants Keep a Shared, Accurate Schedule When a Session Is Viewed, Rescheduled, and Canceled
- Id: AT-001
- Description: This test verifies that mentor and mentee can rely on the platform as the source of truth for upcoming mentorship sessions when plans change. It confirms that users can view their sessions from the calendar, reschedule to a valid mentor availability slot, receive relevant notifications, and cancel the session without leaving stale bookings behind.
-
Prerequisite: A registered user with a
Menteerole and a registered user with aMentorrole are logged in on separate devices or browser sessions. They have an accepted mentorship match with one upcoming session on June 3, 2026, 14:00-15:00. The mentor also has an available future slot on June 5, 2026, 10:00-11:00, and at least one already-booked slot that must not be selectable.
Test Steps:
| # | Instruction | Expectation | Result | Note |
|---|---|---|---|---|
| 1 | As a Mentee, click the Schedule navigation item and open the calendar view. |
The system should show the mentee’s upcoming mentorship session with the mentor name, session date, start time, end time, and current scheduled status. The system should show only sessions involving this mentee. (Req: 1.1.8.2, 1.2.7.2) | ||
| 2 | As a Mentee, open the session scheduled for June 3, 2026, 14:00-15:00. | The system should display the session details and provide clear actions to reschedule or cancel the upcoming session from the calendar context. (Req: 1.1.8.3, 1.1.8.4) | ||
| 3 | As a Mentee, click the mentor profile link from the session details or calendar entry. | The system should open the mentor’s profile page so the mentee can review mentor context before changing the session. (Req: 1.1.8.5, 1.1.3.1) | ||
| 4 | As a Mentee, return to the session details and click Reschedule. |
The system should show valid future availability slots for the same mentor, including June 5, 2026, 10:00-11:00, and should not allow selection of already-booked or unavailable slots. (Req: 1.1.8.3, 1.1.12.3) | ||
| 5 | As a Mentee, select June 5, 2026, 10:00-11:00 and confirm the reschedule. | The system should successfully reschedule the session, show a clear success notification, update the mentee calendar to the new date and time, free the old slot, and book the new slot. (Req: 1.1.8.3, 1.1.11.3, 1.1.12.5, 1.1.13.1) | ||
| 6 | As a Mentor, open notifications after the mentee reschedules the session. | The system should notify the mentor that the affected session was rescheduled, and the notification should be delivered only to users directly involved in the session. (Req: 1.1.7.1, 1.1.7.2) | ||
| 7 | As a Mentor, click the Schedule navigation item and open the calendar view. |
The system should show the same session at June 5, 2026, 10:00-11:00 in the mentor’s calendar, matching the mentee’s updated session details. (Req: 1.1.8.2, 1.1.8.3) | ||
| 8 | As a Mentor, open the rescheduled session and click Cancel. |
The system should present a clear confirmation step before canceling the upcoming mentorship session for both participants. (Req: 1.1.8.4, 1.1.13.1) | ||
| 9 | As a Mentor, confirm the cancellation. | The system should cancel the session, show a clear success notification, mark the session as canceled, release the booked slot, and prevent further reschedule or cancel actions on that canceled session. (Req: 1.1.8.4, 1.1.12.4, 1.1.13.1) | ||
| 10 | As a Mentee, refresh the calendar and open notifications. | The system should show the session as canceled rather than active/upcoming, and should notify the mentee that the session was canceled. The notification should not be visible to unrelated users. (Req: 1.1.7.1, 1.1.7.2, 1.1.8.2, 1.1.8.4) |
Feature/Epic: Availability & Booking: Slot management and booking workflows, including conflict resolution
Name: Mentor Publishes Weekly Availability and Mentee Successfully Books a Session Within Business Rules
Id: AT-AVAIL-004
Description: This test validates the end-to-end collaborative booking workflow from both sides of the platform. It confirms that a mentor can define and publish their weekly availability, that a mentee can discover and book a specific slot with or without a cover letter, and that both parties receive correct system feedback at each step. The test explicitly validates the business rules preventing expired bookings, duplicate requests, and unauthorized slot access — ensuring the platform delivers its core value of structured, conflict-free mentorship scheduling.
Prerequisite:
- A registered Mentor user (role: MENTOR, app_usage_mode: MENTOR, username: "dr_ayse") is logged in, has completed profile setup with at least one skill: "Machine Learning"
- A registered Mentee user (role: MENTEE, app_usage_mode: MENTEE, username: "cem_mentee") is logged in (separate session)
- Current system date is April 30, 2026
- No availability slots exist yet for "dr_ayse"
- No prior mentorship requests or sessions exist between these two users
Test Steps:
| # | Instruction | Expectation | Result | Note |
|---|---|---|---|---|
| 1 | As the Mentor ("dr_ayse"), navigate to the profile or availability management page by clicking "Manage Availability" from the main navigation. | The availability calendar page loads and displays an empty state message: "You have no availability slots yet." A clearly visible "Add Slot" or "Create Slot" button is present. No slots appear on the calendar. | Validates that a newly onboarded mentor starts with a clean availability state | |
| 2 | Click the "Add Slot" button. In the slot creation form, set Date: May 10, 2026, Start Time: 14:00, End Time: 15:00. Click "Save". | The system creates the slot and displays a success notification: "Slot added: May 10, 14:00–15:00." The calendar immediately reflects the new slot with a green/AVAILABLE indicator. The slot is now publicly discoverable. | Validates Req 1.1.4.1: mentors can create time slots; slot is visible on calendar | |
| 3 | Click the "Add Slot" button again. Set Date: May 10, 2026, Start Time: 14:30, End Time: 15:30 (intentionally overlapping with the first slot). Click "Save". | The system rejects the submission and displays an inline error: "This slot overlaps with an existing slot (14:00–15:00). Please choose a different time." The conflicting slot is NOT created. The calendar remains unchanged with one slot. | Validates Req 1.1.4.4: overlap prevention on the mentor side | |
| 4 | Create a second valid slot: Date: May 10, 2026, Start Time: 15:00, End Time: 16:00. Click "Save". | The second slot is created successfully. Calendar now shows two consecutive, non-overlapping slots on May 10: 14:00–15:00 and 15:00–16:00. Both display as AVAILABLE. | Confirms consecutive slots with exact boundary times are accepted | |
| 5 | Create a third slot in the past: Date: April 10, 2026, Start Time: 10:00, End Time: 11:00. Click "Save". | The form either rejects the past date with an error: "Cannot create a slot for a past date." or the date picker prevents selecting past dates entirely. No slot is created. | Validates Req 1.1.4.3: past-date slot creation should be blocked | |
| 6 | Switch to the Mentee session ("cem_mentee"). Navigate to the Discover page from the main navigation and search for "Machine Learning" in the skills filter. | The Discover page loads with matching results. "dr_ayse"'s profile card is visible in the results showing her name, the "Machine Learning" skill badge, rating, and a "View Profile" button. Search results load in under 2 seconds. | Validates Req 1.1.5.1 and 1.1.5.3: mentor discovery and skill filtering within performance threshold | |
| 7 | Click the "View Profile" button on "dr_ayse"'s profile card. | The mentor profile detail page loads, displaying: full name, bio, skills (Machine Learning), rating, total reviews, and an availability calendar section showing both May 10 slots (14:00–15:00 and 15:00–16:00) with green AVAILABLE indicators and enabled "Book" buttons. | Validates Req 1.1.5.4: complete mentor profile is visible to mentees, availability is surfaced | |
| 8 | In the availability calendar, locate the past-date slot if visible (April 10, 10:00–11:00). Attempt to click its "Book" button. | The April 10 slot either does not appear in the calendar (filtered out by the system), or is displayed in a gray/disabled state with its "Book" button disabled. Clicking the disabled button produces no action. A tooltip or label reads: "This slot has passed." | Validates Req 1.1.4.5: past slots cannot be booked; UI communicates this clearly | |
| 9 | Click the "Book" button on the May 10 14:00–15:00 slot. | A booking request modal appears with pre-filled read-only fields: Mentor name ("dr_ayse"), Slot date and time (May 10, 2026, 14:00–15:00). An optional "Cover Letter" text area is present. A "Send Request" button and a "Cancel" button are visible. | Validates Req 1.1.4.6: booking workflow is initiated with slot details | |
| 10 | Leave the Cover Letter field completely empty. Click "Send Request". | The system accepts the request without requiring a cover letter. A success notification displays: "Mentorship request sent to dr_ayse." The modal closes. The mentee is NOT redirected away from the profile page. | Validates Req 1.1.4.7: cover letter is optional; request succeeds with empty field | |
| 11 | Navigate to the Dashboard by clicking "Dashboard" in the main navigation. Locate the "My Requests" or "Sent Requests" section. | The dashboard shows the newly sent request: Mentor "dr_ayse", Slot: May 10, 14:00–15:00, Status badge: "PENDING". The cover letter field displays as "No cover letter provided." | Confirms mentee can track request status post-submission | |
| 12 | Return to "dr_ayse"'s profile page and attempt to click "Book" on the May 10 15:00–16:00 slot (the second slot). | The "Book" button on all of dr_ayse's remaining slots is now disabled. Clicking it triggers an error notification: "You already have a pending request with this mentor. Please wait for a response before sending another." A second request is NOT created. | Validates Req 1.1.4.8: one active PENDING request per mentee per mentor at a time | |
| 13 | Switch to the Mentor session ("dr_ayse"). Navigate to the Dashboard and locate the incoming requests section. | The dashboard displays a pending request from "cem_mentee": slot May 10, 14:00–15:00, cover letter shown as empty/none. An unread notification badge is visible. Two action buttons are present: "Accept" and "Decline". | Validates that mentors receive booking requests and can act on them per Req 1.1.4.9 | |
| 14 | As the Mentor, click the "Accept" button on cem_mentee's request. | The system updates the request status to "ACCEPTED". A success toast displays: "Request accepted. Session confirmed with cem_mentee for May 10, 14:00–15:00." The May 10 14:00–15:00 slot status changes from AVAILABLE to BOOKED and is no longer displayed as bookable to other mentees. A notification is sent to cem_mentee. | Validates Req 1.1.4.10: acceptance creates a confirmed session and slot becomes unavailable | |
| 15 | Switch back to the Mentee session ("cem_mentee"). Check the Dashboard and the notification center. | The Dashboard's "Upcoming Sessions" section shows: "Session with dr_ayse — May 10, 2026, 14:00–15:00 — CONFIRMED." A notification reads: "dr_ayse has accepted your mentorship request. Your session is scheduled for May 10, 2026 at 14:00." The previously PENDING request badge has updated to ACCEPTED. | Validates Req 1.1.4.11: mentee is notified of acceptance and session appears in their calendar |
Feature/Epic: Messaging: In-app conversation management and moderation (reporting)
Name: Matched Mentor and Mentee Exchange Messages in a Private Conversation and Mentee Successfully Reports an Abusive Message
Id: AT-MSG-001
Description: This test validates that the in-app messaging system serves its core business purpose: enabling trusted, private communication exclusively between users who have an active mentorship relationship, while providing a safe reporting mechanism to protect users from harassment or abuse. It confirms that unmatched users cannot initiate conversations, message history is persisted and accessible, and that a reported message is flagged for moderation — upholding the platform's commitment to a safe mentoring environment.
Prerequisite:
- A confirmed mentorship match exists between Mentor user "dr_ayse" (role: MENTOR) and Mentee user "cem_mentee" (role: MENTEE) — their mentorship request has been ACCEPTED and a session is in CONFIRMED state
- A third user "unrelated_user" (role: MENTEE) exists but has NO mentorship relationship with "dr_ayse"
- All three users are registered and active
- No prior messages exist between any of these users
Test Steps:
| # | Instruction | Expectation | Result | Note |
|---|---|---|---|---|
| 1 | As "cem_mentee", navigate to the "Messages" or "Inbox" page by clicking the messages icon in the main navigation bar. | The Messages page loads and displays a conversation list panel on the left and an empty chat panel on the right. A conversation thread with "dr_ayse" is visible in the list (automatically created upon match confirmation). An empty state message such as "No messages yet. Say hello!" is shown in the chat panel. | Validates that matched users have a pre-created conversation thread; no manual initiation needed | |
| 2 | Click on the conversation thread with "dr_ayse". | The chat panel opens for the "dr_ayse" conversation. The mentor's name, avatar, and title are shown in the chat header. A message input text box and a "Send" button are visible at the bottom. The conversation body is empty. | Confirms conversation detail view loads correctly for matched users | |
| 3 | Type the message "Hello dr_ayse! Looking forward to our session on May 10." in the message input box. Click the "Send" button. | The system sends the message and it immediately appears in the chat panel as a sent message (right-aligned, with a timestamp). The message input box clears. No page reload occurs. The conversation list on the left updates to show this message as the latest preview. | Validates core message sending functionality and real-time UI update | |
| 4 | Switch to the Mentor session ("dr_ayse"). Navigate to the "Messages" page. | The Messages page loads. The conversation list shows "cem_mentee"'s thread at the top with an unread indicator (bold text or badge). The preview text matches the last message: "Hello dr_ayse! Looking forward to our session on May 10." | Validates that sent messages are delivered and unread state is surfaced to the recipient | |
| 5 | As "dr_ayse", click on the conversation with "cem_mentee". | The chat panel opens showing cem_mentee's message: "Hello dr_ayse! Looking forward to our session on May 10." The unread indicator is cleared. The message is displayed with the correct sender name, avatar, and timestamp. | Confirms message delivery and read-state management | |
| 6 | As "dr_ayse", type "Thank you Cem! I have prepared some Python exercises for you." in the input box and click "Send". | The reply appears immediately in dr_ayse's chat panel as a sent message. The conversation thread is updated. | Validates mentor can reply within the same conversation thread | |
| 7 | Switch back to the "cem_mentee" session. Without refreshing, observe whether the mentor's reply appears. | The mentor's reply "Thank you Cem! I have prepared some Python exercises for you." appears in the chat panel, either in real-time via WebSocket or within the polling interval. The conversation remains in the correct chronological order. | Validates message delivery to the mentee side; confirms conversation ordering | |
| 8 | As "cem_mentee", refresh the browser page (F5) and navigate back to the "dr_ayse" conversation. | The full conversation history is persisted and displayed correctly: cem_mentee's first message followed by dr_ayse's reply, both with accurate timestamps. No messages are lost after page refresh. | Validates Req: message history persistence; users can access past messages at any time | |
| 9 | Switch to the "unrelated_user" session. Navigate to the "Messages" page. | The Messages page loads with an empty conversation list or a list that does NOT include a thread with "dr_ayse". No "New Message" or "Start Conversation" button for arbitrary users is present, or if a user search exists, initiating a conversation with "dr_ayse" is blocked. | Validates Req: messaging is restricted to matched users only; unmatched users cannot initiate conversations | |
| 10 | As "unrelated_user", attempt to directly access the conversation URL for dr_ayse (e.g., /messages/dr_ayse) if the URL pattern is guessable. |
The system returns a 403 Forbidden response or redirects to the Messages page with an error: "You do not have an active mentorship relationship with this user." No message content from the dr_ayse/cem_mentee conversation is exposed. | Validates access control enforcement at the route/API level; prevents unauthorized message access | |
| 11 | Switch back to "cem_mentee". In the conversation with "dr_ayse", hover over or long-press dr_ayse's message "Thank you Cem!..." to reveal message action options. | A context menu or action toolbar appears with at least the following option: "Report Message" (and optionally "Copy"). The actions are accessible without leaving the conversation view. | Validates that the reporting affordance is present on received messages per moderation requirements | |
| 12 | Click the "Report Message" option on dr_ayse's message. | A moderation report modal/dialog appears with a dropdown or list of report reasons, such as: "Harassment", "Inappropriate content", "Spam", "Other". A free-text "Additional details" field is also visible. A "Submit Report" button and a "Cancel" button are present. | Validates the reporting workflow initiation and available moderation categories | |
| 13 | Select "Inappropriate content" as the report reason. Leave the "Additional details" field empty. Click "Submit Report". | The report is successfully submitted. The modal closes and a confirmation notification displays: "Your report has been submitted. Our moderation team will review it." The conversation and the reported message remain visible and usable — the mentee is not blocked from the conversation during review. | Validates Req: report can be filed without a mandatory description; user experience is not disrupted post-report | |
| 14 | As "cem_mentee", attempt to report the same message a second time. | The "Report Message" option is either disabled on the already-reported message, or clicking it shows: "You have already reported this message." A duplicate report is NOT created. | Validates idempotency of the report action; prevents spam-reporting | |
| 15 | As "cem_mentee", send five more messages in rapid succession to dr_ayse. | All five messages are sent and appear in the conversation in the correct order, without duplication or missing messages. The system handles rapid input gracefully with no errors or dropped messages. | Validates message ordering and system stability under quick sequential sends |
Feature/Epic: Mentorship Requests & Matching: Sending, accepting, declining requests, and managing active matches
Name: Mentee Sends a Mentorship Request with a Cover Letter, Mentor Accepts It to Form an Active Match, and System Enforces One-Request-Per-Mentor Rule
Id: AT-REQ-001
Description: This test validates the full lifecycle of a mentorship request from both the mentee's and mentor's perspectives. It confirms that a mentee can express genuine intent by writing a cover letter, that the mentor receives the request with all necessary context to make an informed decision, and that upon acceptance a formal active match is established between the two users. It also validates the platform's integrity rules — specifically that a mentee cannot flood a single mentor with multiple requests — ensuring the system builds trustworthy, intentional mentorship relationships rather than transactional spam.
Prerequisite:
- Mentor user "sara_mentor" (role: MENTOR, app_usage_mode: MENTOR) is registered, active, and has completed profile setup with skill "Web Development" and at least one AVAILABLE slot on May 12, 2026, 10:00–11:00
- Mentee user "leo_mentee" (role: MENTEE, app_usage_mode: MENTEE) is registered and active
- A second Mentee user "other_mentee" (role: MENTEE) is registered and active
- No prior mentorship requests or matches exist between any of these users
Test Steps:
| # | Instruction | Expectation | Result | Note |
|---|---|---|---|---|
| 1 | As "leo_mentee", navigate to the Discover page by clicking "Discover" in the main navigation bar. In the skill filter, select "Web Development" and click the "Search" button. | The system filters the mentor list and displays "sara_mentor"'s profile card among the results, showing her name, "Web Development" skill badge, rating, and a "View Profile" button. Results load within 2 seconds. | Validates mentor is discoverable by skill; Req 1.1.5.1 & 1.1.5.3 | |
| 2 | Click the "View Profile" button on "sara_mentor"'s profile card. | Sara's full mentor profile page loads, displaying her name, bio, skills, rating, and an availability calendar section showing the May 12 slot (10:00–11:00) with AVAILABLE status and an enabled "Book" button. | Validates complete mentor profile is visible to mentees; Req 1.1.5.4 | |
| 3 | Click the "Book" button on the May 12, 10:00–11:00 availability slot. | A mentorship request modal appears with pre-filled read-only fields: Mentor ("sara_mentor"), Slot (May 12, 2026, 10:00–11:00). An optional "Cover Letter" text area with placeholder text such as "Introduce yourself and describe your goals…" is visible. "Send Request" and "Cancel" buttons are present. | Validates booking modal surfaces cover letter option; Req 1.1.4.6 | |
| 4 | In the "Cover Letter" field, type: "Hi Sara, I am a junior frontend developer looking to improve my React skills. I would love your guidance on component architecture and best practices." Click the "Send Request" button. | The system submits the request. A success notification appears: "Mentorship request sent to sara_mentor." The modal closes. leo_mentee remains on sara_mentor's profile page without being redirected. | Validates successful request submission with cover letter; Req 1.1.4.7 | |
| 5 | Navigate to the Dashboard by clicking "Dashboard" in the main navigation. Locate the "My Requests" or "Sent Requests" section. | The dashboard displays the newly sent request: Mentor "sara_mentor", Slot: May 12, 2026, 10:00–11:00, Status badge: "PENDING", Cover letter preview visible. The request appears as the most recent entry. | Confirms mentee can track their own request status post-submission; Req 1.1.4.8 | |
| 6 | Return to "sara_mentor"'s profile page. Attempt to click the "Book" button on her remaining available slots (if any exist). | All "Book" buttons on sara_mentor's profile are disabled or clicking any of them triggers an error notification: "You already have a pending request with sara_mentor. Please wait for a response before sending another." No second request is created. | Validates one-active-request-per-mentor rule; Req 1.1.4.8 | |
| 7 | Switch to the Mentor session ("sara_mentor"). Navigate to the Dashboard. | The Dashboard displays an unread notification badge and a "Pending Requests" section showing one incoming request from "leo_mentee" for May 12, 10:00–11:00. The request card shows leo_mentee's display name, proposed slot date and time, and a truncated cover letter preview. | Validates mentor receives request with full context for decision-making; Req 1.1.4.9 | |
| 8 | As "sara_mentor", click "View Details" on leo_mentee's request card. | A request detail modal opens showing: Mentee name ("leo_mentee"), profile picture, proposed slot (May 12, 2026, 10:00–11:00), and the full cover letter text: "Hi Sara, I am a junior frontend developer…". Two action buttons are visible: "Accept" and "Decline". | Confirms mentor sees complete request context including full cover letter before deciding | |
| 9 | Click the "Accept" button. | The system updates the request status to ACCEPTED. A success toast displays: "Request accepted. A session with leo_mentee is now confirmed for May 12, 10:00–11:00." The request card in the dashboard updates its badge to "ACCEPTED". The May 12 slot status changes from AVAILABLE to BOOKED. The "Accept" and "Decline" buttons are disabled. | Validates acceptance transitions request status and locks the slot; Req 1.1.4.10 | |
| 10 | As "sara_mentor", navigate to "My Matches" or check the "Active Mentorships" section on the dashboard. | "leo_mentee" appears in the active matches list. The match entry shows mentee name, matched date (today), and the confirmed session date (May 12, 2026). The match status is "ACTIVE". | Validates that acceptance creates a formal active match record; Req 1.1.6.1 | |
| 11 | Switch back to the "leo_mentee" session. Check the notification center by clicking the bell icon in the navigation bar. | An unread notification is present: "sara_mentor has accepted your mentorship request. Your session is confirmed for May 12, 2026 at 10:00." The notification includes sara_mentor's name and links to the session detail or dashboard. | Validates mentee is notified of acceptance in real time; Req 1.1.4.11 | |
| 12 | As "leo_mentee", navigate to the Dashboard and locate the "Upcoming Sessions" section. | The confirmed session is listed: "Session with sara_mentor — May 12, 2026, 10:00–11:00 — Status: CONFIRMED." The session entry is NOT shown as PENDING anymore. | Confirms session appears on mentee dashboard post-acceptance; Req 1.1.4.11 | |
| 13 | Switch to the "other_mentee" session. Navigate to sara_mentor's profile page and observe the May 12 slot. | The May 12, 10:00–11:00 slot is no longer displayed as AVAILABLE. It is either hidden from public view, shown as BOOKED/UNAVAILABLE with a disabled "Book" button, or excluded from the calendar entirely. "other_mentee" cannot book the already-confirmed slot. | Validates slot is removed from public availability after acceptance; Req 1.1.4.10 | |
| 14 | As "other_mentee", send a fresh mentorship request to sara_mentor for a different available slot (if one exists). | The request is accepted by the system normally. This confirms the one-request rule is scoped per mentee–mentor pair and does not globally block other mentees from sending requests to the same mentor. | Validates rule is per-pair, not global; prevents over-restriction | |
| 15 | Switch back to "sara_mentor". Navigate to the Pending Requests section and attempt to click "Accept" or "Decline" on leo_mentee's already-accepted request. | Both "Accept" and "Decline" buttons are disabled and non-interactive. Hovering over them shows a tooltip: "This request has already been responded to." No duplicate action is processed. | Validates idempotency of request response actions; prevents accidental double-processing |
Acceptance Test Details:
- Feature/Epic: Mentor Discovery
- Name: As a Mentee, Find the Right Mentor by Skill, Popularity, and Recency
- Id: AT-001
- Description: This acceptance test verifies that a mentee can efficiently discover relevant mentors based on learning goals, trust signals, and freshness of mentor supply. It confirms business value by ensuring the mentee can move from broad browsing to confident mentor shortlisting using skill filters, popularity ranking, and recently added criteria.
- Prerequisite: A registered user with a Mentee role is logged in. There are at least 6 active and visible Mentor profiles in the system, including: (1) mentors with the skill "Python", (2) mentors with different average ratings and mentee counts, and (3) mentors created at different dates/times (at least one newly added mentor in the last 7 days).
| # | Instruction | Expectation | Result | Note |
|---|---|---|---|---|
| 1 | As a Mentee, tap the "Discover" tab from the main navigation. | The system should open the mentor discovery view and show mentor profile cards that can be browsed without errors. (Req: Mentor Discovery - Browse Mentors) | ||
| 2 | As a Mentee, verify the default discovery list before applying any filters. | The system should show only active, visible Mentor profiles in the default list, so hidden or non-mentor accounts are not displayed. (Req: Mentor Discovery - Visibility and Role Constraints) | ||
| 3 | As a Mentee, select the "Python" skill from the skill filter control. | The system should refresh results and show only mentors who provide the selected skill, matching the user’s learning intent. (Req: Mentor Discovery - Skill-Based Search/Filtering) | ||
| 4 | As a Mentee, add another skill filter (for example, "Django") while keeping "Python" selected. | The system should keep results relevant to the selected skill criteria and clearly reflect active filters so the user understands why mentors are shown. (Req: Mentor Discovery - Multi-Criteria Filtering Usability) | ||
| 5 | As a Mentee, clear all selected skill filters. | The system should remove filter constraints and return to the broader mentor list without requiring page reload or re-login. (Req: Mentor Discovery - Filter Reset) | ||
| 6 | As a Mentee, switch to the "Popular" mentor browsing criterion. | The system should show mentors ordered by popularity signals, with higher-rated and higher-engagement mentors appearing before lower-ranked ones. (Req: Mentor Discovery - Popularity-Based Ranking) | ||
| 7 | As a Mentee, compare the first two mentors in "Popular" view. | The system should present ranking that is consistent with popularity indicators (rating and mentee engagement), supporting trust-based decision-making. (Req: Mentor Discovery - Popularity Ordering Consistency) | ||
| 8 | As a Mentee, switch to the "Recently Added" mentor browsing criterion. | The system should show mentors ordered from newest to oldest additions, allowing discovery of newly available mentors. (Req: Mentor Discovery - Recently Added Sorting) | ||
| 9 | As a Mentee, open the top mentor card in "Recently Added" and then return to the list. | The system should open the mentor’s public profile details and preserve the selected "Recently Added" context when returning, so exploration remains seamless. (Req: Mentor Discovery - Profile Drill-Down and Context Retention) | ||
| 10 | As a Mentee, repeat discovery by entering a skill keyword in search (for example, "python") using different letter casing. | The system should return relevant mentors regardless of input case, ensuring natural and forgiving search behavior. (Req: Mentor Discovery - Case-Insensitive Skill Search) |
| Field | Value |
|---|---|
| Feature / Epic | Feedback & Reviews: Post-session feedback and public profile rating aggregation |
| Name | Mentees and Mentors Provide Mutual Feedback After Mentorship Session, and Public Ratings Aggregate Transparently |
| Id | AT-FB-001 |
| Description | Validates that after a mentorship session concludes, both mentor and mentee can provide confidential feedback and ratings to each other. The feedback is recorded with immutable timestamps and associated with the mentorship relationship. Critically, public ratings only update and become visible after a defined feedback threshold (e.g., 5 reviews) is reached, preserving mentor anonymity early in their journey. This test ensures the platform builds trust through transparent rating aggregation while preventing undue influence from single low/high reviews. |
| Prerequisite | 1. The system is running (web frontend + backend API + database). 2. Two accounts exist: one Mentor ( john.mentor@university.edu) with role MENTOR and one Mentee (alice.mentee@university.edu) with role MENTEE. 3. Both accounts have completed onboarding and have profile information (bio, skills). 4. An active mentorship relationship (Match) exists between John (Mentor) and Alice (Mentee) in the skill "Python" with status ACCEPTED. 5. The mentorship session has been scheduled and marked as completed (past end time). 6. John the Mentor currently has 0 to 4 feedback entries (below the threshold of 5). 7. Alice can identify John's profile and the completed session in her dashboard. |
Important
Prerequisite: Alice (Mentee) is logged in. A completed mentorship session with John (Mentor) is visible on Alice's calendar or in her active matches list.
| # | Instruction | Expectation | Result | Note |
|---|---|---|---|---|
| 1 | As Alice (Mentee), navigate to the completed mentorship session in the calendar or matches dashboard. | The system displays the session details: date, time, skill ("Python"), John's name/avatar, and a 'Leave Feedback' button (or similar call-to-action). The session is marked as COMPLETED or past due. No feedback form is visible yet (Req: 1.1.6.1). |
||
| 2 | Click the 'Leave Feedback' button. | The system opens a feedback form/modal with the following fields: 1. Rating — a 5-star selector (1–5 stars, currently unselected). 2. Comment — a textarea with placeholder text "Share your experience with this mentor..." (optional field). 3. Submit Feedback button and a Cancel button. Form title reads: "Feedback for [John]" (Req: 1.1.6.1, 1.1.6.2). |
||
| 3 | Leave all fields empty and click 'Submit Feedback'. | The system displays an inline validation error: "Please select a rating." The form does not submit. The textarea may remain empty (Req: 1.1.13.1, 1.1.13.2). | ||
| 4 | Select 4 stars as the rating but leave the comment field empty, then click 'Submit Feedback'. | The system accepts the submission (comment is optional). A success notification appears: "Feedback submitted successfully!" The form closes. The user is returned to the session view or dashboard (Req: 1.1.6.1, 1.1.6.2, 1.1.13.1). | Feedback with comment is optional per UX design. | |
| 5 | Verify the feedback submission by calling GET /api/mentorship/matches/{match_id}/feedback/me/ (from Alice's perspective). |
The API returns Alice's feedback object: { "id": <id>, "match": <match_id>, "from_user": <alice_id>, "to_user": <john_id>, "rating": 4, "comment": "", "created_at": "<ISO-8601-timestamp>", "updated_at": "<ISO-8601-timestamp>" } The created_at and updated_at fields are properly formatted ISO 8601 dates (Req: 1.1.6.2, 2.5.2). |
Timestamps are immutable and auditable. |
Important
Prerequisite: John (Mentor) is logged in. The completed session with Alice is visible on John's calendar or matches list. Alice has already submitted feedback (Part A is complete).
| # | Instruction | Expectation | Result | Note |
|---|---|---|---|---|
| 6 | As John (Mentor), navigate to the completed session in the calendar or matches dashboard. | The system displays the session details: date, time, skill, Alice's name/avatar, and a 'Leave Feedback' button. No feedback form is visible yet. The system may optionally show a notification (e.g., "Alice has left feedback for you") but does not reveal the rating or comment (Req: 1.1.6.1, 1.1.6.2). | ||
| 7 | Click the 'Leave Feedback' button. | The system opens a feedback form identical in structure to Part A, Step 2. Title reads: "Feedback for [Alice]" (Req: 1.1.6.1). | ||
| 8 | Select 5 stars and enter the comment: "Alice was very engaged and asked excellent questions. Great mentee!" Then click 'Submit Feedback'. |
The system accepts the submission. A success notification appears: "Feedback submitted successfully!" The form closes. John is returned to the session view or dashboard (Req: 1.1.6.1, 1.1.6.2, 1.1.13.1). | ||
| 9 | Verify the feedback submission by calling GET /api/mentorship/matches/{match_id}/feedback/me/ (from John's perspective). |
The API returns John's feedback object: { "id": <id>, "match": <match_id>, "from_user": <john_id>, "to_user": <alice_id>, "rating": 5, "comment": "Alice was very engaged...", "created_at": "<ISO-8601-timestamp>", "updated_at": "<ISO-8601-timestamp>" } Timestamps are present and immutable (Req: 1.1.6.2, 2.5.2). |
Important
Both Alice and John have submitted feedback (Parts A & B complete). Verify that feedback is correctly associated with the mentorship relationship.
| # | Instruction | Expectation | Result | Note |
|---|---|---|---|---|
| 10 | As John (Mentor), call GET /api/mentorship/matches/{match_id}/feedback/ to retrieve all feedback on the match. |
The system returns an array with two feedback objects: 1. Alice's feedback (from_user: alice_id, to_user: john_id, rating: 4, comment: "") 2. John's feedback (from_user: john_id, to_user: alice_id, rating: 5, comment: "Alice was very...") Both are correctly associated with the match. Neither John nor Alice can see the other's feedback yet (if privacy is enforced) OR both can see each other's feedback (if bilateral feedback is visible in the relationship). System design determines this. |
System design will specify bilateral visibility rules. | |
| 11 | As Alice, call GET /api/profiles/{john_id}/ to fetch John's public profile. |
John's public profile is returned. The profile includes a field average_rating or public_rating. Since John has only 1-2 feedback entries (below the threshold of 5), the public rating field is null, hidden, or explicitly shows "Not enough ratings yet." (Req: 1.1.6.3). |
Public rating is hidden until threshold is reached. | |
| 12 | Verify that the feedback record cannot be modified. As John, attempt to call PATCH /api/mentorship/feedback/{feedback_id}/ with updated comment "Actually, I meant the opposite..."
|
The system returns 405 Method Not Allowed or 400 Bad Request with error message: "Feedback cannot be edited after submission." The feedback remains unchanged (Req: 2.5.2 — immutable audit trail). | Feedback immutability ensures data integrity. |
Important
Prerequisite: John (Mentor) currently has between 1 and 4 feedback entries from different mentees. Alice's feedback is one of them. We will now add feedback from 4 more mentees to reach the threshold of 5.
| # | Instruction | Expectation | Result | Note |
|---|---|---|---|---|
| 13 | Simulate or create 4 additional completed mentorship sessions between John and 4 different mentees (Bob, Carol, David, Eve). Each mentee submits feedback as follows: - Bob: 5 stars, "Excellent mentor!" - Carol: 4 stars, "Very helpful." - David: 5 stars, "Highly recommend." - Eve: 4 stars, "Good, but could be clearer." |
The system accepts all 4 feedback submissions. Each mentee receives a success notification. The feedback records are created with timestamps. John now has a total of 5 feedback entries (Alice 4-star + Bob 5-star + Carol 4-star + David 5-star + Eve 4-star). | Threshold-crossing moment is about to occur. | |
| 14 | Before the 5th feedback is counted, as Alice, call GET /api/profiles/{john_id}/ to fetch John's public profile. |
John's public profile returns average_rating: null or displays "Not enough ratings yet" (Req: 1.1.6.3). The profile is otherwise complete (bio, skills, etc.). |
Threshold not yet triggered. | |
| 15 | The system processes the 5th feedback submission and triggers an aggregation job (or real-time update). Call GET /api/profiles/{john_id}/ again to fetch the updated profile. |
John's public profile now includes average_rating: 4.4 (calculated as (4 + 5 + 4 + 5 + 4) / 5 = 4.4 stars). The rating is visible on John's profile card in the Mentor Discovery search results and on John's full profile page (Req: 1.1.6.3). |
Aggregation occurs atomically once threshold is reached. | |
| 16 | As a Guest (unauthenticated user), navigate to John's public profile page or perform a mentor discovery search. | The system displays John's profile with the public average_rating: 4.4 prominently visible (e.g., "⭐ 4.4 (5 reviews)"). The rating is not hidden from guests (Req: 1.1.6.3, 1.2.1.2, 1.2.1.3). |
Public ratings boost discoverability. | |
| 17 | As John (Mentor), call GET /api/mentorship/feedback/me/received/ to view all feedback received. |
The system returns an array of all 5 feedback objects with details: each from_user, rating, comment, and created_at timestamp. John can see a detailed review history (Req: 1.1.6.2, 2.5.2). | Mentors have full access to their feedback data. |
Important
The threshold has been crossed and John's public rating is now visible. Verify privacy constraints.
| # | Instruction | Expectation | Result | Note |
|---|---|---|---|---|
| 18 | As Alice, navigate to John's profile page (as a logged-in mentee). | The system displays John's profile with the public average_rating: 4.4 visible. Alice can also see an indicator or link stating "You've rated this mentor" or "Your feedback is pending review" (optional UX). Alice cannot see the detailed feedback from other mentees (Bob, Carol, David, Eve) or their ratings—only the aggregate public rating (Req: 1.1.6.3, 2.2.1). |
Individual feedback remains private. | |
| 19 | As Alice, call GET /api/mentorship/feedback/{alice_feedback_id}/ using her own feedback ID. |
The system returns Alice's feedback object (her 4-star rating and comment). Alice can retrieve her own feedback. (Req: 1.1.6.2). | Users can view their own feedback. | |
| 20 | As Alice, attempt to call GET /api/mentorship/feedback/{bob_feedback_id}/ (Bob's feedback ID) without authorization. |
The system returns 403 Forbidden with error message: "You do not have permission to view this feedback." Alice's request is blocked. Only the mentor (John) and the mentee (Bob) can view that specific feedback (Req: 1.1.6.2, 2.2.1, 1.2.7.2). | Feedback access is strictly controlled. | |
| 21 | As an Admin, attempt to call GET /api/mentorship/feedback/{bob_feedback_id}/. |
The system returns 403 Forbidden. Admins cannot read private feedback by default unless specifically authorized via a report workflow (Req: 1.1.3.3, 1.2.2.2). | Admin access is restricted per privacy policy. |
| # | Instruction | Expectation | Result | Note |
|---|---|---|---|---|
| 22 | As Alice, attempt to submit feedback on a mentorship session that has not yet occurred (future session). | The system rejects the request with 400 Bad Request and error message: "Feedback can only be provided after the session has ended." Alice cannot leave feedback on future or ongoing sessions (Req: 1.1.6.1). | Prevents premature feedback. | |
| 23 | As Alice, attempt to submit feedback on the same completed session twice. After the first feedback in Part A, attempt to submit a second feedback. | The system returns 400 Bad Request or 409 Conflict with error message: "You have already provided feedback on this session. Feedback cannot be modified or duplicated." Only one feedback per user per session is allowed (Req: 2.5.3). | Prevents duplicate feedback. | |
| 24 | As Alice, attempt to provide feedback on a session with a mentor she has not been matched with. | The system returns 403 Forbidden with error message: "You do not have permission to provide feedback on this session." Only the mentor and mentee involved in the session can provide feedback (Req: 1.1.6.2). | Authorization prevents cross-relationship feedback. |
| Requirement ID | Requirement Description | Test Step(s) | Coverage |
|---|---|---|---|
| 1.1.6.1 | The system shall allow mentors and mentees to provide feedback to each other after an interaction. | A1-A4, B6-B8, F22 | Full |
| 1.1.6.2 | Feedback shall be associated with the relevant mentorship relationship. | A5, B9, C10, E17, E19, F24 | Full |
| 1.1.6.3 | The system shall update and display a mentor's average public rating only after receiving a defined threshold of new feedback entries (e.g., every 5 reviews) to preserve user anonymity. | D14, D15, D16, D17 | Full |
| 1.1.13.1 | The system shall provide clear success and failure notifications for all key actions, such as form errors. | A4, B8, D13 | Full |
| 1.1.13.2 | The system shall enforce stricter validation on all forms to prevent the use of special characters in name fields. | A3 (validation) | Partial |
| 1.2.7.2 | The system shall enforce authorization and ownership checks on protected API endpoints. | E20-E21, F24 | Full |
| 2.2.1 | Private messages shall not be publicly visible. | E18, E20 | Full |
| 2.5.2 | Core entities shall include auditable timestamps. | A5, B9, C10, D17 | Full |
| 2.5.3 | The system shall enforce data integrity constraints to prevent duplicate or conflicting lifecycle records. | F23 | Full |
This acceptance test validates that the platform:
- Builds Mutual Trust — Mentors and mentees can transparently exchange feedback and ratings after each session.
- Protects Early Mentors — Public ratings only become visible after a threshold (e.g., 5 reviews), preventing low ratings from discouraging new mentors early on.
- Ensures Privacy — Individual feedback remains confidential between the mentor and mentee; guests and other users see only the aggregate public rating.
- Supports Data Integrity — Feedback is immutable, timestamped, and strictly associated with the mentorship relationship.
- Prevents Abuse — Validation prevents duplicate feedback, premature feedback, and unauthorized feedback access.
- Wrote Acceptance test 2 and decided on data strategy with Ebubekir.
- Wrote Acceptance test 3 and decided on data strategy with İnan
- Wrote Acceptance test 4 and decided on acceptance test strategy with Enes.
- Wrote Acceptance test 5 and decided on acceptance test strategy with Turgut.
- Wrote Acceptance test 6 and review requirements with Barkın.
- Wrote Acceptance test 1 and review other tasks.
- Wrote Acceptance test 7 and review requirements with Göksel.
- Wrote Acceptance test 8.
Links: Home | Main Repository
Team Members
- Software Requirements Specification (SRS)
- Requirement Elicitation Questions
- Scenarios: Mentee New Register
- Scenarios: Mentee Already Registered
- Scenarios: Mentor Already Registered
- Use Case Diagram (Initial) - 1
- Use Case Diagram (Initial) - 2
- Use Case Diagram (Initial) - 3
- Use Case Diagram (Final)
- Class Diagram
- Sequence Diagrams
- Final Milestone Deliverables
- Final Project Review
- Final Progress Based on Teamwork
- Final Individual Contributions
- Final Demo Plan
- MVP Deliverables
- MVP Plan
- MVP Demo Plan
- MVP Demo Backup
- MVP Milestone Review
- MVP Feedback Report
- MVP Individual Contributions
- Project Plan
- Communication Plan
- Test Plan & Coverage
- Acceptance Testing Strategy
- Acceptance Tests Checklist
- Last Week Checklist
- Responsibility Assignment Matrix (RAM)
- Use of Standards
- Project Standards & Workflow
- Project Retrospective
- API Documentation
- Knowledge Base