| ID | Description | Precondition | Steps | Expected Result | Actual Result | Status |
|---|
| AUTH-001 | Valid login with OTP (2-step) | Active user account exists |
- Navigate to login page
- Enter valid username and password
- Submit credentials
- Receive OTP/access code
- Enter access code
- Submit
|
User is authenticated and redirected to role-appropriate dashboard. JWT token issued. | | |
| AUTH-002 | Invalid password login attempt | Active user account exists |
- Navigate to login page
- Enter valid username, wrong password
- Submit
|
Error message displayed. Login denied. Failed attempt logged in tbl_login_logs. | | |
| AUTH-003 | Brute-force protection lockout | Active user account exists; brute-force configured |
- Attempt login with wrong password N times (where N = configured threshold)
- Attempt with correct password
|
Account is locked after N failed attempts. Even correct credentials are rejected until lockout period expires. | | |
| AUTH-004 | Must-Change-Password (MCP) flow | New user or admin-reset password |
- Login with temporary password
- System prompts password change
- Enter new password (meeting complexity rules)
- Confirm new password
- Submit
|
Password updated successfully. User redirected to dashboard. Old password no longer works. | | |
| AUTH-005 | Password reset via Admin | Admin logged in; target user exists |
- Admin navigates to user management
- Selects target user
- Clicks reset password
- Confirms action
|
Target user's password is reset. MCP flag set. User must change password on next login. | | |
| AUTH-006 | Session timeout | User logged in; idle_time_out configured in tbl_sys_settings |
- Login successfully
- Remain idle for duration exceeding idle_time_out
- Attempt any action
|
Session expired. User redirected to login page with appropriate message. | | |
| AUTH-007 | Role-based access — Admin | Admin logged in |
- Access admin-only pages (user mgmt, system settings, billing)
- Verify all admin menus are visible
|
Full access to all platform features. All admin menu items visible and functional. | | |
| AUTH-008 | Role-based access — ETO | ETO logged in |
- Access ETO pages (enrollment approvals, territory reports)
- Attempt to access admin-only pages
|
ETO can access territory-scoped features. Admin-only pages are inaccessible or hidden. | | |
| AUTH-009 | Role-based access — Tutor | Tutor logged in |
- Access tutor pages (assignments, exams, chat)
- Attempt to access admin or ETO pages
|
Tutor can access teaching features only. Admin/ETO pages inaccessible. | | |
| AUTH-010 | Role-based access — Student | Student logged in |
- Access student pages (subjects, assignments, exams, grades)
- Attempt to access tutor/admin pages
|
Student has access to learning features only. Higher-role pages inaccessible. | | |
| AUTH-011 | JWT token expiry | User logged in; token_expiry configured |
- Login and note JWT token
- Wait for token to expire
- Make API request with expired token
|
API returns 401 Unauthorized. Client redirects to login. | | |
| AUTH-012 | Invalid/tampered JWT | API running |
- Craft a request with a modified/invalid JWT
- Send to a protected endpoint
|
API returns 401 Unauthorized. Request is rejected. | | |
| ID | Description | Precondition | Steps | Expected Result | Actual Result | Status |
|---|
| ENR-001 | Student self-registration (web) | Web admin accessible; intake period open |
- Navigate to registration page
- Fill all required fields (name, email, phone, territory, rank, session)
- Select entry type: N (New)
- Submit registration
|
Student record created with admission_status = "U" (Uploaded). Admission number generated. Confirmation displayed. | | |
| ENR-002 | Student self-registration (mobile) | Mobile app installed; intake period open |
- Open mobile app
- Tap Register
- Fill all required fields
- Submit
|
Student record created with admission_status = "U". Admission number generated. Success screen shown. | | |
| ENR-003 | Admission status flow: U → N | Student registered (status U) |
- Verify student record has status "U"
- System or admin processes upload
- Status changes to "N" (Pending ETO)
|
Student status transitions from U to N. Student appears in ETO's pending approval queue. | | |
| ENR-004 | ETO approves enrollment | ETO logged in; student in territory with status "N" |
- ETO navigates to enrollment approvals
- Filters by territory
- Selects student (e.g., 2018333 Esther Mwangale)
- Reviews details and approves
|
Student status changes to "EP" (ETO Passed). Student moves to Admin approval queue. | | |
| ENR-005 | ETO rejects enrollment | ETO logged in; student in territory with status "N" |
- ETO navigates to enrollment approvals
- Selects a student
- Enters rejection reason
- Clicks Reject
|
Student status changes to "ER" (ETO Rejected). Rejection reason stored. Student notified. | | |
| ENR-006 | ETO territory scoping | ETO logged in; students from multiple territories exist |
- ETO navigates to enrollment approvals
- Verify only students from ETO's territory are visible
- Attempt to approve student from different territory
|
ETO can only see and approve students within their assigned territory. Cross-territory students not visible. | | |
| ENR-007 | Admin approves enrollment (EP → P) | Admin logged in; student with status "EP" |
- Admin navigates to enrollment approvals
- Selects student with "EP" status
- Reviews and approves
|
Student status changes to "P" (Admin Approved). Student can now access learning features. Login credentials generated. | | |
| ENR-008 | Admin rejects enrollment | Admin logged in; student with status "EP" |
- Admin selects student
- Enters rejection reason
- Clicks Reject
|
Student status changes to "AR" (Admin Rejected). Rejection reason stored. | | |
| ENR-009 | Search student by admission number | Admin/ETO logged in; student 2018333 exists |
- Navigate to student search
- Enter admission number "2018333"
- Submit search
|
Esther Mwangale's record is returned with all details. | | |
| ENR-010 | Search student by email | Admin logged in; student with known email exists |
- Navigate to student search
- Search by email address
|
Matching student record(s) returned. | | |
| ENR-011 | Search student by phone number | Admin logged in; student with known phone exists |
- Navigate to student search
- Search by phone number
|
Matching student record(s) returned. | | |
| ENR-012 | Continuing student enrollment (entry type C) | Previously approved student exists |
- Student or admin initiates continuing enrollment
- Select entry type "C" (Continuing)
- Select next academic level
- Submit
|
Student enrolled at next level. Previous records preserved. Billing differentiates new vs continuing. | | |
| ENR-013 | ETO views student biodata and previous performance during approval | ETO logged in; continuing student (entry type C) with previous performance data exists in territory |
- ETO navigates to enrollment approvals
- Clicks on a pending student record
- Verify biodata section shows: full name, email, phone, DOB, gender, marital status, rank, country, territory, admission number, registration channel
- Verify previous performance section shows: previously completed subjects, grades/scores, pass/fail status
- Verify selected subjects for current enrollment are listed
|
ETO can see full student biodata AND previous academic performance on the approval review screen. Performance data includes subject names, scores, and grades from prior enrollment levels. This enables informed approval/rejection decisions. | | |
| ENR-014 | ETO must download student list before approval | ETO logged in; pending students exist in territory |
- ETO navigates to enrollment approvals
- Click "Download Student List" (Excel export)
- Verify downloaded Excel contains: admission number, name, email, phone, entry type (N/C), territory, registration date, admission status
- Filter download by New students only
- Filter download by Continuing students only
- Verify the download includes all pending students in territory
|
Excel file downloads successfully with all student data. Filtering by New (N) and Continuing (C) entry types works correctly. The list is a prerequisite for the ETO before performing any approvals. | | |
| ENR-015 | ER (ETO Rejected) allows re-registration | Student with status "ER" exists |
- Student with ER status attempts to re-register
- Complete registration form with same email
- Submit enrollment
|
Student can re-register successfully. New enrollment record created. Status set to "N" (pending ETO). Previous ER record is not affected. | | |
| ENR-016 | AR (Admin Rejected) allows re-registration | Student with status "AR" exists |
- Student with AR status attempts to re-register
- Complete registration form
- Submit enrollment
|
Student can re-register successfully. New enrollment record created with status "N". Previous AR record unaffected. | | |
| ENR-017 | ETO tracks application progress through all stages | ETO logged in; students at various stages exist in territory |
- ETO views student list — verify students with status U, N, EP, P, ER, AR are all visible
- Click on a student with status EP — verify ETO approval date and remarks are shown
- Click on a student with status P — verify both ETO and Admin approval dates/remarks shown
- Click on a student with status ER — verify rejection reason and date are shown
- Verify status history audit trail shows every status transition with timestamps and officer names
|
ETO has full visibility into each student's application progress through ALL registration stages. Status history shows a complete JSON audit trail of every status change (U→N→EP→P or U→N→ER etc.) with who performed each action and when. | | |
| ENR-018 | Student tallying: total students with new/continuing breakdown per territory | Admin or ETO logged in; students exist across territories with entry_type N and C |
- Navigate to student tallying/dashboard
- View total number of students
- View breakdown: total new students vs total continuing students
- View breakdown per territory
- Verify ETO sees only their own territory's tallies
- Verify Admin sees all territories
|
Dashboard shows cumulative totals: total students, new students (entry_type=N), continuing students (entry_type=C). Per-territory breakdown is accurate. ETO is scoped to their territory; Admin sees all. | | |
| ENR-019 | ETO approval view shows new, continuing-registered, and continuing-unregistered students | ETO logged in; territory has mixed student types |
- Navigate to student approvals
- Verify ETO can see: new students (first-time enrollees)
- Verify ETO can see: continuing students who are already registered in the system
- Verify ETO can see: continuing students who are NOT yet registered
- Verify each category is clearly labeled or filterable
|
ETO approval page distinguishes between three categories: (1) New students, (2) Continuing students already registered, (3) Continuing students not yet registered. Each is clearly identifiable and filterable. | | |
| ENR-020 | Auto-capture registration number for continuing students (no "NA") | Continuing student enrolls; they previously had an admission_no in the system |
- Continuing student starts enrollment process
- Student enters their existing registration number
- Verify the system captures and stores the registration number entered by the student
- Verify the system does NOT default to "NA" for continuing students
- Verify ETO/Admin see the correct registration number during approval
|
The system automatically captures the registration number entered by the continuing student. No "NA" placeholder is used. This avoids rejection and repetition of the enrollment process, especially when handling large numbers of students. | | |
| ENR-021 | Re-upload previous performance records after approval | Continuing student has been approved at both ETO and Admin levels; some subjects are missing from previous performance |
- Admin identifies a continuing student with missing subjects in their previous performance records
- Navigate to the student's performance management page
- Upload/re-upload previous performance records (subjects and scores)
- Verify the newly uploaded subjects appear in the student's record
- Verify this can be done AFTER the student has already been approved
|
System allows re-uploading of previous performance records for continuing students even after approval at both ETO and Admin levels. Missing subjects can be added without requiring the student to re-enroll. Previously uploaded data is preserved. | | |
| ID | Description | Precondition | Steps | Expected Result | Actual Result | Status |
|---|
| SUB-001 | View learning levels | Admin logged in |
- Navigate to curriculum management
- View available learning levels
|
Three levels displayed: Foundation, Certificate, Diploma. Each with correct subjects. | | |
| SUB-002 | Create new subject | Admin logged in |
- Navigate to subject management
- Click Add Subject
- Enter subject code (e.g., FPNT02), name, learning level, cost
- Save
|
Subject created with correct code format. Appears in subject list under appropriate level. | | |
| SUB-003 | Soldier progression path | Student with Soldier rank, approved enrollment |
- Verify Foundation subjects available
- Complete Foundation level
- Verify Certificate subjects become available
- Complete Certificate
- Verify Diploma subjects become available
|
Soldiers follow Foundation → Certificate → Diploma path. Each level unlocks sequentially. | | |
| SUB-004 | Non-Soldier progression path | Student without Soldier rank, approved enrollment |
- Verify Foundation is skipped
- Certificate subjects available directly
- Complete Certificate
- Diploma subjects become available
|
Non-Soldiers follow Certificate → Diploma path (no Foundation). Correct subjects displayed. | | |
| SUB-005 | Student selects subjects | Student logged in; enrolled at a learning level |
- Navigate to subject selection
- View available subjects for current level
- Select subjects
- Confirm selection
|
Records created in tbl_student_subjects_selection. Subject costs calculated. Selection status = "P" (Pending). | | |
| SUB-006 | Subject cost tracking | Admin logged in; subjects with costs configured |
- View subject details
- Verify cost field is populated
- Enroll student in subject
- Verify cost appears in billing
|
Subject costs correctly tracked and reflected in student billing calculations. | | |
| SUB-007 | Subject level gating — student cannot access next level before completing current | Student enrolled at Foundation level with incomplete subjects |
- Student views subjects — only Foundation subjects visible
- Attempt to apply for Certificate level while Foundation subjects are incomplete
- Verify system rejects the request
- Complete all Foundation subjects with passing grades
- Apply for Certificate level again
|
System blocks access to next level subjects until ALL subjects in current level are completed with passing grades. After completion, next level subjects become visible and enrollment is allowed. | | |
| SUB-008 | Admin configures subject grouping and level count | Admin logged in |
- Navigate to Learning Levels configuration
- View existing levels (Foundation, Certificate, Diploma)
- Verify subject counts per level are accurate
- Verify admin can adjust level configuration
|
Admin can view and configure learning levels. Subject-to-level assignments are correct. Level progression depends on the number of levels configured by admin. | | |
| SUB-009 | Student can only view subjects in their current level | Student enrolled at Certificate level; Foundation completed |
- Student logs in and navigates to Subjects
- Verify only Certificate-level subjects are shown for selection
- Verify Foundation subjects show as "Completed" (view only)
- Verify Diploma subjects are NOT visible until Certificate is completed
|
Students see only their current level subjects for active enrollment. Completed level subjects are viewable but read-only. Next level subjects are hidden until progression criteria are met. | | |
| SUB-010 | Tutor-subject assignment during student approval | Admin approving student; subjects selected by student |
- Admin reviews student's selected subjects during approval
- For each subject, assign a tutor from available tutors
- Approve all subjects
- Verify tutor receives the student in their assigned subject list
|
Tutor-subject-student relationship created correctly. Tutor can see the student under their assigned subjects. Student can access materials/assignments for the subject. | | |
| ID | Description | Precondition | Steps | Expected Result | Actual Result | Status |
|---|
| ASG-001 | Tutor uploads assignment | Tutor logged in; assigned to subject |
- Navigate to assignment management
- Select subject
- Upload assignment file (PDF/DOCX)
- Set title and instructions
- Save
|
Assignment created in tbl_materials_upload. File stored in MinIO. Visible to enrolled students. | | |
| ASG-002 | Monthly upload limit enforcement | Tutor has uploaded 3 assignments for a subject this month (max configured) |
- Attempt to upload a 4th assignment for same subject in same month
|
System prevents upload. Error message: maximum assignments per month reached. | | |
| ASG-003 | Student downloads assignment | Student enrolled in subject; assignment uploaded |
- Navigate to assignments
- Select subject
- View assignment
- Download assignment file
|
Assignment file downloaded successfully. Content matches uploaded file. | | |
| ASG-004 | Student submits assignment | Student enrolled; assignment available |
- Navigate to assignment submission
- Select assignment
- Upload completed work (PDF/DOCX)
- Submit
|
Submission recorded. Status = "N" (New). File stored in MinIO under student_assignments/. Timestamp recorded. | | |
| ASG-005 | Tutor marks assignment | Tutor logged in; student submission exists |
- Navigate to unmarked assignments
- Select student submission
- Download and review
- Enter score and remarks
- Submit marking
|
Mark recorded in tbl_assignment_marking. Status changes to "R" (Reviewed). Student can view score. | | |
| ASG-006 | Late assignment handling | Assignment deadline passed; student attempts submission |
- Student attempts to submit after deadline
- System flags as late
- Admin reviews late submission request
- Admin approves/rejects
|
Late submission requires admin approval. If approved, submission proceeds. If rejected, student notified. | | |
| ASG-007 | Assignment retake (failed) | Student scored below pass threshold; retakes < 3 |
- Student requests assignment retake
- System verifies retake count < 3
- Student submits new work
|
Retake allowed (up to 3 attempts). New submission recorded with retake count incremented. Previous scores preserved. | | |
| ASG-008 | Assignment reports (marked/unmarked) | Admin/Tutor logged in; assignments exist in various states |
- Navigate to assignment reports
- Filter by marked/unmarked status
- Filter by subject/territory
|
Report shows accurate counts and details for marked and unmarked assignments. Filters work correctly. | | |
| ASG-009 | Student monthly submission limit (configurable) | Admin has configured max_assignments_per_month=3 in System Settings; student logged in |
- Student submits 3 assignments for the same subject in the current month
- Student attempts to submit a 4th assignment for the same subject in the same month
- Admin changes max_assignments_per_month to 5 in System Settings
- Student can now submit additional assignments
|
System enforces the admin-configured monthly submission limit per subject. After 3 submissions (default), further submissions are blocked with a clear message. Changing the limit in System Settings takes effect immediately. | | |
| ASG-010 | Assignment date filter accuracy | Assignments uploaded across multiple months; Admin/Tutor logged in |
- Navigate to assignment reports
- Filter by upload month (e.g., September)
- Verify only September assignments are displayed (not August or October)
- Repeat for other months to confirm accuracy
|
System displays assignments from the exact selected month. No off-by-one errors in date filtering. The filter matches the actual upload timestamp, not a shifted month. | | |
| ID | Description | Precondition | Steps | Expected Result | Actual Result | Status |
|---|
| EXM-001 | Create MCQ exam paper | Tutor logged in; subject assigned |
- Navigate to exam management
- Click Create Exam Paper
- Select subject, set title, duration
- Add MCQ questions with options and correct answers
- Save paper
|
Exam paper created in tbl_exam_paper. Questions stored in tbl_questions. Paper linked to subject. | | |
| EXM-002 | Create essay exam paper | Tutor logged in; subject assigned |
- Create exam paper
- Add essay-type questions
- Save
|
Essay exam paper created. Questions do not have auto-grading options. | | |
| EXM-003 | Schedule exam date | Exam paper created; admin/tutor logged in |
- Navigate to exam scheduling
- Select exam paper
- Set date, start time, end time
- Confirm schedule
|
Exam date recorded in tbl_exam_dates. Enrolled students can see scheduled exam. | | |
| EXM-004 | Student takes online MCQ exam | Exam scheduled; student enrolled; exam window open |
- Student navigates to exams
- Clicks Start Exam
- Answers MCQ questions
- Submits exam before time expires
|
Answers saved in tbl_paper_answer. MCQ auto-graded. Score calculated and displayed. Quiz record in tbl_student_quiz. | | |
| EXM-005 | Exam timer enforcement | Student taking timed exam |
- Start exam
- Let timer reach zero without submitting
|
Exam auto-submitted when time expires. Answered questions graded; unanswered marked as incorrect. | | |
| EXM-006 | Downloadable exam (PDF) | Tutor creates downloadable exam with PDF upload |
- Tutor creates exam paper with downloadable=true
- Uploads exam PDF
- Sets submission deadline
- Student downloads exam PDF
- Student uploads answer PDF before deadline
|
Exam PDF downloadable. Student uploads answer file. Submission timestamp recorded. Late submissions blocked after deadline. | | |
| EXM-007 | Exam retake (failed) | Student failed exam; retake count < 3 |
- Student requests exam retake
- System verifies retake eligibility
- Student takes exam again
|
Retake allowed (up to 3 attempts). New quiz record created. Previous attempt preserved. Retake count incremented. | | |
| EXM-008 | Oral exam score entry | Tutor logged in; student completed oral exam |
- Navigate to exam marking
- Select student and oral exam
- Enter oral exam score
- Save
|
Oral score saved. Contributes to overall grade calculation alongside written exam and assignments. | | |
| EXM-009 | Quiz auto-population | Exam paper created; students enrolled in subject |
- Admin/Tutor creates exam for subject
- Verify quiz records auto-created for all enrolled students
|
Quiz records in tbl_student_quiz auto-generated for each enrolled student. All have pending status. | | |
| EXM-010 | Tutor marks essay exam | Student submitted essay answers |
- Tutor navigates to exam marking
- Selects essay submission
- Reviews answers
- Enters scores per question
- Submits marks
|
Essay scores recorded. Total calculated. Student can view results. | | |
| EXM-011 | Exam results view (student) | Student completed and graded exam |
- Student navigates to results/grades
- Views exam results
|
Student can see score, grade, and correct/incorrect answers for MCQ. Essay scores visible after tutor marking. | | |
| EXM-012 | Exam report generation | Admin/Tutor logged in; completed exams exist |
- Navigate to exam reports
- Filter by subject, date range, territory
- View/export report
|
Report shows exam performance metrics: pass rate, average score, distribution. Export to Excel/PDF works. | | |
| EXM-013 | Retake limit enforcement (3 attempts max) | Student has failed an exam 3 times for a subject |
- Student attempts a 4th retake of the same exam
- Verify system blocks the retake
- Verify student can no longer access online assignments and exams for that subject
|
After 3 failed attempts, student is blocked from further online exam/assignment access for the subject. System displays a clear message explaining the retake limit has been reached and oral examination is required. | | |
| EXM-014 | Oral exam after 3 failed attempts | Student has exhausted 3 retake attempts; Admin/Tutor logged in |
- Tutor/Admin navigates to oral exam score entry
- Selects the student who has exhausted retakes
- Enters oral assignment score and oral exam score manually
- Saves the scores
- Verify the scores contribute to the final grade calculation
|
Oral scores are manually entered for both assignments and exams. Scores are recorded and integrated into the grading formula. The student's final grade reflects the oral assessment results alongside any previous scores. | | |
| ID | Description | Precondition | Steps | Expected Result | Actual Result | Status |
|---|
| GRD-001 | Verify grading thresholds | Grading config seeded (Flyway V5) |
- Query
tbl_grading_config - Verify 6 tiers: High Distinction (85-100), Distinction (75-84.99), Credit (65-74.99), Merit (55-64.99), Pass (50-54.99), Fail (0-49.99)
|
All 6 grading tiers present with correct ranges. No gaps or overlaps. | | |
| GRD-002 | Weighted grade calculation | Student has assignment score and exam score for a subject |
- Verify assignment_weight_pct + exam_weight_pct = 100% in system settings
- Calculate expected weighted grade manually
- Compare with system-calculated grade
|
System grade matches manual calculation: (assignment_score * assignment_weight / 100) + (exam_score * exam_weight / 100). | | |
| GRD-003 | Grade tier assignment | Student has calculated weighted score |
- Check student's weighted score
- Verify correct grade tier assigned based on thresholds
|
Score of 87 = High Distinction, 76 = Distinction, 66 = Credit, 56 = Merit, 51 = Pass, 45 = Fail. | | |
| GRD-004 | Student grade summary | Student logged in; has grades in multiple subjects |
- Navigate to grades/performance page
- View summary across all subjects
|
All subjects listed with individual scores, weighted grades, and grade tiers. Overall GPA/average displayed. | | |
| GRD-005 | Admin edits final score | Admin logged in; student has a calculated grade |
- Navigate to grade management
- Select student and subject
- Edit final score
- Save with reason
|
Final score updated. Audit trail records the change with admin name and reason. Grade tier recalculated. | | |
| GRD-006 | Configurable grading weights | Admin logged in |
- Navigate to system settings
- Change assignment_weight_pct and exam_weight_pct
- Save
- Verify new weights applied to future calculations
|
Weight changes saved. New calculations use updated weights. Existing grades not retroactively changed. | | |
| ID | Description | Precondition | Steps | Expected Result | Actual Result | Status |
|---|
| SUS-001 | 1-year deadline tracking | Student enrolled in subject with start date > 1 year ago |
- Verify subject selection record has start date
- Check if 1-year deadline has passed
|
System correctly identifies students past the 1-year completion deadline. | | |
| SUS-002 | Automatic suspension (scheduled job) | Daily scheduler configured; student past deadline |
- Wait for scheduled job to run (or trigger manually)
- Verify student with expired deadline is suspended
|
Student's subject selection flagged as suspended. Suspension log entry created with auto-generated comment. | | |
| SUS-003 | Admin lifts suspension | Admin logged in; student is suspended |
- Navigate to suspension management
- Select suspended student
- Enter reason for lifting
- Click Lift Suspension
|
Suspension removed. Student can resume subject. Log entry records who lifted and why. | | |
| SUS-004 | Admin declines suspension lift | Admin logged in; student requests suspension lift |
- Review suspension lift request
- Enter decline reason
- Click Decline
|
Suspension remains. Student notified of decline. Log entry records decision and reason. | | |
| SUS-005 | Suspension log audit trail | Admin logged in; suspensions have been processed |
- Navigate to suspension logs
- View history for a specific student
|
Complete log showing: suspension date, reason, who lifted/declined, timestamps, comments. | | |
| SUS-006 | Admin searches for suspended students | Admin logged in; multiple students have expired subject deadlines |
- Navigate to Suspension Management
- View list of all suspended students
- Search/filter by territory, subject, or suspension date
- Verify each entry shows: student name, admission number, subject, enrollment date, suspension date, territory
|
Admin sees a searchable list of all students who failed to complete their subject within 1 year. List includes all relevant details for decision-making. | | |
| SUS-007 | ETO notification of suspension | Student in ETO's territory has been suspended |
- Verify ETO has been formally communicated about the suspension
- ETO can view suspended students in their territory
|
ETO is notified of student suspensions in their territory. The communication includes student details and suspension reason. | | |
| SUS-008 | Lifted suspension resets 1-year deadline | Admin has lifted a student's suspension |
- Admin lifts suspension with comments
- Verify student's subject enrollment is re-activated
- Verify a new 1-year deadline is set from the lift date
- Student can access subject materials and submit assignments again
|
After suspension is lifted, student starts over with a fresh 1-year completion window. Previous progress is preserved but the deadline counter resets. | | |
| ID | Description | Precondition | Steps | Expected Result | Actual Result | Status |
|---|
| CRT-001 | Generate certificate PDF | Student completed all subjects in a level with passing grades |
- Admin navigates to certificate generation
- Selects eligible student
- Clicks Generate Certificate
- Downloads PDF
|
PDF generated with: student name, level completed, date, unique serial number, QR code. Format is professional and correct. | | |
| CRT-002 | Certificate serial number uniqueness | Multiple certificates generated |
- Generate certificates for 3 different students
- Compare serial numbers
|
Each certificate has a unique serial number. No duplicates in tbl_certificates. | | |
| CRT-003 | QR code verification (public) | Certificate with QR code generated |
- Scan QR code on certificate
- Follow URL (no authentication required)
|
Public verification page displays: student name, level, date, serial number. Confirms certificate authenticity. No login required. | | |
| CRT-004 | Generate transcript PDF | Student has grades across multiple subjects |
- Navigate to transcript generation
- Select student
- Generate transcript
- Download PDF
|
Transcript PDF contains: all subjects, individual scores, weighted grades, grade tiers, overall average. Formatted professionally. | | |
| CRT-005 | Certificate for ineligible student | Student has incomplete or failed subjects |
- Attempt to generate certificate for student who hasn't completed level
|
System prevents certificate generation. Message indicates which requirements are not met. | | |
| ID | Description | Precondition | Steps | Expected Result | Actual Result | Status |
|---|
| FIL-001 | Upload file to MinIO | MinIO running; salt-files bucket exists |
- Upload a file via any upload feature (assignment, reading material)
- Verify in MinIO console
|
File stored in MinIO salt-files bucket. Path follows territory-based structure. File accessible via API. | | |
| FIL-002 | Download file from MinIO | File previously uploaded to MinIO |
- Request file download via API
- Verify file content
|
File downloaded correctly. Content matches original upload. Correct MIME type returned. | | |
| FIL-003 | Dual-read fallback to filesystem | File exists in /opt/salt_files but NOT in MinIO |
- Ensure file exists only in legacy path
- Request file download
|
System tries MinIO first, falls back to /opt/salt_files. File returned successfully from legacy path. | | |
| FIL-004 | File size limit (100MB) | Server configured with max-file-size=100MB |
- Upload a file just under 100MB
- Upload a file over 100MB
|
Under-limit file uploads successfully. Over-limit file rejected with clear error message. | | |
| FIL-005 | File path structure verification | Files uploaded for different territories |
- Upload files for Kenya (+254) and Rwanda (+250) territories
- Check MinIO/filesystem paths
|
Files organized by territory code: +254/, +250/. Structure matches legacy salt_files/ layout. | | |
| FIL-006 | Material reuse across multiple intakes | Admin logged in; existing reading material or assignment available |
- Navigate to an existing reading material or assignment
- Click Reuse Material
- Select multiple intake periods (months) for which the material should be reused
- Confirm the reuse
- Verify the material appears in the selected intake periods
|
Admin can reuse materials on a monthly basis across multiple intake periods within a year. Material is linked to selected intakes without re-uploading. Students in the target intakes can access the reused material. | | |
| FIL-007 | Marking comments/remarks downloadable as marking scheme | Tutor has marked assignments/exams with comments; student and admin logged in |
- Tutor marks an assignment with detailed comments/remarks
- Student views the marked assignment — verify comments are visible
- Admin views the marked assignment — verify comments are visible
- Download the assignment record with marking comments
- Verify the downloaded file includes all tutor comments
|
All tutor comments on marked assignments and exams are treated as the marking scheme. Comments are accessible to the student, tutor, and admin. The archived comments/marking scheme are downloadable. | | |
| ID | Description | Precondition | Steps | Expected Result | Actual Result | Status |
|---|
| RPT-001 | Admin dashboard real-time stats | Admin logged in; data exists |
- Navigate to admin dashboard
- Review displayed statistics
|
Dashboard shows: total students, active enrollments, pending approvals, recent activity. Data is current. | | |
| RPT-002 | Enrollment trends report | Admin logged in; enrollment data across multiple periods |
- Navigate to enrollment reports
- Select date range
- View trends
|
Chart/table showing enrollment numbers over time. Filterable by territory, level, status. | | |
| RPT-003 | Assignment submission analytics | Admin/Tutor logged in; assignment data exists |
- Navigate to assignment reports
- View submission rates
|
Report shows: total assigned, submitted, pending, late submissions. Per subject and per territory breakdowns. | | |
| RPT-004 | Exam performance metrics | Admin logged in; exam results exist |
- Navigate to exam reports
- View performance metrics
|
Metrics include: pass rates, average scores, score distributions, highest/lowest performers. | | |
| RPT-005 | Territory-level breakdown | Admin logged in; multi-territory data exists |
- Navigate to territory reports
- Compare across territories
|
Side-by-side territory comparison: student counts, pass rates, assignment completion, active subjects. | | |
| RPT-006 | Student tallying (new vs continuing) | Admin logged in; both new and continuing students exist |
- Navigate to student tallying report
- Filter by entry type
|
Report distinguishes new (N) vs continuing (C) students. Totals per subject and per territory. | | |
| RPT-007 | Excel export from reports | Admin logged in; report with data displayed |
- Generate any report
- Click Export to Excel
- Open file
|
Excel file generated with Apache POI. Data matches on-screen report. Columns properly labeled. File opens correctly. | | |
| RPT-008 | PDF export from reports | Admin logged in; report with data displayed |
- Generate report
- Click Export to PDF
- Open file
|
PDF generated with OpenPDF. Formatted professionally. Data matches on-screen report. | | |
| ID | Description | Precondition | Steps | Expected Result | Actual Result | Status |
|---|
| DAT-001 | Partial UNIQUE indexes on active records | Flyway V7 migration applied |
- Attempt to create two active students with same admission_no
- Verify constraint violation
|
Database rejects duplicate active admission_no. Constraint applies only to active records (not deleted/archived). | | |
| DAT-002 | BOM cleanup trigger | BOM triggers installed (remove_bom, remove_bom_on_users) |
- Insert a student record with BOM characters in admission_no (e.g., "2011278#")
- Query the record
|
BOM characters automatically stripped by trigger. Stored value is clean (e.g., "2011278"). | | |
| DAT-003 | Admission status audit trail | Student exists; status changes occur |
- Change student admission status through approval flow
- Query audit trail (JSON history field)
|
Each status change recorded with: old status, new status, changed_by, timestamp, reason. Full history preserved. | | |
| DAT-004 | Daily integrity checks (scheduled) | Scheduler configured; data exists |
- Wait for daily integrity check to run (or trigger manually)
- Review integrity log
|
Check results logged in tbl_data_integrity_log. Issues identified and flagged. No false positives. | | |
| DAT-005 | Schema management admin page | Admin logged in |
- Navigate to schema management page
- View current schema status
- View Flyway migration history
|
Page shows applied migrations (V1-V7), current schema version, table statistics, and index status. | | |
| DAT-006 | Data export (full backup) | Admin logged in |
- Navigate to data export
- Select export type (students, users, enrollments, or full)
- Initiate export
- Download file
|
Export file generated in appropriate format. Data complete and accurate. File downloadable. | | |
| ID | Description | Precondition | Steps | Expected Result | Actual Result | Status |
|---|
| MOB-001 | Student registration (mobile) | App installed; intake open |
- Open app
- Tap Register
- Fill: name, email, phone, territory, rank, session
- Submit
|
Registration successful. Confirmation screen displayed. Student record created in backend. | | |
| MOB-002 | Student login (mobile) | Approved student account exists |
- Open app
- Enter credentials
- Complete OTP step
|
Login successful. Student dashboard displayed with subjects, announcements, notifications. | | |
| MOB-003 | Subject selection and level view | Student logged in; enrolled at a level |
- Navigate to subjects
- View current level subjects
- Select available subjects
|
Subjects displayed for current level. Selection saved. Correct level progression enforced. | | |
| MOB-004 | Assignment upload (mobile) | Student logged in; assignment available |
- Navigate to assignments
- Select assignment
- Upload answer file from device
- Submit
|
File uploaded to MinIO. Submission recorded. Confirmation shown. File accessible by tutor. | | |
| MOB-005 | Online exam (mobile) | Student logged in; exam scheduled and open |
- Navigate to exams
- Start available exam
- Answer questions
- Submit
|
Exam loads correctly on mobile. Timer visible. Questions navigable. Submission successful. Score displayed for MCQ. | | |
| MOB-006 | Downloadable exam (mobile) | Downloadable exam available |
- Navigate to exams
- Download exam PDF
- Complete offline
- Upload answer PDF
|
PDF downloads to device. Answer upload works within deadline. Late upload blocked. | | |
| MOB-007 | Performance/grades view | Student logged in; has grades |
- Navigate to grades/performance
- View subject grades
|
All subject grades displayed with scores, weighted grades, and grade tiers. Charts/visuals render correctly. | | |
| MOB-008 | Chat with tutors (mobile) | Student logged in; tutor assigned |
- Open chat screen
- Select tutor
- Send message
- Receive reply
|
Messages send and receive. History persists. Unread count updates. No message loss. | | |
| MOB-009 | Chatbot with escalation (mobile) | Student logged in; FAQs configured |
- Open chatbot
- Ask question
- If unsatisfied, escalate
- Attach image if needed
|
Chatbot responds from FAQ. Escalation creates support ticket. Image attachment works. | | |
| MOB-010 | Profile update (mobile) | Student logged in |
- Navigate to profile
- Update allowed fields (phone, email)
- Save
|
Profile updated successfully. Changes reflected in backend. Non-editable fields (admission_no) remain locked. | | |
| ID | Description | Precondition | Steps | Expected Result | Actual Result | Status |
|---|
| EXD-001 | Public overview access (no auth) | Dashboard deployed; data exists |
- Open executive dashboard URL without logging in
- View overview page
|
Public overview page loads. Shows high-level statistics (enrollment count, territory count, etc.). No sensitive data exposed. | | |
| EXD-002 | Authenticated detailed reports | Admin logged in to dashboard |
- Login to executive dashboard
- Access detailed reports section
|
Detailed analytics available: student demographics, performance breakdowns, financial summaries. Data accurate. | | |
| EXD-003 | Enrollment trends charts | Dashboard accessible; enrollment data spans multiple periods |
- Navigate to enrollment trends
- View charts (fl_chart)
- Interact with chart (hover, filter)
|
Charts render correctly. Data points accurate. Filtering by territory/date works. Responsive on different screen sizes. | | |
| EXD-004 | Performance metrics visualization | Dashboard accessible; exam/assignment data exists |
- Navigate to performance metrics
- View pass rates, averages, distributions
|
Metrics displayed as charts/graphs. Data matches backend reports. Visual representation clear and accurate. | | |
| EXD-005 | Territory breakdown view | Dashboard accessible; multi-territory data |
- Navigate to territory breakdown
- Compare territories
|
Each territory (Kenya, Rwanda, Burundi, Zimbabwe, etc.) shown with key metrics. Comparison view functional. | | |
| ID | Description | Precondition | Steps | Expected Result | Actual Result | Status |
|---|
| MRK-001 | Tutor views marking progress for their subjects | Tutor logged in; students have submitted assignments and exams |
- Navigate to marking dashboard or progress view
- View the list of subjects assigned to the tutor
- For each subject, verify counts of: total submissions, marked, pending
- Verify progress percentage is displayed
|
Tutor sees a clear breakdown of marking progress per subject: total assignments/exams submitted, number marked (status T or P), number pending (status N). Progress is trackable from beginning to completion. | | |
| MRK-002 | Admin views marking progress across all subjects | Admin logged in; marking data exists across subjects and tutors |
- Navigate to marking progress analytics
- View marking progress for all subjects
- Filter by tutor, subject, or territory
- Verify total, marked, and pending counts are accurate
|
Admin sees a platform-wide view of marking progress. Data is filterable by tutor, subject, and territory. Counts match actual data in tbl_assignment_marking. Admin can identify tutors who are behind on marking. | | |
| MRK-003 | Student views their own marking status | Student logged in; has submitted assignments and exams |
- Navigate to assignments/performance
- View the status of each submitted assignment (Pending, Marked, Approved)
- View the status of each submitted exam
|
Student can see the marking status for each submission: N (Pending marking), R (Reviewed by tutor), T (Tutor marked), P (Admin approved). Student has visibility into the marking process from submission to final approval. | | |
| MRK-004 | Marking progress updates in real-time | Tutor marks an assignment; Admin and student are viewing progress |
- Tutor marks a pending assignment
- Verify tutor's marking progress count updates
- Verify admin's marking progress dashboard reflects the change
- Verify student sees the updated status on their submission
|
After tutor marks an assignment, all three roles (Tutor, Admin, Student) see the updated status on their next page load. Progress tracking is consistent across all views. | | |
| ID | Description | Precondition | Steps | Expected Result | Actual Result | Status |
|---|
| PRF-001 | Student updates profile (web) | Student logged in to web admin |
- Navigate to Profile page
- Update first name, middle name, last name
- Update email address
- Update phone number
- Update marital status
- Update session preference
- Update Salvation Army rank
- Save changes
|
All editable fields are saved. Non-editable fields (admission number, territory) remain locked and cannot be changed. Updated values reflected immediately in the student's profile and visible to Admin/ETO. | | |
| PRF-002 | Student updates profile (mobile) | Student logged in to mobile app |
- Navigate to Profile screen
- Update name, email, phone, marital status, session, rank
- Tap Save
- Verify changes persist after app restart
|
Profile updated successfully on mobile. Changes synced to backend. Same fields editable/locked as web version. Changes persist after logout and re-login. | | |
| PRF-003 | Admin/ETO/Tutor updates their own profile | Non-student user logged in |
- Navigate to Profile settings
- Update name, email, phone number, preferred language
- Save changes
|
Non-student users can update their own profile information. Changes saved and reflected across the system. Email uniqueness is enforced (cannot use another user's email). | | |
| PRF-004 | Profile update validates unique fields | User logged in; another user exists with a known email/phone |
- Attempt to change email to another user's email
- Attempt to change phone to another user's phone
|
System rejects duplicate email and phone number. Appropriate error messages displayed. Original profile remains unchanged. | | |
| ID | Description | Precondition | Steps | Expected Result | Actual Result | Status |
|---|
| CSV-001 | Valid CSV upload with correct format | Admin logged in; CSV file with valid admission numbers and 17-column subject rows prepared |
- Navigate to student data restore / CSV upload
- Select a valid CSV file containing at least 2 students with multiple subject rows each
- Submit the upload via
POST /admin/restore_students/{id} - Verify response indicates success
- Query
tbl_student_subjects_selection to confirm records created
|
All student-subject records created correctly. Assignment scores (1–10), avg_assignment, total_exam, and total_max_awarded stored accurately. Each single-value row correctly parsed as admission number header grouping subsequent subject rows. | | |
| CSV-002 | CSV with invalid column count (not 1 or 17) | Admin logged in; CSV file with rows having incorrect column count (e.g., 10 columns) |
- Prepare CSV with a row containing fewer or more than 17 columns (e.g., missing assignment columns)
- Upload via the endpoint
- Observe response
|
Server returns a clear error message identifying the malformed row(s). No partial data is persisted. Response indicates which line number(s) have invalid column counts. | | |
| CSV-003 | Assignment scores outside 0–100 range | Admin logged in; CSV file with assignment scores exceeding valid range (e.g., -5 or 150) |
- Prepare CSV where one or more assignment1–10 values are outside 0–100
- Upload via the endpoint
- Observe validation response
|
Server rejects the upload with a validation error identifying the out-of-range score(s) and their row/column position. No records created for the invalid student block. | | |
| CSV-004 | Assignment average outside 0–50 range | Admin logged in; CSV file with avg_assignment value exceeding 50 (e.g., 55) |
- Prepare CSV where avg_assignment (column 15) is greater than 50 or negative
- Upload via the endpoint
- Observe validation response
|
Server rejects the row with a validation error. The avg_assignment field must be in range 0–50. Error message clearly identifies the offending value. | | |
| CSV-005 | Invalid exam date format | Admin logged in; CSV file with incorrectly formatted exam_date (e.g., 2026-12-31 instead of MM/dd/yyyy) |
- Prepare CSV with exam_date in wrong format (ISO, dd-MM-yyyy, etc.)
- Upload via the endpoint
- Observe error handling
|
Server returns a parse error identifying the invalid date and expected format MM/dd/yyyy. No records created for that student block. | | |
| CSV-006 | Non-existent subject code | Admin logged in; CSV file references a subject_code not in tbl_subjects |
- Prepare CSV with a fabricated subject_code (e.g.,
ZZ999) - Upload via the endpoint
- Observe error handling
|
Server returns an error indicating the subject code was not found in the system. The error identifies which admission number and subject code failed. Valid rows for other students may still be processed (or entire upload rejected, depending on implementation). | | |
| CSV-007 | Subject assigned to wrong learning level | Admin logged in; CSV references a subject_code with a learning_level_id that does not match the subject's actual level in tbl_subjects |
- Prepare CSV where subject_code exists but learning_level_id does not match (e.g., Foundation subject with Diploma level ID)
- Upload via the endpoint
- Observe validation
|
Server detects the mismatch between subject_code and learning_level_id. Returns error identifying the conflicting row. No incorrect enrollment created. | | |
| CSV-008 | Student not found (auto-create behavior) | Admin logged in; CSV contains an admission_no that does not exist in tbl_student |
- Prepare CSV with a non-existent admission number (e.g.,
9999999) - Upload via the endpoint
- Verify whether student record is auto-created or error returned
- If auto-created, verify minimal student record in
tbl_student
|
System either (a) auto-creates a stub student record with the admission number and processes the subject data, or (b) returns an error listing the unrecognized admission number(s). Behavior must be consistent and documented. | | |
| CSV-009 | Duplicate upload (idempotency check) | Admin logged in; same CSV file already uploaded once successfully |
- Upload a valid CSV file and confirm success
- Upload the exact same CSV file a second time
- Check
tbl_student_subjects_selection for duplicate records
|
System either (a) skips already-existing records and returns a summary (created vs. skipped counts), or (b) updates existing records without creating duplicates. No duplicate enrollment rows exist after the second upload. | | |
| CSV-010 | CSV with BOM characters in admission numbers | Admin logged in; CSV file saved with UTF-8 BOM encoding, or admission numbers contain # suffix artifacts |
- Prepare CSV file with BOM byte prefix (common from Excel exports)
- Include admission numbers with trailing
# (e.g., 2011278#) - Upload via the endpoint
- Verify admission numbers are cleaned before lookup
|
BOM bytes stripped from first admission number. Trailing # characters removed. The remove_bom() database trigger and application-level cleaning ensure correct matching to existing student records. | | |
| CSV-011 | Zero assignment score zeroing behavior | Admin logged in; CSV file where one or more assignment scores are 0 |
- Prepare CSV with one student where assignment3 = 0 (all others non-zero)
- Upload via the endpoint
- Check the stored avg_assignment and total_max_awarded values
- Prepare another CSV where all 10 assignments are 0
- Upload and verify totals
|
If any single assignment score is 0, verify whether the system zeros out all totals (avg_assignment and total_max_awarded become 0) or calculates the average excluding the zero. Document the observed behavior. The zeroing rule, if present, must be consistently applied. | | |
| CSV-012 | Large file with multiple students | Admin logged in; CSV file with 50+ students, each having 3–5 subject rows |
- Prepare a large CSV file with at least 50 student groups
- Upload via the endpoint
- Monitor response time
- Verify all records created correctly
- Check for timeouts or partial failures
|
All student-subject records processed successfully without timeout. Response includes a summary (total students processed, total subject records created). Processing completes within reasonable time (< 30 seconds for 50 students). | | |
| ID | Description | Precondition | Steps | Expected Result | Actual Result | Status |
|---|
| E2E-ENR-01 | New student self-registration through full approval chain | Registration endpoint accessible; ETO and Admin accounts exist for the student's territory |
- Student registers via
/auth/register with personal details and territory - Verify student created in
tbl_student with admission_status = P (Pending) - ETO logs in, views pending students for their territory
- ETO approves the student
- Admin logs in, views ETO-approved students
- Admin approves the student
- Verify admission_status changes to
D (Done) - Verify admission_no is generated
- Student logs in and selects subjects for enrollment
- Verify selections appear in
tbl_student_subjects_selection
|
Complete enrollment chain works: Registration → ETO approval → Admin approval → Admission number assigned → Student can log in and select subjects. Status transitions: P → EP (ETO pending) → D (Done). Subject selections created with pending approval status. | | |
| E2E-ENR-02 | Continuing student enrollment (level progression) | Student has completed all Foundation subjects; Admin logged in |
- Verify student has passing grades in all Foundation subjects
- Admin or system advances student to Certificate level
- New academic level record created in
tbl_academic_level - Student logs in and sees Certificate-level subjects available
- Student selects Certificate subjects
- Verify enrollment at new level in
tbl_student_subjects_selection
|
Student seamlessly progresses from Foundation to Certificate level. Previous Foundation grades preserved. New academic level record created. Certificate subjects available for selection. No data loss from previous level. | | |
| E2E-ENR-03 | Cross-territory admission | Student registers under territory A; ETO exists for territory A; Admin has cross-territory access |
- Student registers with a territory different from their physical location
- ETO of the target territory reviews and approves
- Admin reviews cross-territory request
- Admin approves with territory assignment
- Verify student is enrolled under the correct territory
- Verify territory-specific tutor can see the student
|
Cross-territory enrollment requires both ETO and Admin approval. Student is correctly assigned to the target territory. Territory-bound users (ETO, Tutor) in the target territory can see and manage the student. Territory code correctly recorded. | | |
| E2E-ENR-04 | Bulk CSV enrollment by admin | Admin logged in; CSV file with multiple new students prepared |
- Admin prepares CSV with student data (names, territories, admission numbers)
- Admin uploads CSV via bulk enrollment endpoint
- Verify students created in
tbl_student and tbl_sys_users - Verify admission_status set to
U (Uploaded) - Admin reviews and activates bulk-uploaded students
- Students can log in with generated credentials
|
Bulk enrollment creates student records efficiently. Each student gets a user account and student record. Admission status is U (Uploaded) until admin activates. Generated credentials allow students to log in. Duplicate admission numbers are detected and reported. | | |
| ID | Description | Precondition | Steps | Expected Result | Actual Result | Status |
|---|
| E2E-ASG-01 | Full assignment lifecycle: upload through grading | Tutor assigned to subject; students enrolled in subject; Admin account available |
- Tutor logs in and navigates to assignment management
- Tutor uploads a new assignment (PDF/DOCX) for their subject
- Verify assignment appears in
tbl_materials_upload with correct subject linkage - Student logs in and sees the new assignment listed
- Student downloads assignment, prepares answer, and uploads submission
- Verify submission recorded in
tbl_assignment_marking with status N (New) - Tutor views pending submissions and marks the assignment (score 0–100)
- Tutor submits the marks (status changes to
T) - Admin reviews and verifies the marks
- Verify final score appears in student's performance view
|
Complete assignment lifecycle functions end-to-end. Assignment uploaded to MinIO/file storage. Student submission stored correctly. Tutor marking saved. Admin verification completes the flow. Score contributes to the student's assignment average for that subject. Status transitions: N → T (Tutor marked) → P (Published/verified). | | |
| E2E-ASG-02 | Late assignment submission (admin override) | Assignment deadline has passed; Admin has enabled late submissions in tbl_sys_settings |
- Verify assignment deadline has passed
- Student attempts to submit after deadline
- If late submission is disabled, verify rejection message
- Admin enables late submission in system settings
- Student re-attempts submission
- Verify submission accepted with late flag
- Tutor marks the late submission
|
Late submission behavior is controlled by system settings. When disabled, students see a clear deadline-passed message. When enabled by admin, late submissions are accepted and flagged. Tutor can see the late flag when marking. Score is recorded normally. | | |
| E2E-ASG-03 | Assignment rejection and resubmission | Student has submitted an assignment; Tutor logged in |
- Tutor reviews a student's assignment submission
- Tutor rejects the submission (status
R) with feedback comments - Student receives notification of rejection
- Student views rejection reason
- Student uploads a revised submission
- Tutor re-marks the resubmission
- Verify only the latest submission score is used
|
Rejection flow works correctly. Student notified of rejection with tutor feedback. Student can resubmit. New submission replaces or supplements the rejected one. Tutor can mark the resubmission. Status transitions: N → R (Rejected) → N (resubmitted) → T (marked). | | |
| E2E-ASG-04 | Monthly limit enforcement (max 3 per month per subject) | Student enrolled in a subject; system setting for monthly assignment limit is 3 |
- Tutor uploads 4 assignments for a subject within the same month
- Student submits assignments 1, 2, and 3 successfully
- Student attempts to submit assignment 4 in the same month
- Verify system enforces the monthly limit
- Wait for the next month (or adjust test date) and verify limit resets
|
System enforces the monthly assignment submission limit per subject per student. After reaching the limit (3), further submissions in the same calendar month are blocked with a clear message. Limit resets at the start of the next month. The limit value is configurable in system settings. | | |
| E2E-ASG-05 | Downloadable assignment report (marked/unmarked per tutor) | Multiple assignment submissions exist across subjects; Admin or Tutor logged in |
- Navigate to assignment reports
- Filter by tutor, subject, and date range
- Generate report showing marked vs. unmarked assignments
- Export report to Excel/PDF
- Verify counts match actual submission data
|
Report accurately shows the count of marked and unmarked assignments per tutor per subject. Export generates a valid Excel/PDF file. Data matches the underlying records in tbl_assignment_marking. Report helps identify tutors with marking backlogs. | | |
| ID | Description | Precondition | Steps | Expected Result | Actual Result | Status |
|---|
| E2E-EXM-01 | Full MCQ exam lifecycle: creation through results | Tutor assigned to subject; students enrolled; Admin account available |
- Tutor creates a new exam paper for their subject
- Tutor adds MCQ questions with options and correct answers
- Admin reviews and approves the exam paper
- Exam date is scheduled in
tbl_exam_dates - Students are notified of the upcoming exam
- During exam window, student logs in and starts the exam
- Student answers MCQ questions and submits
- System auto-grades MCQ answers
- Tutor reviews auto-graded results
- Admin provides final approval on results
- Student views their exam score and grade
|
Complete exam lifecycle works end-to-end. Paper created in tbl_exam_paper, questions in tbl_questions. Quiz records auto-generated for enrolled students. MCQ auto-grading calculates correct scores. Results flow through tutor review and admin approval. Student can view final results. All records consistent across tables. | | |
| E2E-EXM-02 | Downloadable exam flow (PDF-based) | Tutor logged in; subject has enrolled students; Admin account available |
- Tutor creates exam paper with
downloadable=true - Tutor uploads exam PDF to the paper
- Tutor sets a submission deadline
- Student logs in and downloads the exam PDF
- Student prepares answers offline
- Student uploads answer PDF before deadline
- Verify submission timestamp is before deadline
- Tutor downloads student's answer PDF and marks it
- Tutor enters the score
- Admin verifies the marks
- Student views the final score
|
Downloadable exam flow works completely. Exam PDF stored in MinIO/file storage. Students can download and re-download. Answer upload respects deadline (blocked after expiry). Tutor can access student answers for marking. Scores recorded and visible to student after admin verification. | | |
| E2E-EXM-03 | Failed exam retake (up to 3 retakes, then oral) | Student enrolled in subject with an exam; exam paper exists |
- Student takes exam and fails (score below pass mark)
- Student requests retake (attempt 2) and fails again
- Student takes retake (attempt 3) and fails again
- Student attempts a 4th retake
- Verify system blocks the 4th online attempt
- Verify student is directed to oral examination
- Tutor/Admin enters oral exam score manually
- Verify oral score contributes to final grade
|
Retake counter increments correctly (1 → 2 → 3). Each attempt creates a new tbl_student_quiz record. After 3 failed attempts, online exam access is blocked for that subject. System clearly communicates that oral exam is required. Oral score entry works and integrates into grading formula. Previous attempt scores are preserved for audit. | | |
| E2E-EXM-04 | Oral exam score entry | Student has been directed to oral exam (3 retakes exhausted or admin decision); Tutor/Admin logged in |
- Tutor navigates to oral exam score entry
- Selects the student and subject
- Enters oral assignment score (0–50)
- Enters oral exam score (0–100)
- Saves the oral scores
- Verify scores are stored in the system
- Verify the final grade recalculates incorporating oral scores
- Student views updated performance reflecting oral assessment
|
Oral scores are stored and clearly distinguished from online scores. Grade calculation incorporates oral scores using the configured weighting formula. Student's performance view shows the oral assessment results. Both oral assignment and oral exam scores are captured independently. | | |
| E2E-EXM-05 | Exam with late submission enabled | Downloadable exam exists with deadline passed; Admin can enable late submission |
- Verify exam submission deadline has passed
- Student attempts to upload answer after deadline — verify rejection
- Admin enables late submission for the exam/subject
- Student re-uploads answer after late submission is enabled
- Verify submission accepted with late flag
- Tutor marks the late submission
- Verify score is recorded and contributes to grade
|
Late submission control works for exams. Deadline enforcement is strict by default. Admin override enables late submissions. Late submissions are flagged in the system. Tutor can mark late submissions normally. Score contributes to grade calculation regardless of late flag. | | |
| ID | Description | Precondition | Steps | Expected Result | Actual Result | Status |
|---|
| E2E-GRD-01 | Full grading and certificate generation | Student has completed all subjects at a learning level (all assignments marked, exam taken and graded) |
- Verify all 10 assignments for each subject are marked
- Verify exam scores exist for each subject
- System calculates weighted grade per subject (assignment avg + exam score using configured weights from
tbl_sys_settings) - Verify grade tier assigned (A/B/C/D/E/F) per
tbl_grading_config - Admin confirms student has completed all required subjects for the level
- Admin triggers certificate generation
- System generates PDF certificate with student details, grades, and QR code
- Download and open the PDF certificate
- Scan QR code to verify it links to valid verification URL
|
Grade calculation uses configured weights accurately. All grade tiers map correctly to score ranges. Certificate PDF generates without errors. PDF contains: student name, admission number, learning level, list of subjects with grades, date of completion, Salvation Army branding. QR code is scannable and links to a verification endpoint that confirms certificate authenticity. | | |
| E2E-GRD-02 | Admin overrides final score | Student has a calculated final score for a subject; Admin logged in |
- Admin navigates to student performance management
- Admin selects a student and subject
- Admin views the system-calculated score
- Admin overrides the final score with a new value
- Admin provides justification/reason for the override
- Verify the overridden score is reflected in the student's record
- Verify audit trail captures the override (who, when, old value, new value)
|
Admin can override final scores. Override is recorded in tbl_student_subjects_selection (total_max_awarded). Audit trail in Auditable fields captures lastModifiedBy and lastModifiedDate. Student sees the updated score. Grade tier recalculates based on the overridden score. | | |
| E2E-GRD-03 | Transcript generation with all subjects and grades | Student has completed multiple subjects across one or more learning levels |
- Admin or student requests a transcript
- System queries all completed subjects and grades for the student
- PDF transcript is generated listing every subject, score, grade, and completion date
- Download and verify the transcript
- Verify it includes student details (name, admission number, territory)
- Verify all subjects and grades are present and accurate
|
Transcript PDF generates successfully. Contains all completed subjects organized by learning level. Each entry shows subject code, subject name, final score, grade tier, and completion date. Student details are accurate. PDF formatted with Salvation Army branding. Totals and GPA/average displayed if applicable. | | |
| E2E-GRD-04 | QR code verification on certificate | Certificate PDF has been generated for a student |
- Open the generated certificate PDF
- Locate the QR code on the certificate
- Scan the QR code with a mobile device or QR scanner
- Verify the URL resolves to a verification page
- Verify the verification page displays correct student and certificate details
- Try modifying the URL parameters to test for tampering detection
|
QR code encodes a verification URL with a unique certificate identifier. Scanning opens a web page confirming: student name, admission number, learning level, date of issuance, and certificate validity. Modified/tampered URLs return an invalid certificate response. QR code is generated using ZXing library and is clear/scannable. | | |
