Name:Charles Mwangi

Reg:P100/2177G/22

ODEL / E-LEARNING SYSTEM TEST PLAN

1. OBJECTIVES

 Verify functional requirements for each module (positive / negative / edge cases).

 Ensure correctness of integrations (authentication → enrollment → content access →

notifications).

 Validate non-functional requirements: performance, scalability, reliability, security,

accessibility (WCAG 2.1 AA) and cross-browser/device compatibility.

 Provide automated regression coverage for core flows and create a repeatable CI
pipeline for tests.

 Achieve stakeholder sign-off via UAT with measurable acceptance criteria.

2. TEST SCOPE

2.1 In-scope

Module 1 — Registration & Enrollment

 Sign up / login flows (email, SSO if present).

 Password reset, 2FA (if implemented).

 Profile fields validation (name, ID, email, program).

 Course search, filters, prerequisite checks, course add/drop, waitlist behavior.

 Notifications on enrollment success/failure.

Module 2 — Content Delivery

 Video streaming (play, pause, resume, seek).

 Transcoding / adaptive bitrate fallback.

 File downloads (PDF, PPT), inline viewer.

 Quiz delivery (timed, randomization), auto-grading, manual grading for essay

answers.
Module 3 — Communication

 Direct messages, group threads, thread moderation.

 Announcements (created by lecturer, delivered to enrolled students).

 File attachments in messages (size/type limits), content moderation.

 Push / email notification flows (subscribe/unsubscribe).

3. TEST STRATEGY & APPROACH

3.1 Testing Levels & Responsibility

 Unit Tests — Developers (component and business logic).

 Integration Tests — Developers + QA (APIs, DB, auth, third-party mocks).

 System Tests — QA (functional, compatibility, regression).

 Performance & Security Tests — Performance/security engineers with QA support.

 Acceptance (UAT) — Real students/lecturers and product owners.

3.2 Types of Testing

 Functional / Positive & Negative: e.g., enrollment when prerequisites not met
(negative).

 Boundary & Edge Cases: e.g., zero-length files, maximum upload size, longest
username strings.

 Compatibility: Desktop browsers (Chrome/LTS, Firefox, Edge, Safari), iOS Safari,

Android Chrome.

 Responsiveness: Layout checks across breakpoints.

 Performance: Page load times, concurrency, video startup time, DB query latency.

 Security: OWASP Top-10 checks (auth bypass, XSS, SQLi), session management.

 Accessibility: Keyboard navigation, screen reader text, color contrast.

 Localization: If multi-language support exists (format/date/time).

 Recovery & Reliability: DB failover, interrupted uploads, partial writes.

 Regression: Focused on core flows — login, enrollment, content access, quizzes.

4. TEST ENVIRONMENTS

4.1 Environment Matrix

 Dev: Unit tests + developer integration.

 QA / Staging: Mirrors production: same middleware, DB schema, CDN config. Used

for system tests, security scans, performance testing (scaled down).

 Pre-prod: Full production-like load tests, final UAT.

 Prod (read-only for smoke checks): Post-release sanity tests.

4.2 Server & Network Configurations

 Web servers: [Link] / Nginx (versions).

 App servers: 2 replicas in staging; scale rules configurable.

 DB: PostgreSQL/MySQL, replica read nodes.

 CDN: for video and static assets; test behavior when CDN returns 304 / 500.

 Storage: S3 compatible for media; simulate object storage latency.

 Network: Simulate 3G, 4G, 100ms/200ms latency for video/responsive testing.

4.3 Device / Browser Matrix

 Desktop: Windows 10/11 (Chrome 120+, Edge latest), macOS (Safari 16+, Chrome).

 Mobile: iOS 17 (Safari), Android 14 (Chrome).

 Tablets: iPadOS Safari.

 Screen readers: NVDA, VoiceOver.

5. TEST DATA

User accounts: studentA (fresh), studentB (already enrolled), lecturerX.

 Courses: course_free.pdf, course_paid (if future), course_with_prereq.

 Quizzes: MCQ pool, essay questions, timed quiz templates.

 Media: short/large videos (e.g., 2MB, 200MB), PDF notes, corrupted file.

 Edge data: very long text inputs, invalid emails, unsupported file types.

 Use a test data seeding script to populate DB with deterministic records and varying
permission sets.
6. DETAILED ENTRY / EXIT CRITERIA

