Traditional Template sample project: Workflows

Helix ALM includes workflows that can be configured to match the way your team works. Each item type has a workflow. In the Traditional Template project, the team configured a basic workflow for each item type to match their straightforward development process.

The following information describes how each workflow is configured and details on how each step in the workflow is used by the team.

Requirement Documents

The team has a formal process for creating requirement documents and getting sign-off from management. To support this internal process, the team developed a workflow to manage documents from first draft through reviews, approvals, and implementation. The workflow has nine states (represented by squares) and a few events (represented by arrows) to move documents between states.

State	Description
Draft	All new documents start in this state.
Awaiting Review	When the document is considered complete and ready for review, it moves to this state.
Reviewed	During the review process, the document can move between this state and Change Needed until it is ready for approval.
Change Needed	During the review process, the document can move between Reviewed and this state until it is ready for approval.
Approved	During the approval process, the document can move between this state and Not Approved until it is formally accepted and ready for implementation.
Not Approved	During the approval process, the document can move between Approved and this state until it is formally accepted and ready for implementation.
Implemented	When all related requirements are implemented, the document moves to this state.
Obsolete	Documents that are no longer applicable to the product move to this state.

Requirements

The team configured a simple workflow to keep all requirement types moving through the development process. The workflow has six active states (represented by squares) and a few events (represented by arrows) to move requirements between states.

State	Description
Draft	All new requirements start in this state.
In Review	When the requirement is considered complete and ready for review, it moves to this state.
Change Needed	During the review process, the requirement can move between this state and Reviewed until it is ready for approval.
Reviewed	When the review is complete, the requirement moves to this state and is assigned for approval.
Approved	When the requirement is approved, it moves to this state and is ready for implementation. Test cases can be generated from requirements in this state.
Implemented	When the requirement is implemented and considered completed, it moves to this state. Test cases can be generated from requirements in this state.

Test Cases

The team uses a workflow to make sure that test cases go through a review process before they put them into the test plan and avoid using obsolete or out-of-date test cases. The workflow has five active states (represented by squares) and a few events (represented by arrows) to move test cases between states.

State	Description
Draft	All new test cases start in this state.
Ready for Review	When the test case is ready for review, it moves to this state.
Change Needed	If changes are identified for the test case during the review process, it moves to this state.
Ready	When the test case is complete and ready to use in testing, it moves to this state. Manual test runs can be generated from test cases in this state.
Obsolete	Test cases that no longer apply to the tested application move to this state. This ensures that the team does not waste time generating tests from out-of-date test cases.

Manual Test Runs

The team tracks and reports on testing progress using a simple pass/fail workflow. The workflow has some complexity to support ambiguous test results. The workflow has seven active states (represented by squares) and a few events (represented by arrows) to move manual test runs between states.

State	Description
Not Started	All new manual test runs start in this state.
In Progress	After work starts on executing a manual test run, it moves to this state.
Results Unclear (Needs Review)	After a manual test run is executed, if the results are unclear, it moves to this state and is assigned to another tester to review.
On Hold	If a manual test run cannot be executed for some reason, it moves to this state until the blockage is cleared.
Passed	After a manual test run is executed and results are determined, it moves to this state or Failed based on the results.
Failed	After a manual test run is executed and results are determined, it moves to this state or Passed based on the results.
Closed (Ignored)	After a manual test run is executed, if the results are unclear, it is moves to this state so the team can ignore the test.

Issues

The team starts managing new issues with a simple yes/no decision in the workflow. New issues are reviewed and then either accepted or rejected. The processes of fixing and verifying are also split out to ensure the right people are performing each activity with metrics that show how each part of the process is working. The workflow has six active states (represented by squares) and a few events (represented by arrows) to move issues between states.

State	Description
Open	All new issues start in this state.
Accepted	Each issue is reviewed and, if a fix is needed, it moves to this state.
Fixed	After the issue is fixed, it moves to this state.
Closed (Verified)	After the fix is verified, it moves to this state.
Open (Verify Failed)	If the fix fails verification testing, it moves to this state and is assigned to a developer to fix.
Closed	Each issue is reviewed and, if a fix is not needed, it moves to this state.