How QA and delivery teams use Plane

Finding defects is only one part of QA. Teams also need to establish whether fixes have been verified, whether those changes introduced regressions, and whether critical issues remain unresolved before a release.

These questions become harder to answer when requirements live in documents, defects are tracked separately, and release plans don't reflect the latest testing results. QA spends time chasing Engineering updates, while Delivery struggles to distinguish completed development from work that's actually ready to ship.

Plane connects requirements, defects, verification, dependencies, and release decisions through the same work items. QA can follow fixes through retesting, and Delivery can see what's cleared verification, what's blocking rollout, and what needs to move to the next release.

We'll walk through these workflows using a data platform team preparing a role-restricted bulk export feature, from reviewing acceptance criteria to documenting what ships.

Prepare work for QA verification

QA usually receives a feature that Product and Engineering have already scoped. The earlier path from customer demand into delivery work is covered in feature request management in Plane. Here, QA's job is to understand what's expected and flag what needs clarification or completion before testing begins.

Review requirements and expected behavior in Pages

Open the feature's PRD in Project Pages to review the requirements and acceptance criteria alongside the related implementation work items. In this example, the Bulk data export PRD covers file generation, permission checks, and interrupted exports, with links to the work items responsible for each.

QA can comment directly on the Page or on a linked work item. A question about what should happen when a user's role changes during an export stays next to the requirement, and Product or Engineering can reply and update the expected behavior there.

Because the Page and work items reference each other, QA can move to the implementation without copying the same specification into a separate test document. The comments also show which ambiguities were resolved before verification starts.

Identify testing blockers with Dependencies

Not every completed-looking task is testable. On the verification work item, use a Blocked by dependency to show that QA is waiting on a specific Engineering task. For the export, permission verification depends on the permission-check implementation being ready.

The relationship is visible from both work items. QA can open the blocker, see its assignee and state, and follow progress without maintaining a separate list of Engineering handoffs. A dependency records what is waiting on what. It does not automatically change a work item's state when Engineering finishes.

This matters when the QA queue fills up. The team can tell work that is ready for verification apart from work that cannot move yet, using Plane's actual dependencies rather than a manually maintained Blocked label.

Run testing and track verification

QA work needs clear ownership, verification states, and accessible evidence. Plane's workflows, Views, and Custom automations organize the testing queue, while work item descriptions, comments, and attachments keep results with the work.

Move testing through QA states

Configure workflow states that reflect the team's verification process, such as Ready for QA, In verification, Needs fix, Retesting, and Verified. QA engineers move work items through those states as they perform checks, and the assignee shows who owns the next action.

Add an Environment Option custom property, with values such as Staging and Pre-production, when the same behavior needs checking across different builds. That property can show on work items and narrow Views.

A Custom automation can route a work item to the QA lead when its state changes to Ready for QA. The workflow tracks verification progress; the automation handles the handoff without deciding whether a test passed.

Create Views for incoming tests, blockers, and retests

A saved View grouped by state gives QA an immediate picture of what is ready, underway, awaiting a fix, or verified. Save additional views for the queues people actually return to:

• Incoming verification
  Filter to Ready for QA so the lead can assign new testing work.
• In verification
  Filter to In verification and group by assignee to see the active workload.
• Awaiting retest
  Filter to Retesting so fixes returning from Engineering don't get buried among first-pass checks.
• Blocked tests
  Show open verification work with unresolved Blocked by dependencies, so testers can inspect the Engineering work holding it up.

These Views keep their filters and layout. QA engineers work from a focused queue while the lead reviews the wider workload, without maintaining separate tracking sheets.

Report and resolve defects

A failed check becomes actionable when Engineering has enough information to reproduce it, and QA can follow the same defect back through the fix and retest.

Capture reproducible bugs with Work item types

Create a work item titled Restricted users can export unauthorized records using the Bug Work item type. Fill the fields an engineer needs to reproduce it, keeping the recurring ones in custom properties so they stay consistent across defects:

• Severity (custom property): Critical
• Affected environment (custom property): Staging
• Description: Steps to reproduce, expected behavior, and actual behavior.
• Attachments: A redacted sample and test-log reference.

