Тест-план LMS

Зачем нужно

LMS затрагивает контент, доступы, прогресс, работы учеников, преподавателей, чаты и интеграции. Тест-план фиксирует минимальный набор проверок, без которого домен нельзя считать готовым к разработке и запуску.

Test data

Для автотестов нужны fixtures:

• student A;
• student B;
• parent A, связанный только со student A;
• parent B, связанный только со student B;
• teacher A с assignment на student A;
• teacher B без assignment на student A;
• organization X, где teacher A имеет teacher mode;
• organization Y, где teacher A не имеет доступа;
• Learning Group A с student A;
• Learning Group B с student B без progress assignment;
• methodist;
• operations;
• admin;
• course draft;
• course published version 1;
• course published version 2;
• active enrollment;
• paused enrollment;
• revoked enrollment;
• lesson with required blocks;
• task-bank referenced activity;
• competition training/debrief material published as LMS training target;
• workbook;
• project;
• booking slot;
• chat thread.
• roadmap program/module/topic/pathway with layers;
• topic progress and completion evidence;
• product trajectory projection inputs from LMS and CRM;

Unit tests

Course and versioning

• создание course валидирует slug, title, subject;
• нельзя создать duplicate slug;
• draft version получает следующий номер;
• published version immutable;
• publish требует валидное дерево;
• retire запрещает новые enrollments;
• content hash стабилен для одинаковой структуры.

Tree validation

• node tree не допускает cycles;
• position уникален среди siblings;
• lesson может содержать required blocks;
• block body валидируется по type;
• broken task-bank reference блокирует publish;
• unlock rule валидируется по schema;
• completion rule валидируется по schema.

Enrollment state machine

• pending -> active;
• active -> paused -> active;
• active -> completed;
• pending|active|paused -> revoked;
• invalid transition возвращает error;
• revoked enrollment не удаляет progress;
• transition создаёт audit.

Progress calculation

• unopened lesson даёт not_started;
• first open даёт in_progress;
• required blocks completed дают completion;
• optional blocks не блокируют completion;
• returned submission даёт needs_review;
• accepted submission завершает activity;
• course progress агрегируется из lessons;
• recalculation idempotent;
• imported progress не перетирает внутренний без reconciliation.

Roadmap projection and completion

• public projection скрывает PII, purchases, attendance и personal progress;
• filters subject, level, format, layer, track, availability работают на API level;
• student projection показывает own progress и next step;
• parent projection требует family context;
• teacher projection требует active assignment;
• entry_requirements не блокируют enrollment;
• catchup не создаёт completion;
• attendance, lesson completion и task-bank result создают evidence, но не completion без rule;
• manual override completion требует reason и audit;
• recalculation completion idempotent;
• product trajectory block собирается из LMS roadmap refs и CRM product refs без ручной подмены source refs.

Attempts and submissions

• start attempt создаёт next attempt_no;
• submit locks answer;
• repeated submit with same idempotency key не создаёт duplicate;
• returned attempt позволяет новую попытку;
• feedback accepted пересчитывает progress;
• score correction создаёт audit;
• teacher override auto-check требует reason.

Permissions

• student видит только свои данные;
• parent видит только связанных детей;
• teacher видит только assigned students;
• methodist не видит student answers без отдельного права;
• operations не читает chat/submission без audited access;
• service webhook без signature rejected;
• admin read пишет audit при доступе к приватному объекту.

Learning Workspace

• teacher mode требует selected organization;
• teacher не видит Learning Group из чужой организации;
• create Learning Group пишет owner teacher и organization;
• add participant принимает только student_profile_id, не создаёт student profile;
• invite хранит safe identity ref, а не raw token/contact;
• assignment на LMS course не создаёт progress без enrollment;
• assignment на trainer/debrief не создаёт competition result;
• group progress скрывает participant без teacher assignment.

Integration tests

CRM entitlement

Сценарии:

1. CRM sends activated entitlement.
2. LMS creates enrollment.
3. Student sees course.
4. Student opens lesson.

Проверки:

• webhook signature verified;
• duplicate webhook idempotent;
• missing course returns controlled error;
• revoke closes access but history remains.

Task-bank check

Сценарии:

1. Lesson block references task-bank problem.
2. Student submits attempt.
3. LMS sends or records check request.
4. task-bank returns result.
5. LMS updates attempt, evidence and progress.

Проверки:

• answer key не хранится в LMS;
• accepted result completes required activity;
• returned result keeps lesson in progress or needs review;
• stale result rejected or ignored.

Identity family access

Сценарии:

1. Parent reads child progress.
2. Identity removes family relation.
3. Parent repeats request.

Проверки:

• access denied after relation change;
• family cache invalidated;
• previous audit remains.

Teacher assignment

Сценарии:

1. Teacher A has assignment.
2. Teacher A checks submission.
3. Assignment ends.
4. Teacher A tries to read new submission.

Проверки:

• active assignment grants access;
• ended assignment denies new access;
• replacement teacher sees new queue;
• old feedback author remains visible.

Learning Workspace assignments

Сценарии:

1. Teacher selects organization.
2. Creates Learning Group.
3. Adds student A and invites parent.
4. Assigns LMS lesson and task-bank trainer.
5. Opens group progress.

Проверки:

• selected organization validated by identity context;
• group appears in “my groups”;
• invite accept activates participant after identity validation;
• assignment is idempotent;
• progress row for student A visible only with lms.progress.read and teacher assignment;
• denied participant rows do not leak private progress.

