Test Plan & Coverage

1. Testing Strategy

Our testing strategy ensures both technical robustness and adherence to our W3C/WCAG 2.1 AA accessibility standards across our monorepo architecture:

• Unit Testing:
  • Frontend: Utilizing Vitest to test isolated React components, custom hooks, and state management to ensure UI elements behave as expected.
  • Backend: Using Django's built-in testing framework to validate Python business logic, model constraints (e.g., dual user role validations, unique email enforcement), and database interactions.
• API & Integration Testing: Testing our Django REST Framework endpoints to ensure proper data serialization, authentication, permission enforcement across user types (Guest, User, Admin), and error handling when the frontend communicates with the backend.
• End-to-End (E2E) Testing: Simulating real user scenarios across the entire application stack—from the React frontend (web) and React Native (mobile) through to the Django backend and database. This ensures critical user journeys function seamlessly in a production-like environment.
• Accessibility Testing: Validating WCAG 2.1 AA compliance using axe DevTools and WAVE browser extensions during UI development.
• Mock Data: Generating seed data (mock Mentor and Mentee profiles, sample expertise fields, availability slots, and mentorship listings) to consistently test the search, discovery, and request workflows without relying on a production database.
• Automated Quality Assurance: Utilizing our CI/CD pipeline (GitHub Actions) on every pull request to run backend tests (Django test suite with PostgreSQL) and frontend checks (Vitest + Vite build) to catch bugs before they merge.
• Manual Quality Assurance: Requiring at least one other developer to review the proposed code changes on every pull request to catch bugs and vulnerabilities before they merge.

2. Test Plan Coverage & User Acceptance Criteria (UAC)

To determine if our application is acceptable from a user perspective, our coverage validates the full scope of functional and non-functional requirements defined in our project specification.

Criteria for Acceptability: The application is considered successful if we validate that users can register, build profiles, discover mentors, establish mentorship connections, communicate, schedule sessions, and provide feedback — all within a secure, accessible, and privacy-respecting platform.

Key Scenarios & Use Cases to Validate:

Scenario A: User Registration & Authentication (Req 1.1.2)

• UAC: A new user can register with a unique email and password, and authenticate via JWT tokens.
• UAC: A registered user can log in, log out, and refresh expired tokens.
• UAC: The system supports third-party OAuth authentication (e.g., Google, Apple, Facebook).

Scenario B: User Types & Access Control (Req 1.1.1)

• UAC: Guests can browse and search mentors but cannot initiate communication or send requests.
• UAC: Users can act as mentor, mentee, or both, with multiple concurrent mentorship relationships.
• UAC: Admins can manage accounts and review reports but cannot read private messages by default.

Scenario C: Profiles & Visibility (Req 1.1.3)

• UAC: Users can create and edit profiles with display name, bio, title, location, and picture.
• UAC: Users can control visibility of profile fields (public vs. hidden) and choose to display only initials publicly.
• UAC: Guests can view only the public parts of user profiles.

Scenario D: Mentorship Discovery (Req 1.2.1)

• UAC: Users and guests can search and filter mentors by skill/topic, criteria, and geographical distance.
• UAC: Mentor listings can be viewed on an interactive map interface.
• UAC: The UI features dynamic discovery lists such as "Recently Added Listings" and "Popular Mentors".

Scenario E: Mentorship Request & Matching (Req 1.1.4)

• UAC: A Mentee can send a mentorship request with an optional cover letter to a Mentor.
• UAC: Mentors can accept or reject requests, with automatic Match creation upon acceptance.
• UAC: The system prevents duplicate pending requests and supports many-to-many mentorship relationships.

Scenario F: Scheduling & Calendar (Req 1.1.8)

• UAC: Users can create availability schedules and view upcoming sessions in a calendar.
• UAC: Users can reschedule and cancel sessions, and navigate to mentor profiles from calendar entries.
• UAC: The system supports one-time and recurring sessions, and integrates with external calendars.

Scenario G: Messaging (Req 1.1.5)

• UAC: Matched users can exchange private messages with file sharing and Markdown support.
• UAC: Users can report problematic communication through the messaging interface.

Scenario H: Group Sessions & Workshops (Req 1.1.9)

• UAC: Mentors can create workshops with participant thresholds, and mentees can request group attendance.

Scenario I: Feedback & Ratings (Req 1.1.6)

• UAC: Mentors and mentees can provide feedback tied to their mentorship relationship.
• UAC: Public ratings update only after a threshold of new reviews to preserve anonymity.

Scenario J: Notifications (Req 1.1.7)

• UAC: The system notifies users about relevant events, delivered only to directly affected users.

Scenario K: Admin & Reporting (Req 1.2.2)

• UAC: Admins can review reports and manage user accounts through a dedicated interface.

Scenario L: Accessibility, Platform & Constraints (Req 2.1, 2.4, 1.2.4)

• UAC: Web and mobile interfaces comply with WCAG 2.1 AA accessibility standards.
• UAC: The system provides both web and mobile application interfaces.
• UAC: All third-party libraries are open-source; no monetization or skill verification features are included.