Add a Relates to relation to the permission requirement and a Blocks dependency to the customer rollout work item. The bug is now connected to both the behavior it breaks and the delivery work it prevents.

Assign the bug to the engineer responsible for permission filtering. QA can follow its owner, activity, and state directly on the work item as the investigation progresses.

Track code fixes and QA retests

With GitHub or GitLab connected, an engineer can associate the branch, commits, and pull request with the Bug work item. QA opens the development activity on the work item to follow the implementation instead of asking for status in a separate channel.

Depending on the configured integration and state mapping, development events may update the work item's state. That is still not proof of verification. A merged pull request describes Engineering progress, not a successful QA retest.

When the fixed build is ready, the work item returns to the QA queue. The tester repeats the restricted-role export check and records the outcome and evidence on the Bug work item. Engineering activity and QA verification stay together in the work item's history. The bug tracking guide goes deeper into triage, state configuration, and verification.

For the integration setup, see how integrations work in Plane.

Coordinate delivery around QA findings

QA sees individual failing checks. Delivery needs to understand what those failures prevent from shipping and which dates or commitments may change.

Surface delivery risks with Workspace Views

Create a Workspace View to bring open QA findings and high-priority delivery work together across Engineering, Platform, and QA projects. Show state, priority, assignee, and due date so the delivery lead can identify what needs attention without opening each project separately.

The permissions bug and unfinished audit-logging work appear alongside the rest of the active delivery queue. The lead can open either item to see its owner, latest update, and next action.

QA remains responsible for the verification result. Delivery uses the cross-project view to coordinate follow-ups and decide whether the rollout plan needs to change.

Replan affected work in the Timeline layout

Switch to Timeline to compare the planned verification dates with the customer rollout. A delay in testing can now be assessed against the dates the team has committed to.

If the rollout date needs to move, the delivery lead adjusts the affected work item dates and records the reason on a delivery Page. Changing a date does not automatically reschedule every related work item, so the lead checks the rest of the plan before confirming the change.

The Page links to the revised rollout work and records who owns the next decision. The schedule changes in Timeline, while the reason for the change stays accessible to the team.

Manage QA sign-off before release

A testing state tells the team where an item stands. A QA approval flow establishes who can sign off on the result before that state changes.

Configure an approval flow for verification

Use a workflow to define the allowed QA states and transitions. For the Bug Work item type, the team can require a QA lead's approval when an item attempts to move into Verified.

Configure an approval flow on that transition, select the QA lead as the approver, and set the outcomes. Approval sends the item into Verified, and rejection sends it back to Needs fix. Transition conditions and approval flows govern the move whether a person or a configured automation attempts it.

This makes the verification gate part of the workflow rather than an informal agreement in comments. It does not approve a release automatically. It confirms the specified work item has cleared its configured review.

Before approving the transition to Verified, the QA lead can review test results, supporting evidence, and acceptance criteria directly on the work item. If verification is incomplete, they can reject the transition.

Review release readiness and document what ships

After individual work items have cleared QA, the release lead reviews the complete version: what is included, what remains unfinished, and what the team can ship.

Review QA status in Release Scope

Create a Workspace Release for Data platform v2.4, with a target date and the person leading the release. In its Scope tab, select Add work items and bring in the relevant items from Engineering, QA, Platform, and documentation projects. The work stays in its original project with its assignee, states, and comments.

The lead uses Overview for progress and Scope to inspect the work behind the totals. A completion count helps with planning, but QA sign-off still comes from the verified work items and their evidence.

The lead reviews Release Scope alongside a readiness Page linking to verification evidence, outstanding risks, documentation status, and the decision owner. The permissions and audit-logging work have cleared QA. The remaining question is whether the complete scope and supporting release work are ready for the target date.

Move unfinished work to the next Release

One improvement remains unfinished: optimizing performance on very large exports. It is separate from the mandatory access controls that QA has already verified.

Delivery records the decision to ship the verified export functionality in v2.4 and defer the performance improvement to v2.5. When marking the Release as Released, the lead can transfer unfinished work to another unreleased Release or keep it associated with the current one. The team selects v2.5 for the deferred improvement.

