This page requires java-script to be enabled. Please adjust your browser-settings.
streber
PM
Login
|
Register
Home
Recent changes
Your Tasks
Efforts
Bookmarks
Overall changes
P
rojects
for
streber commun...
streber
People
Companies
S
earch:
streber
>
Tasks
|
Topics
|
Milestones
|
Versions
|
Files
|
Changes
Help
UI
>
Tasks
>
Approval Manag...
> Comment
Antwort auf Neue Notiz
/
#766
Edit
Bookmark
Delete
The Change Process
A change process is the set of rules that exist to control workflow. These rules define a set of states and determine how an issue can pass from one state to another. This includes not only the path that the issue can take, but also the states that specific users are allowed to assign to an issue.
The default behaviour of Fast BugTrack is to allow our customers to follow their own change process. When Fast BugTrack is installed, a default process is put in place to allow the product to function immediately. This includes a common set of states that are outlined in the diagram below. This system can then be configured to meet any needs.
Our default process begins in the "Open" state and progresses to "Ready for Retest" and then onto "Closed". Closed issues are then hidden by default in the system. If the issue is not tested successfully, it is then sent back to the open state to start the process again. An issue can become "Deferred" at anytime and remains in that state until the user is ready to address it.
Default Process
Simple Example
A bug is often raised by a tester. A description of the bug is written, including the environment, product revision, and instruction on how to reproduce it (if possible). The bug is then Assigned to the project manager to determine which department is responsible. The bug is marked as "Open", and immediately begins a history trail within the system.
The project manager is notified that a new bug has entered the system. Immediately, the manager determines who should be handling the fix for the bug. The bug is then re-assigned to the correct developer who can fix the problem.
The developer reproduces the bug using the information provided by users who defined and directed the bug to him/her. Then the bug is fixed and it's status changes to "Ready for Retest". The developer passes the fixed bug to the testing or QA department.
The tester is notified about being assigned a bug, and tests the bug to see if the newest fix is working properly. If it passes, the tester moves the bug to "Closed" , or marks it as "Rejected", if it still does not pass the testing phase. A "Rejected" bug will go back to the developer, who must attempt to fix it again. At any time during this bug fix, the exact status and history of the fix are available to everyone in the system. This information is also easily available for creating reports of outstanding issues. At any stage in this process, there is a full history trail and accountability record as illustrated below (this is also the actual email notification format that is passed to each individual as they are incrementally assigned the issue):