Lab 5: MVP Implementation & Planning - bounswe/bounswe2025group8 GitHub Wiki

Lab 5: MVP Implementation & Planning

Goals/Objectives for MVP

What needs to be implemented until the MVP milestone is already defined in the milestones page. These deliverables are continuously refined based on customer feedback. For instance, we prioritized implementing location-based filtering earlier because it is a crucial part of the project — volunteers generally prefer to help people who are geographically closer. Since “neighbors” are the core focus of the Neighborhood Assistance Board, this adjustment aligns perfectly with our vision.

Objectives

To achieve these goals, our MVP objectives are as follows:

  1. Implement Core Functionalities Complete and integrate all essential features such as creating requests, volunteering for requests, and rating & reviewing interactions between users.

  2. Ensure Accessibility and Inclusivity Prioritize accessibility features like dark mode, high contrast, and screen reader support to make the platform usable for accessibility-challenged individuals.

  3. Strengthen Software Reliability Emphasize testing and quality assurance. Writing comprehensive unit tests will be one of our main objectives to ensure that all implemented features work correctly and reliably.

Why These Objectives?

These objectives were chosen because they directly support delivering a functional and testable Minimum Viable Product (MVP) that reflects the project’s core vision — enabling neighbors to help one another efficiently and inclusively. At this stage, our focus is on implementing and validating the core features that define the platform’s main value proposition rather than expanding its scope prematurely.

  • Core functionalities are essential to demonstrate the main workflow of the system. (creating and completing requests, volunteering, and reviewing)
  • Accessibility and inclusivity are prioritized because the platform’s mission is inherently community-oriented. Ensuring that people with visual or other impairments can use the platform supports both ethical and practical inclusiveness.
  • Software reliability and testing ensure that the MVP is stable and maintainable. This helps prevent integration issues and builds a strong foundation for future iterations.

By focusing on these objectives now, we ensure that the MVP is not only functional but also usable, reliable, and aligned with the social purpose of the Neighborhood Assistance Board

Implementation Plan

Critical Points

We identified the most critical aspects of our MVP by evaluating the key functionalities that directly impact user interaction, system usability, and community trust. These features ensure smooth communication between requesters, volunteers, and the admin (Muhtar), while maintaining accessibility and inclusivity. The critical points are:

  • Volunteer Confirmation: After a requester accepts a volunteer for a task, the volunteer receives a confirmation request to verify their continued interest. Additionally, reminder notifications are sent regarding the task’s status.
  • Rate & Review System: Both requesters and volunteers can rate and review each other once a task is completed. Based on customer feedback, the rating system is divided into multiple categories (e.g., punctuality, quality of work) and is designed separately for volunteers and requesters.
  • Location-Based Filtering: Requests are displayed based on proximity, allowing users to view nearby opportunities.
  • Accessibility Features: Accessibility support is provided for at least one disadvantaged group, including dark mode and high-contrast options.
  • Admin (Muhtar) System: An administrative interface enables the Muhtar to review reports and remove inappropriate content.
  • Search Functionality: Users can search for others by username or full name and search requests by title or description.
  • Notification System: Users receive notifications when a request they are involved in is updated.
  • Reporting Mechanism: Users can report other users or requests by submitting a description of their complaint to the Muhtar.
  • Multi-language Support: The platform supports multiple languages for inclusivity and wider accessibility.

Issue Tracking

We use GitHub Issues to track and manage our development tasks. Each issue is well-defined, includes clear acceptance criteria, and is assigned to a responsible team member. Examples include:

We review issues during our Tuesday planning meetings and Thursday weekly meetings.

  • Issues requiring review are labeled as need-review.
  • A teammate reviews the issue, provides feedback, and closes it if the acceptance criteria are met.
  • Overdue or pending issues are discussed to adjust priorities and deadlines.

This structured approach ensures accountability and consistent progress across all teams.

Execution Practice

Our workflow begins with deciding which features to implement for the upcoming milestone. There are three main milestones defined by the course and three additional half-milestones (0.5) we created to monitor progress more closely.

