Master the 8 sub-systems (Admin, Profiles, Courses, Enrollment, Grades/Attendance, Financial, Portal, Specialized Programs) with comprehensive testing strategies covering 89 features, 32+ business rules, and real-world scenario testing.
Chapters historically relied on spreadsheets and manual processes to manage education and training. This approach was error-prone, lacked accountability, and provided no member/student visibility into schedules, grades, or payments. The Education module formalizes the entire lifecycle: from curriculum design (modules, courses, crafts, levels) through registration, attendance tracking, grading, and payment collection.
What It Does: Chapter staff define work processes (OJT requirements) and modules (classroom curriculum), organize them by craft and level, create courses with schedules and instructors, enroll students, track attendance and grades, manage payments (student/company split), and issue invoices. Students and companies use the portal to register, view courses, submit OJT hours, and pay invoices.
Business Value: (1) Professional delivery—standardized curriculum and transparent grading; (2) Student/Company engagement—self-service portal increases participation; (3) Financial control—split payments and payment plans; (4) Data-driven decisions—reporting on attendance, completion, OJT progress; (5) Regulatory compliance—audit trails and historical records for state/program requirements.
The Education module is organized into 8 interdependent sub-systems. Each supports specific operational functions and links to others:
School years, semesters, lookup tables, module CRUD, work process CRUD, craft definitions, location management, document requests. Foundation for all other systems.
Instructor and student profiles with specializations, portal access, craft enrollments, company associations. Enables access control and student/instructor relationships.
Course CRUD, module assignment, class schedule generation, course copying. Central hub for defining what and when students learn.
Add/browse/transfer/withdraw enrollments, level promotions, split utilities. Manages who takes what course and when.
Session-based attendance recording, assignment/grade entry, performance evaluations. Tracks academic progress per student per course.
Course pricing, payment responsibility (student/company/split), payment plans, invoicing, payment tracking. Revenue and collections management.
Student/instructor/company portals: course catalog, registration, attendance snapshots, OJT submission, payment. Member-facing self-service.
OJT tracking, correspondence training, company-led training, mass communications, reporting (Metabase). Advanced features for specialized delivery modes.
Chapter Staff (3 Levels): L1 (View Only) — browse, export, no changes. L2 (Edit) — modify modules, courses, enrollments, grades; cannot change permissions/settings. L3 (Admin) — full CRUD, all settings, mass communications, document requests.
Instructors: View assigned courses, record attendance/grades, performance evals. Cannot cancel classes or see financials. Portal access optional (chapter-controlled).
Students: Portal access. Browse courses, register (if enabled), view own courses, submit OJT hours monthly, pay invoices, download documents. Cannot see other students' data.
Companies: Portal access. View associated students' courses/OJT/training, verify OJT submissions, pay company-responsible invoices, download documents.
Understand the end-to-end journey: An instructor teaches a course, students enroll, they attend classes, instructors record grades, students may work OJT with their companies, systems generate invoices, students/companies pay via portal. Every sub-system must work in concert. Test holistically, not in isolation.
School Year & Semester Management: Chapters define a school year (e.g., FY2026 Jan-Dec). Within it, semesters can be created/enabled/disabled. Cannot delete school years with active courses. Selector on all browse screens drives context for courses, enrollments, etc.
Module Management: Module ID + Name (unique), Hours (decimal), Level (Core/1-5), NCCER Edition tracking, Craft Association, Status. Bulk creation and edit supported. Cannot delete if assigned to active courses.
Work Process (OJT) Management: Work Process ID + Name (unique), Required Hours (whole numbers), Craft Association, Status. Tracks on-the-job training requirements per craft. Cannot reduce hours below max recorded student hours.
Craft Management: Craft Name, Description, Number of Levels, Status. Assign modules and work processes. Cannot delete if students enrolled. Serves as organizational spine for entire module.
Location Management: 3 types (Physical, Company, Virtual), each with different fields. Used for class scheduling and address resolution. Cannot delete/inactivate if active courses assigned.
Lookup Tables & Chapter Defaults: Attendance Types (e.g., Present, Absent, Makeup), Student Types, Level Notes, Assignment Types. Customizable per chapter.
Instructor Profiles: Link to existing Individual, add Craft Specializations, enable/disable Portal Access (chapter controls via invite/remove), Status (Active/Inactive). Inactive instructors cannot be assigned to new courses. Section-based editing (main, courses, notes tabs). Change history tracked.
Student Profiles: Link to Individual (auto-create or link existing), Company Association (single primary + optionals), Craft Enrollment (per craft: Level, OJT flag, Correspondence flag, Company-Led flag + Lead Company). Portal Access managed by chapter. Status (Active/Inactive). All changes logged with user and timestamp.
Company Association Rules: A student has ONE primary company (for OJT verification routing, invoicing) and can have optional associations. Changing primary company routes ALL OJT submissions (past and future) to new company.
Course Creation (4-Section Wizard): (1) Course Info—Name (unique per school year), Description, Craft/Level, School Year, Semester, Capacity. (2) Location & Instructors—select location (Physical/Company/Virtual) with address or company fields, assign instructors. (3) Capacity & Registration—Capacity (warn but allow over-enrollment), Registration open/close dates, auto-decline if over. (4) Pricing & Payment—Member/Non-Member tuition, Payment Policy (Pay During Registration vs Pay By Date), Late Fees.
Module Assignment: Two-pane interface: available modules (left) vs assigned modules (right). Drag to add/remove, reorder by drag. Shows Module ID, Name, Hours, Level per module.
Class Schedule Generation: Specify date range or class count, system generates class sessions. Support for holidays/breaks (blackout dates). Editable grid shows Class#, Date, Start/End Time, Hours, Assigned Module. Manually adjustable.
Course Copying: Single or bulk utility. Options: copy modules (always), copy schedule (optional), copy instructors (optional). Copy rules ensure clean inheritance.
Add Enrollment (Bulk): Select course, select students, set payment responsibility (Student/Company/Split % or $), select payment plan if applicable, confirm. Post-save: system generates invoices, sends confirmation emails to student/company if payer.
Browse Enrollments: Filter by course, student, status, school year. Columns: Student, Course, Enrollment Date, Status, Attendance %, Grade, Payment Status. Quick actions: view, transfer, withdraw.
Transfer Enrollment: Select target course, effective date, attendance handling (copy forward, reset, or manual). Validates capacity, resolves pricing. Posts new invoice if pricing differs.
Level Promotion (Bulk): Select craft, current level, target level. Process in reverse order (4→5 first, then 3→4, etc). Validates candidates, updates Craft Enrollment Status. If promoting to max level, set Status to Graduated/Completed.
Attendance Recording: Session-based (per class date). Select session, record Present/Absent/Makeup for each student. Makeup resets Hours Absent to zero. History view shows all attendance entries and edits. Summary shows total hours present, absent, percentage.
Grade Entry: Create assignments (by module/date), enter grades per student (percentage 0-100 or Pass/Fail). Optional retake handling. Multiple grade entries per student allowed. Summary shows current grade, all assignment grades, retake results.
Performance Evaluations: Module-based pass/fail evaluations. Select module, select session, record Pass/Fail per student. History and module summary tracked.
Payment Responsibility: Three models: (1) Student Pays—full amount to student invoice. (2) Company Pays—full amount to company invoice. (3) Split—percentage, dollar amount, or fee-specific split. Resolves at enrollment and stored with enrollment for downstream invoicing.
Payment Plans: Installment schedule, auto-draft option, first payment requirement. Applies ONLY to student portion; company pays in full or per its split. Monthly installments generate separate invoices.
Invoice Generation: Triggers on enrollment (immediately or by payment policy date). Split invoices: separate student and company invoices from same enrollment. Payment plan invoices: one per installment. Includes due date, payment instructions, course details.
Payment Tracking: Browse invoices, filter by status (open, past due, paid). Mark paid manually or via gateway. Send unpaid reminders. Past-due balance blocks new registrations.
Student Portal: Course Catalog (browse open courses, filters, pricing resolution—member vs non-member based on auth). Register Now (capacity check, pricing display, payment options: Pay Now / Add to Cart / Request Invoice). My Courses (current/past toggle). View Course (read-only, shows schedule, modules, attendance/grade summaries). Invoices (open/history, installment invoices, company-responsible portions hidden). OJT Submission (monthly, per work process, save draft or submit, company verification). Documents (download/upload requests).
Instructor Portal: My Courses (assigned courses only). View Course (read-only, no finance). Student Profile Snapshot (constrained read-only, no PII beyond name/company).
Company Portal: My Students (with course snapshot, attendance, grade, financial responsibility). View Student (read-only, courses, OJT, training, company-responsible balance only). OJT Verification (approve/adjust/reject monthly submissions). Invoices (company portion only). Documents (download/upload).
OJT (On-The-Job Training): Flag students per craft (requires active company association). Browse participants, record monthly submissions (hours per work process, company verifies). Approval, rejection, or adjustment with comments. Student portal: monthly submission interface, approval history. Company portal: verification interface.
Correspondence Training: Flag students per craft. Browse participants, record module completions (edition, hours, completion date, grade). View progress per craft/level, export. Self-paced curriculum tracking.
Company-Led Training: Flag students per craft + select Lead Company. Browse, record completions, view progress. Company delivers training outside classroom.
Mass Communications: L3-only. Target by course, craft, location, session date. Compose email/text with auto-context injection. Send with confirmation modal. Log all communications for audit.
Reporting (Metabase): Curated reports: attendance, grades, OJT progress, enrollment/capacity, company summaries. Export-capable. Ongoing expansion of reports as needs emerge.
Map your test cases to these 8 sub-systems. Understand dependencies: Admin Setup enables Profiles, which enable Enrollment, which drives Financials and Portal. Test workflows end-to-end across sub-systems. Verify data flows correctly (e.g., enrollment creates invoice with correct payment responsibility, student pays via portal).
School Year: Academic calendar period (e.g., FY2026 Jan-Dec). Context for all courses and enrollments. Selector drives browse screen results.
Semester: Subdivision of school year (Spring, Fall, etc.). Courses assigned to semesters. Can be enabled/disabled per chapter preference.
Craft: Trade classification (e.g., HVAC, Electrical, Plumbing). Chapters organize modules, work processes, and students by craft. Each craft supports 1-6 levels.
Level: Progression tier within craft (Core, Level 1, Level 2, etc.). Modules and courses assigned to levels. Determines prerequisite structure.
Module: Curriculum unit (e.g., "Safety Fundamentals," "Wiring Practices"). Has ID, Name, Hours, Level, Craft association, NCCER edition. Assigned to courses. Used in correspondence training. Multiple versions track NCCER updates.
Work Process: On-the-job training requirement. Has ID, Name, Required Hours, Craft association. Students log monthly hours against work processes. Company verifies submissions.
Course: Class offering. Has Name (unique per school year), Description, Craft/Level, Capacity, Location, Instructors, Schedule, Modules, Pricing, Payment Policy. Students enroll; instructors teach.
Location: Physical, Company, or Virtual venue. Used for scheduling and student logistics. Physical/Company have address fields; Virtual has link.
Student Pays: 100% to student invoice. Company portion = $0.
Company Pays: 100% to company invoice. Student portion = $0.
Split Payment: Percentage-based, dollar-amount-based, or fee-specific split. Student pays their portion; company pays theirs. Separate invoices issued.
Pay During Registration: Student must pay (or arrange payment) immediately upon enrollment to complete registration.
Pay By Date: Invoice generated with future due date. Student has grace period to pay (customizable reminders).
Payment Plan: Installment schedule for student balance only (company cannot use plans). E.g., 3 monthly installments of $500 each. Auto-draft option available. First payment may be required upfront.
Invoice: Bill issued to student or company for course fees. Generated immediately (Pay During) or by due date (Pay By Date). Split invoices issued separately. Payment plan invoices issued per installment.
Attendance Type: Present, Absent, Makeup (custom per chapter). Recorded per class session. Makeup resets Hours Absent. Tracked hours (present, absent) and percentages.
OJT: Work-based learning. Student logs monthly hours by work process (per craft). Company verifies (approve, adjust, reject). Required active company association. State/program-mandated in some jurisdictions.
Correspondence Training: Self-paced, non-classroom curriculum (e.g., online modules, textbook study). Chapter staff flag students per craft, record module completions with grades and hours. Tracked per craft/level.
Company-Led Training: Training delivered by the student's employer. Chapter staff flag students per craft, select Lead Company, record completions. Company trains; chapter tracks.
L1 (View Only): Browse, filter, export. No create/edit/delete. Read-only access to all data.
L2 (Edit): Modify modules, courses, enrollments, grades. Cannot change settings or permissions.
L3 (Admin): Full CRUD. Change all settings, permissions, mass communications, document requests. Chapter owner/director typical role.
Portal Access: Enables instructor/student/company to log into member portal and access education screens (My Courses, Register, OJT, etc.). Chapter staff manage via invite/remove.
Use this glossary as a reference during testing and bug reporting. Precise terminology prevents miscommunication. E.g., "Module" ≠ "Course" (module is curriculum unit; course is offering). "Payment Responsibility" ≠ "Payment Policy" (responsibility = who pays; policy = when payment due).
End-to-End Workflows First: Test complete journeys before isolated features. Example: "Admin setup school year → define craft → create module → add course → enroll student → record attendance → generate invoice → student pays via portal." This validates sub-system integration.
Sub-System Coverage: Allocate testing effort to all 8 sub-systems proportionally. Admin Setup (15%), Profiles (10%), Courses (15%), Enrollment (15%), Attendance/Grades (10%), Financial (15%), Portal (10%), Specialized (10%).
User Persona Testing: Test as each role: Chapter L1/L2/L3, Instructor, Student, Company. Each has different data visibility and action rights. Verify access control is correct.
Data Integrity Focus: Validate calculations (fees, splits, totals), state consistency (e.g., enrollment status, payment status), and audit trails (change history is complete and accurate).
Business Rule Validation: Cross-reference all 32+ business rules (see Business Rules & Gotchas section). Every rule must be tested in context (e.g., "Cannot delete course with active enrollments").
Prerequisite Configurations: School year (FY2026), 2-3 semesters enabled, location (Physical, Company, Virtual) created, chapter settings configured (portal enabled, payment responsibility selection enabled/disabled per test scenario).
Core Master Data: 3-5 Crafts (HVAC, Electrical, Plumbing, etc.), 15-20 Modules per craft (span Core/1-5 levels), 3-5 Work Processes per craft, 3 Locations (1 Physical, 1 Company, 1 Virtual).
Personnel: 5-10 Instructors (assign to 2+ crafts), 20-30 Students (span crafts, some with company association, some without), 5 Companies (varied dues levels, active/inactive).
Courses: Create 8-10 courses (2-3 per school year/craft/semester combination). Vary: location type (physical/company/virtual), capacity (small/medium/large/at-capacity), pricing (member/non-member), payment policy (Pay During/By Date).
Test User Accounts: Chapter staff (L1, L2, L3), Instructor, Student, Company users. Ensure email addresses are valid (for testing automated emails).
Functional Testing: Per sub-system CRUD operations (Create, Read, Update, Delete). E.g., for Courses: Add course (all 4 sections), view course details, edit course info/instructors/schedule, copy course, delete course. Verify all fields display/save correctly.
Integration Testing: Cross-sub-system workflows. E.g., Enrollment flow: (1) Create course with modules/schedule/pricing (Courses subsystem), (2) Enroll student (Enrollment subsystem), (3) Verify invoice generated (Financial subsystem), (4) Verify student can view course in portal (Portal subsystem).
Business Rule Testing: Validate each rule (see Business Rules section). E.g., "Cannot reduce work process hours below max recorded student hours"—create a student with recorded OJT hours, attempt to reduce work process hours, expect error or warning.
Regression Testing: Use checklists per sub-system (Regression Checklists section) before each release. Spot-check critical paths to catch unintended side effects.
Permission/Access Control Testing: Verify L1/L2/L3 visibility and action rights. Confirm inactive instructors/students cannot be assigned. Verify data isolation (student A cannot see student B's data).
Email & Notification Testing: Verify automated emails are sent on enrollment, payment, OJT status changes. Check email content (course name, due date, payment amount, OJT status) is correct. Verify email log is maintained.
Phase 1 (Admin Setup): School year, semesters, lookup tables, craft/level definitions, module CRUD, work process CRUD. Duration: 2-3 days. Critical foundation; blocks downstream testing.
Phase 2 (Profiles & Config): Instructor/student add/edit, company association, craft enrollment, location management. Duration: 2-3 days. Enables course creation and enrollment.
Phase 3 (Courses): Course CRUD (all 4 sections), module assignment, schedule generation, copy course. Duration: 2-3 days. Prerequisite for enrollment testing.
Phase 4 (Enrollment & Academic): Add/browse/transfer/withdraw enrollment, attendance, grades, performance, level promotion. Duration: 3-4 days. Core student lifecycle.
Phase 5 (Financial): Pricing, payment responsibility, payment plans, invoicing, payment tracking. Duration: 2-3 days. Revenue-critical; test thoroughly.
Phase 6 (Portal): Student registration, My Courses, OJT submission, Instructor My Courses, Company My Students, payment. Duration: 3-4 days. Member-facing; high visibility.
Phase 7 (Specialized): OJT verification, correspondence training, company-led training, mass communications. Duration: 2-3 days. Advanced features; often last to stabilize.
Phase 8 (Integration & Regression): Run scenario tests and full regression checklists. Duration: 3-5 days. Pre-release validation.
This is a complex module with high financial and operational impact. Invest in thorough testing. Test as chapter staff would—school year setup first, then profiles, then courses, then enrollments. Test as members would—browse catalog, register, pay, check portal. Verify invoices are correct (frequent payment dispute source). Test edge cases (capacity overages, payment plan math, split payments).
Create a test case for EACH rule. Use rule ID (e.g., "Rule 6: Work Process Hours Immutability") in your test case naming. If a bug is found, reference the rule in the Jira ticket ("Violates Rule 6"). This cross-linking helps prioritize critical vs minor issues. Some gotchas are easy to miss (e.g., "Changing company routes ALL OJT submissions to new company")—test these explicitly.
Setup: Course is running (Week 3 of 12). Student enrolls late. Payment responsibility = Student Pays. Payment plan = 3 monthly installments.
Actions: (1) Enroll student → system generates payment plan invoices (3 months, adjusted prorata for partial month?). (2) Instructor records attendance for past sessions—does system retroactively mark student absent or skip past sessions? (3) Student receives first invoice, pays via portal. (4) One month later, second installment due—verify reminder email sent. (5) Student completes course, final invoice issued (if any balance).
Validations: Invoice amounts are correct (prorata logic if applicable). Payment plan dates are correct. Attendance percentage calculated correctly (present weeks vs total weeks, excluding sessions before enrollment?). Email reminders sent on schedule. Grade/completion visible in portal after course ends.
Setup: Course enrolled. Payment responsibility = 60% Student, 40% Company. Company = ABC Plumbing. Student has active association with ABC Plumbing and XYZ Electrical.
Actions: (1) Enroll student → split invoices generated ($600 student, $400 company). (2) Student pays their portion via portal. (3) Midway through course, student changes primary company from ABC Plumbing to XYZ Electrical. (4) What happens to the existing $400 company invoice? Does it route to XYZ? Or stay with ABC?
Validations: Understand the business rule: does company change affect outstanding invoices (no, they're already issued) or only future invoices? Test the actual implementation. Verify company portal shows correct invoices (ABC sees their $400 from old enrollment, XYZ sees invoices for new enrollments).
Setup: Student flagged for OJT. Primary company = ABC Plumbing. Student has submitted January and February OJT hours. January approved, February pending company review. March submission due.
Actions: (1) Student changes primary company from ABC to XYZ Electrical. (2) What routing happens to February (pending) submission? January (already approved)? (3) Where does March submission route?
Validations: Business rule states: ALL OJT submissions (past and future, verified and pending) route to NEW company. Test that February routing changes to XYZ. Verify XYZ sees February pending. Verify January history is preserved but no longer actionable (already approved). Verify March routes to XYZ from submission.
Setup: Course capacity = 20. Currently 20 students enrolled. New student attempts to enroll via portal (if enabled) or chapter staff manually enrolls.
Actions: (1) Attempt enrollment when at capacity. (2) System shows what? Warning? Error? Confirmation dialog? (3) If allowed (business rule says warn but allow), enrollment completes, course now has 21 students. (4) In portal, does "Register Now" become "Waitlist" or still allow direct enrollment?
Validations: Understand the implementation: does system have waitlist functionality or just warn? If warning, does it clearly state capacity will be exceeded? If portal enrollment is auto-decline when full, test that. If allow, test invoice is still generated and student enrolled.
Setup: Course "Electrical Fundamentals" has modules: Safety, Wiring, Circuits. Course is active (students enrolled, classes scheduled).
Actions: (1) Chapter staff attempts to delete module "Wiring" from system. System should detect "Wiring" is assigned to active course and block delete.
Validations: Verify delete is blocked with error message naming the course(s) that reference the module. Verify module remains in course and can still be taught. Verify no orphaned module references.
Setup: Course tuition = $1,000. Student enrolls with 3-month payment plan. Enrollment date = March 15 (mid-month).
Actions: (1) System generates payment plan invoices. (2) Are installments equal ($333.33 each) or prorated for partial month? (3) Do rounding differences accumulate (e.g., first two months $333.33, third month $333.34)?
Validations: Understand business requirement for partial month handling. Test with multiple scenarios: (a) enrollment mid-month, (b) enrollment on 1st of month, (c) enrollment on last day of month. Verify total of all installments = total tuition (within penny). Verify no negative amounts.
Setup: Craft "HVAC" has courses and students enrolled.
Actions: (1) Chapter staff attempts to delete craft "HVAC". (2) System should block deletion due to active student enrollments in HVAC courses.
Validations: Verify delete is blocked with error naming the courses/students. Option to inactivate craft instead (read-only, no new enrollments). Verify data integrity—no orphaned craft references.
Setup: Student portal registration enabled. Course pricing = $900, payment policy = Pay During Registration. Student selects payment plan (3 months, $300/month).
Actions: (1) Student completes registration with payment plan. (2) First invoice issued immediately (due now). (3) Email confirmation sent. (4) 30 days later, second invoice due. Verify reminder email sent N days before (configurable, e.g., 5 days). (5) Student pays via portal. (6) 60 days from enrollment, third invoice due. (7) Verify email sequence and amounts.
Validations: Email timing is correct (not early, not late). Email content includes course name, due date, amount, payment link. Portal shows all 3 invoices in correct state (paid, past due, future). Late fees applied if payment overdue.
These scenarios represent real situations chapter staff and members will encounter. Use them to design integration test cases that exercise multiple sub-systems. If a scenario reveals a gap in understanding (e.g., "What happens if..."?), ask the product team to clarify before testing. Document clarifications so future QA understands the rules.
Before every release, run through these checklists systematically. Allocate 1-2 hours per sub-system. Check off items as you test them. If an item fails, open a bug immediately and note the failure in the checklist for reporting. These checklists are your "safety net"—they catch unintended side effects and prevent regressions.
School Years & Semesters: Create 2-3 school years (FY2025, FY2026, FY2027). For each, create 2-3 semesters (Spring, Fall) in both enabled and disabled states for testing filtering/defaults.
Crafts (3-5): Create: HVAC, Electrical, Plumbing, Carpentry, Masonry. Each with 3-6 levels (Core/1-5). Span different level structures to test flexibility.
Modules (15-20 per craft): Create diverse modules: "Safety Fundamentals" (Core), "Basic Wiring" (Levels 1-2), "Advanced Circuits" (Level 3-5). Include varied hours (decimal and whole), NCCER editions, status (active/inactive).
Work Processes (3-5 per craft): Create: "Installation OJT," "Maintenance OJT," "Service OJT." Varied required hours (100-500+). Different statuses.
Locations (3): One Physical (with address), One Company (ABC Plumbing), One Virtual (Zoom link). Include realistic contact info.
Instructors (5-10): Create with varied specializations (multiple crafts per instructor). Vary status (active/inactive). Ensure some have portal access, some don't.
Students (20-30): Create diverse cohorts: (a) students with company association (for OJT testing), (b) students without company (non-OJT eligible), (c) students linked to multiple companies. Vary craft/level. Active and inactive statuses.
Companies (5): Create: ABC Plumbing (dues=Gold), XYZ Electrical (dues=Silver), etc. Vary dues levels (Bronze/Silver/Gold/Platinum). Include active and archived.
Chapter Staff (L1, L2, L3): Create 3 test accounts: qa-l1@test.abc, qa-l2@test.abc, qa-l3@test.abc. Assign Education module permissions per level. Use for phase testing (L1 browse, L2 edit, L3 admin features).
Instructor Portal User: Create qa-instructor@test.abc with portal access. Verify Instructor portal screens accessible only to this account.
Student Portal Users (3-5): Create qa-student1@test.abc, qa-student2@test.abc, etc. Enroll in test courses. Verify Student portal screens show only their data.
Company Portal Users (2): Create qa-company-abc@test.abc (ABC Plumbing), qa-company-xyz@test.abc (XYZ Electrical). Verify Company portal shows only their students.
Limited Access User: Create qa-no-edu@test.abc with NO Education permissions. Verify Education module is not accessible (UI hidden, API blocked).
Email Test Account: Set up a test mailbox (qa-education@test.abc) to receive automated Education emails (enrollment confirmation, payment reminder, OJT status, etc.). Subscribe this address to all outbound emails for testing.
Email Template Verification: Confirm all Education email templates are configured: enrollment confirmation (student and company variants), payment reminder (student and company), payment plan installment, OJT status (approved/adjusted/rejected), mass communications. Each template should include context-specific info (course name, due date, amount, etc.).
SMTP Configuration: Verify SMTP settings in test environment match production. Test email sending by triggering a manual email (e.g., Unpaid Invoice Email from browse invoices).
Portal Course Registration: Create test scenarios with registration enabled and disabled. Verify UI shows "Register Now" vs "Contact Chapter" accordingly.
Payment Responsibility Selection (Portal): Configure settings with selection enabled and disabled. Test portal registration with both configurations.
OJT in Portal: Configure OJT enabled and disabled. Verify OJT menu appears/disappears for eligible students.
Payment Plan Configuration: Define 2-3 payment plan templates (e.g., 3 months, 4 months, 6 months with/without auto-draft). Use in course pricing and enrollment testing.
Past-Due Blocking Threshold: Set threshold (e.g., $100 balance blocks registration). Test with enrollments exceeding/below threshold.
Data Preservation: Maintain a "baseline" set of 20-30 stable test records (courses, enrollments, modules, crafts) that remain unchanged throughout testing cycle. These serve as reference data for regression checklists.
Throwaway Data: Use a separate set of "test" records for destructive testing (e.g., deleting courses, transferring enrollments, withdrawing students, archiving companies). These can be reset/recreated between test cycles.
Between Test Cycles: After a full test cycle, optionally reset throwaway data (delete test courses, unenroll test students) to ensure clean state for next cycle. Preserve baseline data and all audit trails (change history).
Data Documentation: Maintain a test data spreadsheet (master list of crafts, modules, courses, students, companies with IDs and key attributes). Future QA can use this to understand what data represents what scenario.
Invest 1-2 days in comprehensive setup before test execution. A well-organized test environment with clean, documented data prevents blockers during testing. Coordinate with DBAs or DevOps to seed bulk data efficiently. Document all setup steps so future QA can replicate the environment. Verify prerequisites before declaring environment "ready" (checklist all items above).