Тестовая матрица

Цели

• Проверить season/tour/registration/submission/result lifecycle.
• Проверить участие без аккаунта и claim access.
• Проверить teacher mode с выбранной организацией, Learning Group snapshots, помощников и площадочный подслой.
• Проверить LMS activity binding, temporary LMS-compatible adapter, task-bank source refs и locked activity structure.
• Проверить hidden results до publication.
• Проверить удержание результата, appeal vs arbitration и ручное утверждение порогов.
• Проверить generation documents только для finalized awards.

Unit tests

Core

• season status transitions;
• tour status transitions;
• track independent from delivery mode;
• award policy thresholds;
• publication requires finalized results.

Participants

• registration duplicate detection;
• participant without account;
• participant created from organization_student_id stores identity_organization_id and snapshot;
• access claim transitions;
• TourParticipation delivery mode per participant;
• two-step registration statuses: pre_submitted, needs_completion, submitted, pending_review, approved, duplicate_hold;
• official data package is required only by official registration policy and raw official fields are rejected by competitions API;
• teacher official flow can create parent contact/invite without granting parent access;
• parent registration sets child-mode participation;
• teacher_name_text never grants teacher access;
• disqualification blocks result publication.

Delivery

• LMS/adapter attempt and competition-facing submission ref cannot be edited after lock;
• group answer submit locks sent students after confirmation warning;
• new students can be submitted before first-tour close when policy allows;
• void requires reason;
• file validation;
• final MVP bulk upload accepts zip/images without required participant binding and marks late uploads;
• photo report transitions require comment for unconfirmed;
• activity binding lock prevents structure changes;
• LMS activity returns score by item;
• competition stores immutable score snapshot;
• scoring aggregation from snapshots.

Results

• rank calculation by track/category;
• award status calculation;
• percentage-oriented thresholds require manual approval snapshot;
• withheld result excluded from public publication;
• result finalization;
• amendment/void audit.

Integration tests

Individual registration

1. User registers for open season.
2. Registration approved.
3. SeasonParticipation created.
4. TourParticipation created.

Teacher registration through Learning Group

1. Teacher enters teacher mode and selects organization.
2. System reads Learning Group from Learning Workspace.
3. Competitions creates competition_group snapshot for season registration.
4. Teacher registers group or selected students.
5. Parent later claims one participant.
6. Updating Learning Group does not mutate historical competition snapshot automatically.

Parent registers child

1. Parent creates pre-registration for child.
2. Parent completes required fields and payment if needed.
3. Registration approved.
4. Child opens tour in child mode.
5. Parent can see status/result/document after publication policy.

Organization student registration

1. Identity creates organization_student.
2. Competitions creates participant with organization_student_id.
3. Participant snapshot remains stable after identity student update.
4. Family/student claim links optional student_profile_id without automatic merge.

Paid season

1. Registration submitted.
2. CRM payment required.
3. CRM entitlement received.
4. Registration approved.

LMS activity binding

1. Admin connects tour/grade category to LMS activity.
2. Activity binding and task structure locked.
3. Tour opens.
4. Participant launches LMS activity attempt from competitions.
5. LMS returns score by item.
6. Competition stores immutable score snapshot.

Temporary LMS-compatible adapter

1. Admin configures temporary adapter with locked activity snapshot.
2. Adapter follows LMS activity contract: activity, item, attempt, response, file response, checking result, score.
3. Tour opens without full LMS runtime dependency.
4. Submission/attempt checked by adapter.
5. Competition stores refs/status and score snapshot, not raw canonical task runtime.

Results and documents

1. Submission checked.
2. Score snapshot finalized for result calculation.
3. Result calculated.
4. Threshold snapshot approved manually.
5. Result finalized.
6. Withheld results excluded from publication.
7. Personal/public publication created by class/track.
8. Award and gratitude documents generated.

Appeals and arbitration

1. Participant submits MVP appeal for score disagreement.
2. Admin accepts/rejects appeal and creates score/check version if accepted.
3. Checker opens arbitration case for suspicious work.
4. Arbitration can withhold result without using appeal workflow.

E2E scenarios

Ученик проходит онлайн-тур

• registration;
• admission;
• tour open;
• LMS/adapter activity attempt submitted;
• score snapshot stored;
• checking;
• personal result;
• document.

Учитель проводит тур для группы

• teacher mode selected organization;
• Learning Group snapshot;
• group registration;
• helper with limited rights;
• delivery mode per student;
• warning before group answer submit;
• upload scans/answers;
• late new student before tour close;
• results visible to teacher after publication.

Открытая площадка

• venue application;
• admin approval;
• public list and map;
• participant venue selection/change;
• capacity cannot be reduced below assignments without admin process;
• participant assignment;
• venue list export;
• post-tour files upload;
• photo report submitted/confirmed/unconfirmed.

Второй тур с несколькими зачётами

• tracks configured;
• participants assigned to tracks;
• results calculated separately;
• public standings separated.

Security tests

• participant cannot read another participant result;
• parent cannot claim чужую запись without approval;
• teacher cannot see unrelated Learning Group or competition snapshot;
• helper cannot exceed granted limited rights;
• venue cannot see non-assigned participants;
• student cannot edit locked LMS/adapter attempt or competition-facing submission ref;
• parent cannot submit child competition attempt unless policy explicitly allows representative submission;
• public cannot see hidden results;
• public cannot see withheld result;
• checker cannot access non-assigned submissions;
• document verification reveals only public-safe data.

Integration resilience tests

• LMS activity runtime unavailable blocks launch unless approved temporary adapter exists;
• task-bank unavailable before lock blocks activity binding or marks issue;
• temporary activity adapter follows LMS contract and requires locked activity snapshot;
• task-bank source does not become runtime;
• identity organization merge does not delete historical participants/results;
• CRM payment event duplicate safe;
• document generation failure does not lose finalized result;
• late submission after close requires admin override;
• duplicate student creates duplicate review queue, not silent merge.
• Learning Group update after snapshot is idempotent and does not rewrite registrations.
• LMS training attempt does not create competition submission/result.
• Student archive shows trainer only after LMS training publication is published.

Acceptance gates

• All lifecycle transitions have unit tests.
• Registration, group, venue and claim access have integration tests.
• Two-step registration, parent child-mode, group answer lock, photo reports, appeals and arbitration have tests.
• Task-bank locked usage tested.
• Results hidden until publication.
• Score/result/document changes audited.
• E2E covers student, teacher, venue and admin paths.