Key concepts
This page explains the terms you will meet everywhere in QA Sync. For one-line definitions, see the Glossary.
People and access
Section titled “People and access”Organisation
Section titled “Organisation”An organisation is one customer company. It is QA Sync’s unit of tenancy: every app, task, QA result, approval, comment, notification and audit entry belongs to exactly one organisation, and database rules keep organisations isolated from each other. See Organisations and tenancy.
Member
Section titled “Member”A member is a person with access to an organisation. You have one QA Sync login (your email address) and can be a member of more than one organisation. Each membership has its own role and status.
Your role decides which workspace you land in and what you can change. QA Sync has seven organisation roles: Admin, Product Manager, Developer, Tester, UI Designer, Client and Viewer. QA Sync’s own platform operators hold a separate Super Admin role. See Roles and permissions.
Member status
Section titled “Member status”A member is either Active or Inactive. Inactive members can still sign in, but they see the Access Pending screen instead of a workspace. See Signing in.
App access and tester groups
Section titled “App access and tester groups”Admins see every app in their organisation. Every other role sees only the apps an admin has granted them. Testers also belong to one or more tester groups; each group belongs to one app, and a tester’s QA queue is built from the groups assigned to each task.
Structuring the product
Section titled “Structuring the product”An app is a product surface your organisation builds and tests, such as a web app or a mobile app. Apps are the top of the work hierarchy.
Module and submodule
Section titled “Module and submodule”A module is a testable area of an app (for example, Checkout). It records platforms (Web, iOS, Android), an environment and a build version. A submodule is a smaller area inside a module (for example, Payment methods). Every task belongs to one module and one submodule.
A task is a unit of work and the thing testers verify. It has a title, type (Functional, UI/UX, Performance or Security), test instructions, an expected result, an assigned developer, assigned tester groups, and planning fields such as priority, due date, story points, milestone and sprint.
Apps, modules, submodules and tasks share one delivery lifecycle (Draft → Backlog → Planned → In Progress → In Review → Staging → Ready to Ship → Production, plus Deprecated). Parents roll up the status and progress of their children. See Task lifecycle.
Milestone and sprint
Section titled “Milestone and sprint”A milestone is a dated goal; a sprint is a dated delivery window. Tasks and other items can be linked to one of each, which powers roadmap, burnup and burndown reporting.
Dependency
Section titled “Dependency”A dependency records that one item is waiting on another (for example, a task waiting for an API). Items with unresolved dependencies show as blocked and lower release readiness.
Testing and feedback
Section titled “Testing and feedback”Task request
Section titled “Task request”A task request is a tester’s proposal for test coverage that doesn’t exist yet. It describes the scenario, device, environment and evidence. An admin reviews it and either publishes it as a new task, merges it into an existing task, marks it reviewed or rejects it. Developers create task requests too, when they escalate a tester’s suggestion for admin review. See Task requests.
QA run and QA result
Section titled “QA run and QA result”When a task is in Staging, a tester opens it and starts a QA run. The run ends with a QA result of Passed, Failed or Blocked, plus severity, bug count, notes, reproduction steps and evidence. See QA execution and evidence.
Evidence
Section titled “Evidence”Evidence is what proves a result: screenshots uploaded to a QA run, video links, and screenshots or screen recordings attached to task requests. Files are stored privately and shown through short-lived signed links.
Feedback submission
Section titled “Feedback submission”A feedback submission is an issue report or a suggestion a tester sends on a task. Developers triage issue reports through their own status flow (New → Triaged → In Progress → Fixed → Needs Retest → Closed). See Feedback and suggestions.
Releasing
Section titled “Releasing”Approval
Section titled “Approval”An approval is a sign-off a release candidate needs before it ships, such as QA Approved or Product Manager Approved. Admins define approval rules; QA Sync creates the matching approvals on each item automatically. See Approvals and releases.
Release readiness
Section titled “Release readiness”Every item has a readiness score and status (Not Ready, At Risk, Ready, Approved for Release), calculated from missing approvals, failed QA, blockers, dependencies and overdue work. Only an admin can promote an item to Production, and promoting an item that isn’t ready requires a written override reason.
Staying informed
Section titled “Staying informed”Comment
Section titled “Comment”Comments are threaded notes on an app, module, submodule or task. Type @ and a name or email handle to mention someone. See Comments and mentions.
Notification
Section titled “Notification”QA Sync sends in-app notifications for assignments, status changes, QA results, approvals, releases, overdue work and mentions. Each person chooses which categories they receive. See Notifications.
Audit log
Section titled “Audit log”The audit log is an immutable record of privileged changes: access changes, create/update/delete of apps, groups, modules, submodules and tasks, task-request outcomes, developer status and note changes, approvals and QA results. Only admins can read it. See Audit log.