-
Notifications
You must be signed in to change notification settings - Fork 0
Lab 10 Report
Execute the acceptance testing strategy prepared in Lab 9, validate the main end-to-end user flows of the system, document scenario-based results, summarize requirement coverage, and identify remaining issues before final delivery.
We carried out Lab 10 as the execution phase of the acceptance testing work prepared in Lab 9. Instead of creating a new test scope, we reused the previously defined acceptance scenarios and evaluated them from the perspective of observable end-user behavior.
The team followed these principles during execution:
- Reuse the Lab 9 scenario structure to preserve consistency.
- Evaluate complete user journeys rather than isolated technical functions.
- Compare actual outcomes with expected results for each scenario.
- Mark incomplete, broken, or partially working flows explicitly.
- Use the observed outcomes to assess readiness for final delivery.
The acceptance test set covered the following scenario groups:
- New user onboarding, registration, and login
- Password reset and recovery
- Role-based profile management
- Mentor discovery and profile evaluation
- Mentorship request lifecycle and notifications
- Active mentorship viewing and shared goal updates
- Weekly availability management for mentors and mentees
Acceptance testing was conducted against the integrated version of the Mentor-Mentee Matching Platform, including the user-facing frontend flows and the backend services supporting them.
The testing environment assumptions were:
- The application was run using the team’s current frontend and backend setup.
- Supporting services such as the database and development email tooling were available where needed.
- Test accounts were prepared with realistic mentor-side and mentee-side data.
- Scenarios were executed from a stakeholder/user perspective rather than only at implementation level.
We reviewed and executed the acceptance scenarios prepared in Lab 9.
- AT-01 -- New user completes onboarding successfully: Validates registration, email verification, and login for a new user.
- AT-02 -- Existing user resets password successfully: Validates the forgot-password, reset-password, and token-based recovery flow.
- AT-03 -- User manages role-based profile information: Validates editing and persistence of mentor/mentee profile fields, preferences, and profile photo behavior.
- AT-04 -- Mentee discovers and evaluates mentors: Validates mentor exploration, filtering, ranking, and mentor profile viewing.
- AT-05 -- Mentorship request lifecycle is handled correctly: Validates request sending, duplicate prevention, incoming request review, acceptance/rejection, and resulting notifications.
- AT-06 -- Active mentorship data can be viewed and updated: Validates active mentorship visibility and shared goal updates.
- AT-07 -- Users manage recurring weekly availability correctly: Validates mentor and mentee weekly availability creation, persistence, and invalid time rejection.
These scenarios were chosen because they collectively cover the most important end-to-end user journeys of the platform with minimum overlap.
The executed acceptance tests continued the requirement-oriented structure defined in Lab 9. Rather than introducing a separate test inventory, the team reused the prepared scenarios to validate whether implemented user flows satisfy the intended requirements in practice.
At a high level, the tests covered 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 kept the report aligned with the requirement mappings already documented in the previous lab and made it easier to connect observed results with expected user-facing outcomes.
A major outcome of Lab 10 was not only confirming which features work, but also identifying remaining risks before final delivery. During the execution process, each scenario was evaluated under one of the following result categories:
- Passed: the user flow works as expected from start to finish.
- Partially passed: the main flow works, but there are consistency, usability, or reliability issues.
- Failed: the flow cannot be completed successfully or violates the expected outcome.
- Not executed: the scenario could not be tested due to dependency, time, or environment constraints.
The final version of the report should therefore summarize:
- Which scenarios passed without major issues
- Which scenarios exposed remaining defects
- Which issues are most critical before final delivery
- Which risks remain if unresolved items are carried into the final milestone
| Member | Contribution |
|---|---|
| Övgü Su Afşar | |
| Mehmet Bora Sarıoğlu | |
| Beratcan Doğan | I helped update and refine the requirements section, and I reviewed open pull requests by providing feedback and checking for consistency and correctness. |
| Muhammet Sami Çakmak | I update web issues and create drafts of new issues according to new scheduling and mentorship timeline requirements. |
| İbrahim Kayan | |
| Burak Öğüt | Reviewed and updated the Requirements wiki: removed Community sections, added Social Feed (For You/Following tabs, hashtag tagging, post interactions), follow/unfollow, and missing requirements. |
| Amin Abu-Hilga | Reviewed and discussed requirements. Made dev mergable in main. |
Lab 10 served as the execution and validation phase of the acceptance testing work initiated in Lab 9. By evaluating the prepared end-to-end scenarios against the implemented system, the team was able to assess not only whether features exist, but whether they collectively support the intended user experience of the Mentor-Mentee Matching Platform.
The main outcome of the lab was a structured basis for documenting actual test results, requirement coverage, and remaining issues before final delivery. The report should therefore be finalized with concrete execution outcomes, concise evidence, and an honest summary of overall readiness.
Team Members
- Lab 1 Report (12/02/2026)
- Lab 2 Report (19/02/2026)
- Lab 3 Report (26/02/2026)
- Lab 4 Report (05/03/2026)
- Lab 5 Report (12/03/2026)
- Lab 6 Report (26/03/2026)
- Lab 7 Report (02/04/2026)
- Lab 8 Report (18/04/2026)
- Lab 9 Report (30/04/2026)
- Lab 10 Report (07/05/2026)
- Weekly Meeting Notes Template
- Lab Meeting 1 (12.02.2026)
- Weekly Meeting 1 (16.02.2026)
- Weekly Meeting 2 (24.02.2026)
- Weekly Meeting 3 (04.03.2026)
- Weekly Meeting 4 (11.03.2026)
- Weekly Meeting 5 (23.03.2026)
- Weekly Meeting 6 (29.03.2026)
- Weekly Meeting 7 (11.04.2026)
- Weekly Meeting 8 (28.04.2026)
- Weekly Meeting 9 (10.05.2026)
- Use Case Diagram 1 (New Mentor User for Mobile Scenario)
- Use Case Diagram 2 (Mentor-Mentee Matching Scenario)
- Use Case Diagram 3 (New Mentee User Scenario)
- Final Use Case Diagram
- MVP Use Case Diagram
- All Sequence Diagrams
- Sequence Diagram: Mentee Matching
- Sequence Diagram: Mentor Matching
- Sequence Diagram: Mentorship Management
- Sequence Diagram: Registration
- Sequence Diagram: Cancelling Mentorship Relationship and Auto Ban
- Sequence Diagram: Login-Logout
- Sequence Diagram: Reporting-User
- Sequence Diagram: Mentor Profile Management
- MVP Sequence Diagrams
- Test Plan & Coverage (MVP)
- Acceptance Testing Strategy
- Acceptance Tests
- Test Data Strategy
- Web Frontend Test Report
- Amin Abu-Hilga
- Övgü Su Afşar
- Muhammet Sami Çakmak
- Beratcan Doğan
- İbrahim Kayan
- Burak Ögüt
- Mehmet Bora Sarıoğlu
- Future Work (reference, not a deliverable)