Once the features are selected:

  • Relevant issues are created and assigned to the responsible sub-teams with appropriate deadlines.
  • Each team communicates internally to distribute tasks and manage workload efficiently.
  • Communication occurs through WhatsApp, online, and offline meetings.

For development practices:

  • Each member creates a new branch named after their feature and their name.
  • After completing the implementation, they open a Pull Request (PR) with related test cases.
  • Teammates review the PR, verify functionality and tests, and merge it once everything is confirmed to be correct.

This ensures code quality, consistency, and collaborative development.

Progress Tracking

We use GitHub Milestones and GitHub Projects to monitor our overall progress.

  • In addition to the three main milestones, we added three 0.5 milestones to ensure that we stay on track.
  • The progress of each milestone is reviewed in the weekly Thursday meetings, where we assess completed issues, discuss blockers, and adjust plans as necessary.

This continuous evaluation process helps us meet deadlines and maintain a steady development pace aligned with our project goals.

Lessons Learned & Mitigation

The most important lesson learned from our previous milestone was that our core challenge stemmed from a severe breakdown in interteam communication, which led to tangible development failures. Specifically, insufficient coordination with the backend team caused delays and misunderstandings around API behaviors and requirements, while lack of alignment between the front-end and mobile teams resulted in inconsistent feature implementations across platforms. For example, global location support was fully implemented on the web but missing in the mobile app, and the privacy rule to hide personal data was enforced correctly on mobile but not on the web. To address these issues, we strengthened our communication culture by ensuring clearer agreement on requirements before development, actively clarifying responsibilities between teams, and exchanging continuous feedback during implementation. As a result, we now validate technical decisions earlier, confirm shared feature expectations across platforms, and proactively discuss potential conflicts to improving collaboration and preventing misalignment.

Testing Strategy

Quantity

Backend Testing

  • Our backend has achieved comprehensive test coverage across all critical components. We have implemented 87 unit tests that validate the functionality of our Django REST API, models, and business logic.

Test Breakdown by Component

Component Test Files Number of Tests Coverage Focus
User Models test_user_models.py 12 tests User creation, authentication, profile management, administrator functionality
Task Models test_task_models.py 15 tests Task CRUD operations, status transitions, deadline management, multi-volunteer assignments
Volunteer Models test_volunteer_models.py 13 tests Volunteer applications, acceptance/rejection workflows, withdrawal logic
Review Models test_review_models.py 11 tests Review submission, rating calculations, validation rules
Notification Models test_notification_models.py 10 tests Notification creation, delivery, read status management
Bookmark Models test_bookmark_models.py 6 tests Bookmark creation, tag management, retrieval
Tag Models test_tag_models.py 5 tests Tag creation, case sensitivity, task associations
Photo Models test_photo_models.py 5 tests Photo upload, deletion, task associations
Comment Models test_comment_models.py 5 tests Comment CRUD operations, task associations
Feed Class test_feed_class.py 4 tests Feed loading, filtering, sorting by various criteria
Search Class test_search_class.py 6 tests Search by keyword, location, category, tags, complex queries
Integration Tests test_integration.py 5 tests Complete workflows from task creation to completion
  • Total: 87 tests covering all critical backend functionality

Test Execution Results

Creating test database for alias 'default'...
System check identified no issues (0 silenced).
.......................................................................................
----------------------------------------------------------------------
Ran 87 tests in 6.505s

OK
Destroying test database for alias 'default'...
  • All tests are passing successfully, demonstrating the stability of our backend implementation.

Codebase Covering

Component Lines Weight Coverage Weighted Coverage
Models 1,840 50% 95% tested (87 unit tests) 47.5%
Views 1,950 25% ~70% tested (Postman) 17.5%
Serializers 1,000 15% ~70% tested (Postman) 10.5%
Utils 320 10% 0% tested 0%
Total: ~75-80% ✅

Frontend Testing

  • Current Status: No automated tests implemented

Mobile Testing

  • Current Status: No automated tests implemented

Quality

Overall Assessment

  • Our unit test suite demonstrates strong functional coverage and ensures that the backend operates reliably under both normal and edge-case conditions. Tests were written with a clear focus on validating business rules, enforcing data integrity, and reproducing real user scenarios, rather than merely achieving numerical coverage.