Entry (for System Testing)

 Unit tests pass > 95% (or agreed threshold).

 Integration tests executed and blocked defects resolved or triaged.

 Staging environment provisioned and seeded.

 Smoke tests pass (basic login, home page, course list, play a video).

Exit (from System Testing)

 All P0/P1 defects fixed and verified.

 ≥ 95% critical functional test cases passed.

 Performance targets met (see Section 8).

 Accessibility checklist (critical items) passed.

 Regression suite executed with acceptable pass rate.

7. TEST CASES — SAMPLES

Test case template: ID | Title | Module | Pre-req | Test steps | Test data | Expected result |
Priority | Status

Module 1 — Course Registration (example)

 TC_REG_001 | Sign up valid user | Registration | none

Steps: 1) Open sign up page 2) Enter valid details 3) Submit 4) Verify confirmation
email link 5) Login.
Expected: Account created, verification email sent, login successful. Priority: P0.

 TC_REG_002 | Sign up with existing email (negative)

Expected: Error message “Email already registered”, account not created. Priority: P1.

Module 2 — Content Delivery (video)

 TC_CONT_010 | Play video on 3G network | Content | Student enrolled in course

Steps: 1) Login; 2) Navigate to video lecture; 3) Play video with network throttling 3G;
4) Seek to mid-point.
Expected: Video plays with adaptive bitrate change; no crash; seek positions
retained. Priority: P0.
Module 2 — Quizzes

 TC_QUIZ_001 | Timed quiz auto-submit | Quiz | Student enrolled

Steps: Start timed quiz; wait until timer expires.
Expected: Quiz auto-submits; grade is calculated; submission timestamp recorded.
Priority: P0.

Module 3 — Communication

 TC_COMM_001 | Lecturer posts announcement | Communication | Lecturer

account
Steps: Lecturer posts announcement → verify enrolled students receive notification
(email/in-app).
Expected: Announcement visible in course, notifications delivered. Priority: P0.

8. PERFORMANCE TESTING

Objectives & KPIs

 Concurrent users target: e.g., nominal 5,000 active users, peak 20,000 (adjust to
institution size).

 Acceptable page load time: < 3s for dashboard under nominal load.

 Video Startup: < 5s to first frame on 4G.

 95th percentile API response: < 1s for critical endpoints (login, enrollment).

 Error rate: < 1% under nominal load.

Scenarios

1. Login Storm: 2,000 logins/minute for 10 minutes. Measure auth latency and DB CPU.

2. Concurrent Playback: 1,000 users start video within 1 minute — observe CDN and
origin server load.

3. Quiz Submission Peak: 5,000 students submit quizzes within a 10-minute window.

4. Mixed Workflow: 50% browsing, 30% playback, 20% messaging — run 1 hour.

Tools & Scripts

 JMeter / Locust for load tests; use distributed workers and monitor DB, app server,
network bandwidth.

 Capture metrics: CPU, memory, thread pools, DB latency, network I/O, error rates.

Bottleneck Remediation
9. SECURITY TESTING CHECKLIST

 Authentication & session management (session expiry, secure cookies).

 Authorization checks (role enforcement — student vs lecturer).

 OWASP Top 10 tests: Injection, Broken Auth, Sensitive Data Exposure, XXE, XSS, CSRF,
Insecure Direct Object References (IDOR), Security Misconfiguration.

 File upload checks: type/size validation, virus scan, path traversal prevention.

 Rate limiting / brute force protection.

 Password policy strength.

 Penetration test for critical flows prior to production release.

10. ACCESSIBILITY (WCAG 2.1 AA) CHECKPOINTS

 Semantic HTML for screen readers.

 All features operable via keyboard (tab order).

 Proper alt text for images; captions for videos and transcripts for audio.

 Color contrast ratio >= 4.5:1 (text) / 3:1 (large text).

 Form labels & ARIA attributes where needed.

 Automated tools (axe, Lighthouse) + manual keyboard/screen reader checks.

11. AUTOMATION STRATEGY

11.1 Goals

 Automate smoke and regression suites for key flows: login, enrollment, content
access, quiz submission, messaging.

 Integrate with CI (GitHub Actions / Jenkins) to run smoke suite on each deployment
and full regression nightly.

11.2 Tools & Frameworks

 Frontend E2E: Cypress (recommended) or Selenium WebDriver + Playwright for cross-browser.

 API Tests: Postman / Newman or pytest + requests.

 Performance: JMeter / Locust.

 Reporting: Allure / HTML Reports.

 CI: GitHub Actions / Jenkins pipelines to trigger test runs and publish reports.
