Lab 10 Report

Lab 10 Report

Introduction

In Lab 9, the team defined an acceptance testing strategy, prepared realistic end-to-end scenarios, and mapped those scenarios to the implemented requirements. In Lab 10, that preparation is turned into execution. The purpose of this report is to document how the planned acceptance tests were carried out, which user-facing flows were validated successfully, and which issues or limitations were still observed during the evaluation process.

The report is written in continuity with the previous lab deliverable. It uses the same acceptance testing scope, scenario set, and requirement-oriented framing so that the transition from planning to execution remains easy to follow.

Acceptance Test Execution Approach

The team used the acceptance test scenarios prepared in Lab 9 as the baseline for execution. These scenarios were designed to cover the main user-facing flows of the Mentor-Mentee Matching Platform with minimum overlap and broad requirement coverage. During Lab 10, each scenario was revisited and evaluated from the perspective of expected end-user behavior rather than low-level implementation details.

The execution approach focused on the following principles:

• Reuse the scenario structure defined in Lab 9 to preserve consistency.
• Evaluate complete user journeys instead of isolated technical functions.
• Record actual behavior against expected results for each step.
• Mark missing, broken, or partially working flows explicitly.
• Use observed outcomes to assess overall readiness for final delivery.

The acceptance test set used in this lab includes the following scenario groups:

1. New user onboarding, registration, and login
2. Password reset and recovery
3. Role-based profile management
4. Mentor discovery and profile evaluation
5. Mentorship request lifecycle and notifications
6. Active mentorship viewing and shared goal updates
7. Weekly availability management for mentors and mentees

Test Environment

Acceptance testing was carried out against the current integrated version of the project, covering the user-facing frontend flows and the backend services that support them. The goal was to validate whether the implemented system behaves in a way that satisfies stakeholder and user expectations under realistic usage conditions.

The environment assumptions were as follows:

• The application was run using the team's current frontend and backend setup.
• Required services such as the database and email-related development tooling were available where the scenario required them.
• Test users were created with roles and data suitable for mentor-side and mentee-side flows.

Scenario-by-Scenario Results

AT-01: New user completes onboarding successfully

This scenario validates the registration, email verification, and login flow for a new user. It confirms that a user can create an account, verify ownership of the email address, and access the authenticated area without developer intervention.

Result summary: The system should allow the full onboarding flow from registration to successful authenticated access. Any failure in registration validation, verification token handling, or login redirection should be recorded here during final execution.

AT-02: Existing user resets password successfully

This scenario evaluates whether a verified user can request a password reset, receive a valid reset link, set a new password, and log in again with updated credentials. It also checks whether the system avoids exposing whether an account exists.

Result summary: The password recovery flow should preserve both usability and security. Any token validation problems, email delivery issues, or reset form errors should be documented here.

AT-03: User manages role-based profile information

This scenario checks whether logged-in users can view and edit their profile information based on the selected role. It includes updating role-specific fields, adjusting preferences, and managing profile photos.

Result summary: Profile updates should persist after reload and reflect the chosen role correctly. Any problems with file upload, persistence, or role-specific field handling should be noted in this section.

AT-04: Mentee discovers and evaluates mentors

This scenario tests the mentor exploration flow from a mentee's perspective. It covers listing, filtering, ranking, and opening mentor profiles.

Result summary: The system should help a mentee meaningfully browse potential mentors and inspect relevant public profile information. Any missing ranking information, incorrect filtering behavior, or broken profile navigation should be reported here.

AT-05: Mentorship request lifecycle is handled correctly

This scenario validates the complete mentorship request flow, including sending a request, preventing duplicate submissions, reviewing incoming requests, rejecting or accepting requests, and observing resulting notifications.

Result summary: This is one of the most critical end-to-end workflows in the platform. Any lifecycle inconsistency, state transition bug, capacity rule violation, or notification mismatch should be clearly highlighted.

AT-06: Active mentorship data can be viewed and updated

This scenario verifies that users who already have an active mentorship can open the relevant view, inspect the mentorship relationship, and update shared goal information.

Result summary: The system should support continuity after matching, not only the initial connection phase. If active mentorship data is not shown correctly or shared goal updates do not persist, the issue should be documented here.

AT-07: Users manage recurring weekly availability correctly

This scenario checks whether both mentors and mentees can create, save, and revisit weekly recurring availability, while invalid time ranges are rejected properly.

Result summary: Availability data should remain consistent across revisits and enforce sensible validation rules. Any incorrect save behavior, overlap handling problem, or broken validation should be reported in this section.

Requirement Coverage Summary

The Lab 10 acceptance testing effort continues the requirement-oriented structure established in Lab 9. Instead of introducing a new scenario set, the team reused the already prepared acceptance tests to validate whether the implemented user journeys now satisfy the corresponding requirements in practice.

At a high level, the executed acceptance tests cover these requirement areas:

• Authentication and account lifecycle
• Password recovery
• Role-based profile management
• Mentor discovery and matching support
• Mentorship request lifecycle
• Active mentorship management
• Weekly availability scheduling
• Notification visibility tied to mentorship actions

This structure keeps the report aligned with the requirement mappings already documented in the earlier acceptance testing work and makes it easier to see which project goals are validated by observable user behavior.

Findings and Remaining Issues

The main value of Lab 10 is not only confirming what works, but also making unresolved gaps visible before the final delivery. For each executed scenario, the team should identify whether the observed result falls into one of the following categories:

• Passed: the user flow works as expected from start to finish.
• Partially passed: the main flow works, but there are usability, reliability, or consistency issues.
• Failed: the flow cannot be completed successfully or violates the expected stakeholder outcome.
• Not executed: the scenario could not be tested due to time, environment, or dependency constraints.

The final version of this section should summarize:

• Which scenarios passed without notable issues
• Which scenarios exposed remaining defects
• Which defects are most important before final delivery
• Which risks remain if unresolved issues are not addressed

Individual Contributions

• Övgü Su Afşar: Contributed the individual acceptance test focusing on registration, login, logout, and role-based profile management, and supported the preparation of the acceptance-testing-oriented report structure.
• Mehmet Bora Sarıoğlu: Add final contribution summary.
• Beratcan Şahin: Add final contribution summary.
• Muhammet Sami: Add final contribution summary.
• İbrahim Kayan: Add final contribution summary.
• Burak Öğüt: Add final contribution summary.
• Amin: Add final contribution summary.

Conclusion

Lab 10 serves as the execution and validation stage of the acceptance testing work initiated in Lab 9. By evaluating the prepared end-to-end scenarios against the current system, the team can now assess not only whether features exist, but whether they collectively support the intended user experience of the Mentor-Mentee Matching Platform.

The report should therefore be finalized with concrete execution outcomes, concise evidence, and an honest summary of readiness for the final delivery.