That transfer changes release membership, not the underlying work item's state or ownership. The team must still make sure its deployment or release candidate matches the agreed scope through its own development and deployment process. Plane records the scope decision. It does not change the build.

The readiness Page records what cleared QA, what moved out, and who approved the final scope. Anyone checking the decision later can follow the links back to the verification evidence.

Prepare the Changelog from verified changes

Open the Release's Changelog tab and draft the notes around the work that actually shipped. Plane provides a rich-text editor for the release notes, which can be updated before or after the Release is marked Released.

For v2.4, the Changelog covers the new bulk export, role-based permission behavior, interrupted-export handling, and relevant upgrade or usage notes. The unfinished performance optimization is not presented as delivered.

The lead can open the completed work items from Scope and check QA's evidence before finalizing each claim. The Changelog stays with the Release as its record of shipped changes. Sharing an external announcement or publishing the notes elsewhere is a separate step.

For a deeper walkthrough of version planning and deployment decisions, see planning and shipping releases in Plane.

Use Plane Agents and skills for QA and delivery

The workflows above cover QA preparation, defect tracking, and release management. Plane Agents can review requirements and flag gaps in test coverage, reusable skills in Plane AI help identify risks in code changes, and Plane MCP brings work item context into coding tools such as Claude Code and Codex.

Each supports a different part of the QA process. Testing, verification decisions, and release approvals remain with the people responsible for them.

Identify testing gaps with Plane Agents

Acceptance criteria describe what a feature should do, but they may not account for every condition QA needs to test. Missing permission checks, failure scenarios, and boundary cases can leave gaps in verification.

Configure a Plane Agent to review requirements in Project Pages and the associated work items when assigned or mentioned. It can compare the expected behavior against documented test scenarios and flag areas that lack coverage, with references to the relevant requirements.

QA reviews the findings, adds necessary test cases, and decides what needs verification. The agent identifies potential gaps but does not execute tests or approve work.

Review security-sensitive changes with skills

QA can use a reusable security-reviewer skill in Plane AI to review code changes before retesting permission-sensitive fixes. For the bulk export feature, an engineer can share a pull request diff to check for authorization gaps, permission leaks, and sensitive data exposure.

The skill flags potential risks, references the affected code, and recommends checks. For example, it might identify an export API that validates the user but fails to restrict results to their account, prompting QA to test cross-account access.

The skill reviews available code without executing it or confirming vulnerabilities. Save it as a workspace skill for reuse across Engineering and QA, or attach it to a Plane Agent with the necessary code access.

For reusable agent instructions and examples, see essential agents and skills for your Plane workspace.

Investigate defects with Claude Code or Codex

While investigating the permissions bug, an engineer can use Plane MCP from Claude Code or Codex to bring the work item's context into a coding session. The flow is practical:

• Read Plane context
  Retrieve the Bug work item, its reproduction steps, environment, and linked permission requirements.
• Investigate the code
  Use the client's separately configured repository access to inspect the export implementation and reproduce the filtering problem.
• Record the finding
  Write the cause, associated branch or pull request, and required QA retest back to the Plane work item through MCP.

For example, the investigation finds that a role filter applies to the preview query but not the export query. The engineer records the finding on the Bug work item so QA can see why the fix was made and what needs retesting.

Plane MCP gives the coding client access to supported Plane work item operations under the connected account's permissions. It does not grant repository access on its own. The same connected Plane context is available through other MCP-aware clients, including Claude and ChatGPT, for permitted actions.

Run QA and delivery on the same work

A release can have completed features and still be held up by an unresolved defect, a pending QA retest, or an unfinished dependency. The challenge is knowing exactly what's ready, what's holding up the rollout, and what needs to move to the next release.

Plane keeps those answers tied to the work itself. QA can track verification results and defects alongside Engineering fixes, while Delivery can review dependencies, adjust timelines, and see which work items have cleared approval.

Bring the whole path into Plane: QA handoffs, approval flows, Release Scope, and the Changelog. Run your next release in Plane.