QA and acceptance

QA should confirm that the client can complete the real operational workflow, not only that individual screens load. Use this page before launch, after major configuration changes, and after product changes that affect users, assignments, reporting, or integrations.

Acceptance principle

A scenario is accepted only when the owner can answer all three questions:

1. What did we expect to happen?
2. What actually happened in the UI, report, API, or webhook?
3. Which evidence proves the result?

Evidence can be a screenshot, export row, API response, webhook delivery log, or an internal note with the exact environment and timestamp.

Core QA scenarios

Scenario	Steps	Expected result	Evidence
Create active user	Add a user manually or through the agreed import/API path.	User appears in the space with correct role, state, and identifier.	User detail screenshot or API response.
Assign group learning	Add a user to a group with assigned content.	User receives the expected learning item.	User learning view and group assignment screenshot.
Assign direct learning	Assign content directly to one user.	User receives the item even without group membership.	User learning view and assignment detail.
Deadline handling	Assign content with a deadline.	Reporting shows the expected due date.	Report row or export row.
Completion	Complete a test or course as learner.	Completion appears in reporting and certificate behavior is correct.	Learner completion screen, report row, certificate state.
Revoked user	Revoke or archive a user.	User no longer acts as active participant, but history remains traceable.	User detail and historical report.
Content version change	Activate or receive a newer content version.	New assignments use the expected version; in-progress behavior is understood.	Content version detail and sample participation.
Integration delivery	Trigger configured API/webhook flow.	External system receives or can read the expected state.	API response, webhook delivery, or external log.

Owner sign-off checklist

Check	Pass criteria
Users	Sample users cover owner, admin, ordinary learner, and revoked user.
Groups	At least one group-based and one direct assignment are verified.
Content	Own content and purchased content are checked separately when both exist.
Reporting	Owner can find completion, overdue learning, and certificate status.
Integration	Retry and error handling are documented when API or webhooks are used.
Screenshots	Required screenshots exist or are explicitly marked as missing.
Open issues	Every known issue has owner, severity, and next action.

Regression pack

Run a smaller regression pack after changes to content, user import, assignment logic, reporting, or API integration:

• create or update one user,
• add the user to a group,
• verify assigned content,
• complete one learning item,
• check reporting and certificate state,
• verify integration output when enabled.

Known gaps log

Track unresolved issues in a simple table until there is dedicated feedback tooling:

ID	Area	Problem	Evidence	Owner	Status
QA-001	Example	Replace this row with a real rollout issue.	Screenshot or export path.	Project owner	Open

When paragraph-level feedback tooling is implemented, this table should link to the exact questioned paragraph or screenshot.