Competition training and debrief

Сценарии:

1. Published competition material is available as training target.
2. Teacher assigns it to Learning Group.
3. Student starts training attempt.
4. task-bank returns check result.
5. LMS records evidence/progress.

Проверки:

• attempt contextDomain is lms;
• no competition_submission, competition_check, competition_result or ranking is changed;
• training result is visible as LMS evidence according to progress rules;
• official competition result remains read-only and separate.

Booking

Сценарии:

1. Two users try to book last seat.
2. One succeeds.
3. Second receives capacity error.

Проверки:

• row lock or optimistic concurrency prevents overbooking;
• hold expires;
• cancellation frees seat according to policy;
• booking event emitted once.

External LMS import

Сценарии:

1. Import external progress.
2. Normalize into evidence.
3. Recalculate snapshot.
4. Receive conflicting later import.

Проверки:

• external id stored;
• duplicate import idempotent;
• conflict visible in admin;
• internal progress not overwritten silently.

E2E tests

Student completes lesson

Flow:

1. Student logs in.
2. Opens course.
3. Opens unlocked lesson.
4. Views required block.
5. Submits activity.
6. Receives accepted result.
7. Progress updates.

Expected:

• lesson state changes from not_started to completed;
• course progress increases;
• activity and progress events emitted;
• page shows next step.

Returned homework

Flow:

1. Student submits homework.
2. Teacher returns it with visible feedback.
3. Student sees returned status.
4. Student reopens and resubmits.
5. Teacher accepts.

Expected:

• old submission remains in history;
• new submission is linked;
• progress waits for accepted status;
• feedback is visible to student and parent if policy allows.

Parent views progress

Flow:

1. Parent opens child dashboard.
2. Opens course progress.
3. Opens feedback summary.

Expected:

• only linked child data visible;
• private teacher notes hidden;
• direct URL to another child returns 403.

Teacher review queue

Flow:

1. Teacher opens review queue.
2. Filters overdue submissions.
3. Opens submission.
4. Adds feedback and accepts.

Expected:

• only assigned submissions visible;
• concurrent review conflict handled;
• progress recalculated.

Teacher Learning Workspace

Flow:

1. Teacher logs in and selects organization.
2. Creates Learning Group.
3. Invites student/parent.
4. Assigns course, trainer or lesson.
5. Opens group progress.

Expected:

• only selected organization groups are visible;
• invite status is visible without exposing raw contact/token;
• assignment target is validated;
• group progress shows only authorized rows.

Methodist publishes course

Flow:

1. Methodist creates draft version.
2. Adds module, lesson and blocks.
3. Links task-bank problem.
4. Runs validation.
5. Publishes version.

Expected:

• version becomes immutable;
• event emitted;
• new enrollment uses published version.

Chat context

Flow:

1. Student opens course chat.
2. Sends message.
3. Teacher replies.
4. Thread closes after course completion.

Expected:

• only participants can read;
• message event has no body;
• closed thread is readonly.

Security tests

• Direct object reference to another enrollment returns 403.
• Direct object reference to another submission returns 403.
• Parent cannot access unlinked child after identity update.
• Teacher cannot access unassigned student.
• Teacher cannot access group progress through Learning Group membership alone.
• Teacher cannot create or read Learning Groups in an unselected/unauthorized organization.
• Learning Group invite token/contact is never returned by LMS API.
• Olympic training attempt cannot update competition result.
• Revoked enrollment cannot open lesson or submit attempt.
• Published version cannot be modified by content API.
• Webhook replay is rejected.
• Chat attachment type and size are validated.
• Admin private read requires reason and writes audit.
• Error responses do not leak existence of private objects where policy requires 404 masking.

Performance tests

Targets for MVP:

Operation	Target
student dashboard	p95 under 500 ms for 20 enrollments
course tree with progress	p95 under 700 ms for 300 nodes
lesson load	p95 under 500 ms excluding video CDN
review queue	p95 under 700 ms for 1,000 pending submissions
Learning Group list	p95 under 500 ms for 100 groups / 2,000 participants in organization
group progress	p95 under 900 ms for 200 participants after permission filtering
progress recalculation single enrollment	p95 under 1,000 ms
booking last seat transaction	p95 under 300 ms under contention

Data consistency tests

• Enrollment references existing course version.
• Progress snapshot references same course version as enrollment.
• Attempt belongs to active enrollment at submit time.
• Submission source exists.
• Feedback belongs to submission visible to teacher.
• Learning Group references valid organization context from identity.
• Learning Group Participant references student_profile_id, not local student record.
• Learning Group Assignment target refs are validated by target domain before activation.
• Workbook revision numbers are sequential.
• Booking capacity never negative.
• Chat participant exists before message create.

Observability checks

Для production readiness проверяются:

• structured logs for state transitions;
• metrics for progress recalculation;
• metrics for event publish/consume;
• dead-letter queue visibility;
• audit search by target and actor;
• alert for failed CRM webhook;
• alert for failed task-bank check handling;
• alert for external sync conflict spike.

Acceptance gates

Перед запуском должны пройти:

• all unit state-machine tests;
• all permission tests;
• integration tests for CRM, task-bank and identity;
• E2E student completion;
• E2E teacher feedback;
• E2E teacher Learning Workspace group/invite/assignment;
• E2E competition training/debrief as LMS attempt, not competition result;
• E2E parent progress;
• booking race test, если booking включён в MVP;
• chat access test, если chat включён в MVP;
• performance smoke for dashboard and course tree.