🟦 EdTech QA

Model answer

EdTech roles exist for pedagogy and child safety, so the scoping is relationship-based, not seat-based. I'd assert a student sees only their own assignments, grades, and submissions; a teacher sees only their assigned classes and the students within them; an admin's scope is the school/district; and — the dimension that's easy to miss — a parent sees only their own child's data and never another child's. I'd probe that parent scoping at the API: take a parent authenticated for child A and request child B's records by ID, asserting denial. I'd test edge relationships: a student in multiple classes, a teacher who is also a parent, shared-custody parents, and a student who moves classes mid-term. Minor-data sensitivity shapes visibility, so I check that even within a permitted scope, restricted fields are masked appropriately. The distinction from SaaS RBAC is that the unit of access is a child and the constraints come from child-safety law, not seat monetisation.

Model answer

Rosters are externally owned and change constantly, so I test the sync as an ongoing reconciliation, not a one-time import. Initial sync: students, teachers, and class assignments import correctly with stable identity mapping. Then the churn that defines a real term: a student added mid-term appears in the right class, a dropped student is removed (but their prior grades are retained per policy), a student moved between classes is re-scoped, and duplicates or identity collisions are handled rather than creating a second account. For LTI specifically, I'd assert the launch passes the correct user identity, role, and course context, that deep-linking lands on the right resource, and that a launch for an unknown user is handled safely. I'd test a partial/failed sync — it must not silently drop enrolments — and reconcile counts against the SIS. The signal is that the SIS/LMS is the source of truth and the integration must stay consistent through constant enrolment change.

Model answer

A gradebook is high-integrity because an incorrect grade affects a student's record and progression, so I treat the calculation like financial math. I'd test the weighting schemes (categories summing correctly, weighted vs points-based), late penalties applied per policy, dropped-lowest-score rules, extra credit, and rounding at the boundary where a grade flips a letter. Excused vs missing vs zero must be distinct, because they compute differently. I'd assert recalculation on every input change is correct and consistent, and that a curve or bulk adjustment applies uniformly. Integrity also means traceability: a grade change should be auditable — who changed it and when — and not silently overwrite history, so a student or parent dispute can be investigated. I'd test concurrent edits by co-teachers and that an in-progress term and a finalised term behave differently. The framing is that grades are correctness-critical and auditable, not casual editable data.

Model answer

Assessment integrity has to hold under both tampering and failure, so the timer must be server-authoritative — I'd test that manipulating the client clock or local timer can't extend the allowed time, and that the deadline is enforced on the server at submission. Disconnect handling is critical and two-sided: a student who drops mid-assessment should resume with the correct remaining time and their answers preserved, without the disconnect either gifting extra time or wiping work, and a refresh shouldn't reset the timer or grant a second attempt. One-attempt enforcement: a completed or submitted assessment can't be retaken, and concurrent sessions from two devices can't be used to game it. Auto-submit on timeout must capture whatever was entered. For proctoring/anti-cheat I'd assert the controls fire (tab-switch, copy/paste, multiple faces) but don't corrupt a legitimate submission or falsely fail a student with a benign network blip. The thread is integrity under adversarial and unreliable conditions, enforced server-side.

Model answer

Minor-data law shapes both how I handle test data and what I assert functionally. On data: I use only synthetic student records with fabricated identifiers — never real student PII — because COPPA/FERPA make real minor data in a test environment a serious risk. On behaviour: for COPPA (under-13), I test that collecting a child's data requires verifiable parental consent, that the consent gate actually blocks collection until granted, and that consent can be withdrawn. For FERPA, education records can't be disclosed without authorisation, so I assert role-based access to records, that a parent accesses only their child, that directory-information opt-outs are honoured, and that data isn't shared with third parties beyond what's permitted. I'd seed students in each consent state and each access relationship to test the gates directly. I'd scan that student PII doesn't leak into logs or analytics. The signal is that for EdTech, privacy compliance is a set of testable functional requirements about minors, not just a data-hygiene footnote.

Model answer

In K-12 accessibility is functional: if a screen reader user or a student with motor differences can't complete a graded assessment, that's not a cosmetic defect, it's the child being unable to do required work — and often a legal obligation. So I'd build accessibility in as a gate, not a closing audit. Coverage targets the highest-stakes flows first: assessments and submissions, core learning activities, sign-in, and navigation. I'd combine automated checks (contrast, labels, structure) with manual assistive-tech testing — keyboard-only, screen reader, and switch access — because automation only catches a fraction. I'd account for diverse learners: extended-time accommodations interacting with the assessment timer, captions on media, and readable language for younger students. Error and focus management matter especially on timed tasks. I'd set WCAG AA as the baseline gate and assert it in CI where automatable, with manual sign-off on the critical journeys each release. As a lead I'd make 'a student can complete this with assistive tech' an explicit acceptance criterion so it's owned upfront, not retrofitted.