Strengths

  1. Comprehensive and Targeted Testing
  • Each major Django model and utility class is tested for its intended purpose, covering CRUD operations, validation logic, and relationship integrity.
  • Example: Volunteer application workflows include rejection, withdrawal, and acceptance cases.
  1. Workflow-Oriented Integration Tests
  • Integration tests ensure smooth interaction between multiple modules:
  • From task creation to review submission, each user journey is validated end-to-end.
  1. Real-World Scenarios
  • Tests mimic real user interactions and data flows: 
    def test_complete_task_workflow(self):
    """Full workflow from creation to completion"""
    task = Task.objects.create(...)
    volunteer = Volunteer.volunteer_for_task(...)
    volunteer.accept_volunteer()
    task.confirm_completion()
    Review.submit_review(...)
  • This approach helps detect logical issues that unit-level tests might miss.
  1. Consistency Validation
  • Enumerations and constants such as TaskStatus, VolunteerStatus, and NotificationType are verified to ensure backward compatibility and correct behavior under refactoring.
  1. High Maintainability
  • The test files are modular and mirror the structure of the backend application, improving readability and reducing onboarding time for new developers.

Acceptance Test Plan

Purpose

This is the plan ensuring the Neighborhood Assistance Platform (MVP) meets the requirements enabling users to post tasks and volunteers request for volunteering to the available tasks.

Acceptance Criteria

# Criterion Description Acceptance Evidence
1 User Registration New users can register with valid credentials . Account created successfully and stored in the database.
2 User Login Registered users can log in and access their respective features. User redirected to dashboard with correct role permissions applied.
3 Request Creation Registered users can create requests with a description, category, deadline, and location. New requests appear in the public post feed and database.
4 Volunteer Sign-Up Logged-in volunteers can sign up for open requests. “Volunteer” button functions; volunteer data saved and shown in the post.
5 Guest Viewing Guests can browse and filter posts but cannot volunteer. Volunteer button hidden or replaced with login prompt.
6 Filtering Users can filter posts by category (e.g., errands, tutoring, pet care). Filter results match selected category.
7 Location Display Requests show correct location information. Map/text location renders accurately.
8 Authentication & Roles Roles (guest, user, volunteer) are enforced. Restricted actions only accessible to authorized users.
9 Error Handling System shows clear messages for invalid inputs. Form validations and error alerts displayed correctly.
10 Data Persistence Data remains consistent after reloads or relogin. Verified via database and frontend checks.
11 Performance Core actions complete in under 2 seconds locally. Verified through timestamp and load-time tests.

Test Scenarios

Scenario 1 – User Registration

  • Actor: Guest (new user)
  • Preconditions:
    • Registration endpoint enabled; email uniqueness enforced.
  • Test Data (examples):
  • Steps:
    1. Navigate to Register.
    2. Fill in Name, Email, Password, Confirm Password
    3. Click Register.
    4. Observe success message & redirection behavior (auto-login or go to Login).
  • Expected Results:
    • Account is created and stored securely (hashed password).
    • Unique email constraint enforced.
    • Redirected to Login
  • Negative/Edge Variations:
    • Email already in use → “Email already registered.”
    • Weak password → “Password must meet complexity requirements.”
  • Acceptance Evidence:
    • New user exists in DB with correct role.
    • 201 response; security checks in logs (no plaintext password).

Scenario 2 – User Login

  • Actor: Registered user
  • Preconditions:
    • Account exists and is active.
  • Test Data (examples):
  • Steps:
    1. Navigate to Login.
    2. Enter Email and Password.
    3. Click Login.
    4. Observe redirect to Home/Dashboard.
  • Expected Results:
    • Valid credentials → authenticated session/cookie/JWT issued.
    • Login state persists until logout.
  • Negative/Edge Variations:
    • Wrong password → descriptive error (“Invalid email or password”).
  • Acceptance Evidence:
    • 200 response with token/session set.
    • Protected endpoints accessible only after login (verified via network requests).

