Apps, modules and sprints

Everything in QA Sync hangs off one hierarchy:

App
└── Module
    └── Submodule
        └── Task

Admins build and maintain this structure. Everyone else sees the parts that belong to apps they have access to.

Apps

An app is a product surface you build and test, such as Customer web app or Driver iOS app.

Create an app: Apps → Add App, then enter App Name, Description and Workflow Stage.

App access is granted per app (see Inviting and managing members), so apps are also your main tool for deciding who sees what.

Tester groups

A tester group is a team of testers inside one app. Tasks are assigned to groups, and testers see staging tasks through their groups.

Create a group: Groups → Add Group, then choose the App, and enter Group Name and Description.

• A group belongs to exactly one app.
• A tester can be in several groups, but only in apps they have access to.
• A task with no groups never reaches a tester.

Modules and submodules

A module is a testable area of an app; a submodule is a smaller area within it.

Create a module: Modules & Submodules → Add Module, then set:

Field	Notes
App	The app the module belongs to.
Module Name, Description
Platforms	One or more of Web, iOS, Android.
Environment	Local, Development, Testing, Staging or Production.
Build / Version	The build under test. Tasks inherit it unless they override it.
Assign Tester Groups	Default groups for this module.
Workflow Stage	See Task lifecycle.

Create a submodule: from a module, add a submodule with a name, description, status (Active or Inactive) and workflow stage.

Planning fields

Apps, modules, submodules and tasks share the same planning fields:

Field	Values
Priority	Critical, High, Medium, Low
Work Type	Feature, Bug, Improvement, Refactor, Technical Debt, Research, Hotfix, Maintenance, Documentation
Risk Level	Low, Medium, High, Critical
Estimated Hours, Actual Hours, Story Points, Complexity Score	Numbers
Start Date, Due Date	Dates. Past-due active items count as overdue.
Milestone, Sprint	One of each.
Release Version	Free text, e.g. 2.4.0. Release analytics group by this.
Owner, Reviewer, QA Owner	Members. They receive notifications about the item.
Blocked Reason	Waiting for design, backend, frontend, client, API, content, approval or external team; technical issue; missing requirement; missing access; unknown.

Milestones and sprints

A milestone is a dated goal (name, description, due date). A sprint is a dated delivery window (name, description, start and end dates). Linking work to them powers the roadmap timeline, milestone progress and risk, sprint velocity, burnup, burndown and scope creep charts. See Analytics and reporting.

To link an item, edit it and choose a Milestone and Sprint in its planning fields.

Note

QA Sync doesn’t yet have a screen for creating or editing milestones and sprints. Contact QA Sync to add or change them for your organisation; once they exist, admins can link any item to them.

Dependencies

Any app, module, submodule or task can depend on another. In an item’s editor, under Dependencies, add the item it waits on, the dependency type (Finish to Start, Start to Start, Finish to Finish, Start to Finish) and the reason. Unresolved dependencies mark the item as blocked and reduce release readiness. See Task lifecycle.

Status rollups

Parents summarise their children automatically:

• A task’s status rolls up to its submodule, then module, then app.
• If all active children share a stage, the parent takes that stage. Otherwise the parent takes a progress-weighted average, so one advanced child can’t over-promote its parent.
• Progress percentage is the average of the children’s stage weights (Draft 0 %, Backlog 10 %, Planned 20 %, In Progress 45 %, In Review 60 %, Staging 75 %, Ready to Ship 90 %, Production 100 %). Deprecated children are ignored.

When you change the stage of an app, module or submodule that has children, QA Sync asks whether to apply the stage to its children as well.

Bulk import

To load a whole test plan at once, select Bulk Import in the admin header, paste or upload a JSON document, validate it, and import.

{
  "apps": [
    {
      "name": "Customer web app",
      "description": "Core product",
      "groups": [{ "name": "QA Team" }],
      "modules": [
        {
          "name": "Onboarding",
          "platform": ["Web"],
          "environment": "Development",
          "assignedGroups": ["QA Team"],
          "submodules": [
            {
              "name": "Signup",
              "tasks": [
                {
                  "title": "Verify signup with a valid email",
                  "instructions": "Go to /signup, enter a valid email and password, submit the form.",
                  "expectedResult": "Account is created and the user lands on the welcome screen."
                }
              ]
            }
          ]
        }
      ]
    }
  ]
}

Level	Required	Optional
App	name	description, groups, modules
Group	name	description
Module	name	description, platform, environment, buildVersion, assignedGroups, submodules
Submodule	name	description, tasks
Task	title, instructions, expectedResult	description, type, assignedGroups

Groups are referenced by name. Validation reports problems with their path in the document before anything is written. If an import stops partway through, the items already created are kept; fix the document and import the rest.