In addition to completing tasks, developers are also responsible for confirming and resolving bugs.

After a build is submitted for testing, QA begins validation and defects may be discovered. At that point, an important responsibility of the development team is to address the reported bugs.

In Sanplex, the bug handling workflow is straightforward:

QA submits a bug → Developer confirms and resolves the bug → QA verifies and closes the bug (standard flow)

There is also a rework (reactivation) flow:

QA submits a bug → Developer confirms and resolves the bug → QA verification fails → Bug is reactivated → Developer resolves again → QA verifies and closes

Developers should confirm and resolve bugs assigned to them, and record the resolution details in Sanplex.

To learn how to confirm and resolve bugs in Sanplex, watch the video: [Video link—Sanplex version to be provided]

视频介绍

1. Confirm Bugs

After QA submits a bug, if the developer cannot resolve it immediately, they can confirm the bug first to acknowledge receipt and provide feedback to QA.

• The bug list indicates whether a bug has been confirmed.
• The bug detail page provides a Confirm action.
• The bug list also provides a Confirm action in the right-side action column.

Note: once a bug is resolved, it will also be automatically marked as Confirmed.

Developers can confirm bugs directly from:

• Dashboard/My > To Do > Bugs
• Testing > Bugs
• Project > Testing > Bugs
• Execution > Testing > Bugs

Confirm action on Testing > Bugs:

图1

2. Resolve Bugs

Developers can resolve bugs from:

• Dashboard/My > To Do > Bugs
• Testing > Bugs
• Project > Testing > Bugs
• Execution > Testing > Bugs
• or directly from the bug detail page by clicking Resolve

图2

Resolve action on the bug detail page:

图3

After clicking Resolve, select both the Resolution and the Resolved Build/Fix Build.

图4

After the bug is resolved successfully, its status changes from Active to Resolved.

3. Bug Resolution Options

3.1 Seven Built-in Resolution Options

Sanplex provides seven common resolution options:

• By Design: works as intended; no change required
• Duplicate: duplicate of an existing bug already logged
• External: caused by external factors; not an issue in this system
• Fixed: fixed and resolved
• Cannot Reproduce: cannot reproduce the issue
• Postponed: valid bug, but deferred to a later time
• Won’t Fix: will not be fixed

Note: Bugs resolved as Fixed and Postponed are typically treated as valid defects. If you need additional resolution options, add them via Admin > Custom > Bug > Resolutions.

3.2 Why There Is No “Convert to Requirement” Resolution

In Sanplex, converting a bug into a requirement is treated as a separate workflow rather than a resolution type:

• After a bug is converted to a requirement, the bug is automatically closed and subsequent tracking continues on the requirement.
• Conceptually, converting a bug to a requirement often means the issue is not yet fixed, but is being handled through requirement planning and delivery.

The bug detail page provides a Convert to Requirement action to convert a bug directly into a requirement.

After conversion, the system records the conversion in the bug’s history and related information (for example, in change history and requirement linkage/source fields); and the bug is closed automatically, with the close reason recorded as Converted to Requirement.

Convert to Requirement action on the bug detail page:

图5

After conversion, the bug is closed automatically. Click the requirement name to open the corresponding requirement.

图6