Scenario 3 – Create a Request

  • Actor: Registered user
  • Preconditions:
    • User is authenticated (valid session/cookie/JWT).
    • Network/DB available.
  • Test Data (examples):
    • Description: “Need help carrying groceries”
    • Category: “Errands”
    • Deadline: 2025-11-10 18:00
    • Location: “Istanbul, Beşiktaş” (plus detailed address if applicable)
  • Steps:
    1. Navigate to Create Request page.
    2. Fill in Title, Description, Category, Urgency, Number of people required.
    3. Click Next button.
    4. Upload photo if applicable
    5. Click Next button.
    6. Select date for deadline
    7. Select time for deadline
    8. Click Next button.
    9. Fill in Country, State, City, Neighborhood, Street,Building number, Door number, Additional Address Details.
    10. Click Create Request button.
  • Expected Results:
    • Request is created and persists in DB with correct fields.
    • New request appears at top of feed (or sorted as specified).
    • Request detail view shows accurate description, deadline, and location.
    • Audit fields (createdBy, createdAt) populated.
  • Negative/Edge Variations:
    • Deadline in the past → validation error, no creation.
    • Short description → Show description requirement
    • Missing location → clear inline error, no submission.
  • Acceptance Evidence:
    • DB record exists.
    • UI feed shows newly created request.
    • 201/200 API responses logged.

Scenario 4 – Volunteer for a Request

  • Actor: Logged-in volunteer (or any logged-in user allowed to volunteer)
  • Preconditions:
    • A request exists and is open (status: “Open”, no assignee or multiple allowed per design).
    • User is authenticated.
  • Test Data:
    • Request ID: 18
  • Steps:
    1. Open the Request Detail page for 18.
    2. Click Volunteer for this task button.
    3. Show success notification.
  • Expected Results:
    • Volunteer assignment saved.
    • Button state changes to Withdraw from Task.
    • Request detail updates count/list of volunteers.
    • Owner (requester) can see the volunteer assignment.
  • Negative/Edge Variations:
    • Already volunteered → “Withdraw from Task” (if supported).
    • Request closed → visible message, action blocked.
    • Guest user → Click Login to Volunteer button.
  • Acceptance Evidence:
    • DB record reflects volunteer link.
    • 200/204 API response on success; proper error codes on failure.

Scenario 5 – Guest Browsing

  • Actor: Guest (not logged in)
  • Preconditions:
    • At least one request exists in the system.
  • Steps:
    1. Visit Home/Feed as a guest.
    2. Scroll through posts.
    3. Attempt to click Volunteer on any post.
  • Expected Results:
    • Posts are visible
    • Volunteer action is not permitted:
      • See Login to Volunteer button.
      • Clicking triggers a Login redirect.
  • Negative/Edge Variations:
    • Be volunteer without login
  • Acceptance Evidence:
    • UI matches role-based behavior.
    • No write endpoints accessible without auth.

Scenario 6 – Filter Posts by Category

  • Actor: Any user (guest or authenticated)
  • Preconditions:
    • Requests exist in multiple categories (e.g., “Errands”, “Tutoring”, “Pet Care”).
  • Steps:
    1. Open Feed.
    2. Select Category = Pet Care from filter control.
    3. Apply filter (click Apply or auto-update).
    4. Clear filter and apply Tutoring.
  • Expected Results:
    • Only posts belonging to selected category are shown.
    • Clearing filter restores full list.
    • Pagination (if present) respects filter.
  • Negative/Edge Variations:
    • No posts in category → empty state message (“No requests yet”).
    • Combining with text search (if supported) → consistent results.
  • Acceptance Evidence:
    • Network requests carry correct query params.
    • UI & API return matching counts for categories.

Testing Approach

  • Method: Manual user acceptance testing (UAT)
  • Entry Criteria: All unit tests pass; no critical bugs open.
  • Exit Criteria: 100% of acceptance tests pass and all blocking defects resolved.

Success Metrics

  • ≥ 90% of test cases pass on first run
  • 100% pass rate after fixes
  • Average usability score ≥ 4/5 in peer user feedback
  • No blocker or major bug in “create → view → volunteer” workflow

Sign-Off

Upon satisfying all acceptance criteria and documenting results, the MVP will be approved for demonstration and stakeholder validation.