11.3 Example automation test (pseudo)

 Test: Verify enrollment grants content access.

Steps (automated): Create test user via API → enroll user via API → request course
content via UI or API → assert HTTP 200 and content metadata.
Use mocks for external services (email provider, CDN) or run against staging mail
catcher.

11.4 Test Suite Structure

 Smoke: 15–20 fastest, highest-value tests (run on every deploy).

 Regression: 200+ tests covering all critical features (nightly).

 Integration: API contract checks on PRs.

12. DEFECT MANAGEMENT & LIFECYCLE

12.1 Severity / Priority definitions

 Severity P0 (Critical): System down, data loss, security breach.

 P1 (High): Core functionality broken (enrollment, content access, quiz grading).

 P2 (Medium): Important but workaround exists (UI misalignment, minor validation).

 P3 (Low): Cosmetic or enhancement requests.

12.2 Workflow (JIRA)

 New → Open → In Progress → Code Review → QA Verify → Done/Closed.

 Reopen if regression occurs. Attach logs, steps, screenshots, network traces.

12.3 Reporting cadence

 Daily build health mail (smoke pass rate).

 Weekly QA dashboard: executed tests, pass/fail, open defects by severity, MTTR.

13. TRACEABILITY MATRIX (sample)

Requirement ID Description Test Case IDs

REQ-R1 User can enroll in course TC_REG_001, TC_REG_005

REQ-C2 Video must stream with adaptive bitrate TC_CONT_010, PERF_VID_001

REQ-M3 Lecturer announcement to enrolled users TC_COMM_001, TC_COMM_002

Maintain this matrix in TestRail/JIRA to ensure requirement coverage.

14. SMOKE TEST CHECKLIST (quick)

 Login (student & lecturer).

 Brief course search and view course details.

 Play a short lecture video.

 Submit a 1-question quiz.

 Send and receive a message between lecturer and student.

 View progress dashboard.

15. UAT (Acceptance) DETAILS

 Prepare UAT scenarios mapped to real academic tasks (register for semester, access
week-1 materials, submit quiz, interact on forum).

 UAT script + feedback form capturing usability, bugs, enhancement suggestions.

 Acceptance criteria must be SMART (e.g., “Enrollment success rate in UAT ≥ 98%”,
“No P0/P1 bugs at sign-off”).

16. TEST SCHEDULE — Milestones (granular)

 Sprint 0 (Week 0): Test plan sign-off, environment provisioning.

 Sprint 1 (Week 1): Unit + component tests done. Smoke tests automated.

 Sprint 2 (Week 2–3): Integration testing; API contract testing.

 Sprint 3 (Week 4): System functional testing + regression.

 Sprint 4 (Week 5): Performance & Security testing.

 Sprint 5 (Week 6): UAT (1 week).

 Sprint 6 (Week 7): Regression run + bug fixes.

 Sprint 7 (Week 8): Release readiness, production smoke.

17. RISKS & MITIGATION

Risk Impact Likelihood Mitigation

Video CDN Pre-prod CDN smoke; cache headers checks;

High Medium
misconfiguration fallback player.

DB slow queries during Query profiling; add indexes; read replica

High Medium
peak scaling.

Late requirement Freeze window before UAT; triage change

Medium High
changes requests.

Build automated seeding scripts and

Insufficient test data Medium High
anonymized production clones.

18. TEST REPORTING & DELIVERABLES

Deliverables

 Approved Test Plan (this document).

 Test cases & execution logs (TestRail/JIRA).

 Automated test scripts (repo).

 Performance & security test reports (graphs + findings).

 UAT feedback forms and sign-off.

 Final Test Summary & Test Closure Report.

Test Closure Report contents

 Executive summary & scope.

 Test metrics: total cases, pass/fail, blocked.

 Defect summary: P0–P3 counts, open vs closed.

 Coverage: requirements mapped to test cases.

 Lessons learned & recommendations.

 Final sign-off and release recommendation.

19. ASSUMPTIONS & CONSTRAINTS

 Staging environment will be production-like in capacity.

 Development will fix P0/P1 defects within agreed SLAs.

 Third-party integrations can be mocked if unavailable.

 Time & resource estimates assume 2 QA testers + 1 performance/security engineer.