Linear helps product and engineering teams track work, discuss changes, and plan iterations quickly. QA benefits from that speed when defects retain sufficient context: conditions, impact, expected behavior, and evidence that a fix works. A lightweight issue should still explain more than “payment is broken.” A good Linear process keeps details available to the assignee and makes work status visible without constant verbal clarification.
Issues, teams, projects, and cycles
An issue is the basic work item: a defect, improvement, or implementation task. A team owns its process, statuses, and issues. A project groups related work toward an outcome, while a cycle defines a team's timeboxed iteration. A cycle is distinct from a release version: issues in one iteration may ship separately, and a major release may span several cycles. QA should agree where the target delivery is recorded and how to locate the exact build to verify.
Statuses and labels as team agreements
Workflows are defined per team and may differ between neighboring teams. A team might use Ready for QA with clear exit criteria for its verification queue; this is a configuration example, rather than a mandatory Linear standard. Labels can identify bugs, product areas, or severity. Priority determines work order; severity can follow a separate team convention. Avoid creating dozens of similar labels if they prevent reliable filtering of critical defects.
Triage: an incoming queue, without a commitment to fix
Triage supports reviewing incoming problems, clarifying data, finding duplicates, and deciding whether to accept work. An issue in triage is not necessarily scheduled for the current cycle. Triage issues are excluded from ordinary views by default unless explicitly included through the relevant filter. Review this queue separately before release. An empty Active issues view does not establish that support has reported no new critical problems.
Writing a concise, useful defect
A title should show the condition and effect: “Invoice retains the old price after a plan change.” Include the build, role, data, steps, expected value, and actual value in the description. State the impact and source of the expectation. Attachments should support the claim rather than replace its explanation. For a large investigation, provide a brief conclusion and a link to diagnostics accessible to the assignee. This keeps Linear convenient while allowing someone outside the original discussion to reproduce the problem.
Practice: changing a subscription plan
A team is changing billing. Requirements say a new plan applies to the next billing period without recalculating the current paid period. The test account has an active subscription and controllable dates; real charges are disabled. QA finds that a draft invoice shows the old price for the next period. A useful defect must distinguish an incorrect calculation from stale interface text.
- 1.Search for similar issues about plans, invoices, and period changes. Compare the subscription's initial state and the source of the incorrect amount.
- 2.Create an issue in the responsible team with the test plan, dates, and expected price. Attach a sanitized calculation response and the displayed value.
- 3.During triage, agree on impact, ownership, and priority. Link the issue to the billing project and any confirmed dependent change.
- 4.After acceptance, verify that the issue appears in the appropriate plan. The chosen cycle represents the work period; delivery details are recorded separately according to team rules.
- 5.When the fix is available, repeat calculations for both the next and current periods. Expect the new price only where requirements specify it, with no real charge.
- 6.Record the build and retest result, then perform the agreed transition. Issue history should distinguish completed development from verified behavior.
Views for QA
Create clear filters for the team, verification status, bug label, and relevant project. Separate views help identify blockers and unassigned issues. Verify the selection against known examples: a triage defect, a ready fix, and a completed issue should appear according to the intended rules. Linear has its own filters and views; Jira JQL cannot be pasted in directly. Document each view's purpose so colleagues understand the question it answers and what it excludes.
Handing work between teams
Moving an issue to another service team changes its context. Linear's documentation explains that the identifier may change, status maps to the recipient's workflow, and some properties may be cleared or mapped differently. After moving an issue, check the owner, project, cycle, labels, and actual queue. Sharing a link alone does not establish that the receiving team has noticed the issue or accepted its priority. Leave a short technical explanation of the transfer.
Relationships and development automation
Record real blocks, blocked by, related, and duplicate relationships to show work dependencies. Code integrations can change statuses after pull request events, but a merge does not prove that a fix is available in the test environment. Check automation settings and agree which event means a fix is ready for retest. When a pipeline updates an issue, its build comment should identify a specific artifact so QA does not have to infer it from the latest repository branch.
The limits of test documentation
An issue stores work and discussion but does not by itself replace a repository of repeatable test cases and execution history. A small change may need only clear acceptance criteria and a verification result; a large regression needs a separate structure linked to the project and build. Avoid creating permanent issues for every case merely to increase counts. Distinguish agreed coverage, actual execution, and defects found in particular runs so reporting does not mix different entities.
Common mistakes and practical lessons
Common mistakes include treating a cycle as a release, overlooking triage, closing defects on merge, and moving issues between teams without reviewing their properties. The other extreme is imposing a huge template on every cosmetic observation. Effective QA in Linear preserves precision where it affects reproduction and decisions. The result is a fast, understandable queue and verified fixes with enough history for the next person.