UI > Tasks > Feature (new)

Approval Management / Testing and Approval options / Bug-Task life cycle / #671

MoveBookmark

Summary

new
Apr 6, 2006
Apr 7, 2006 / frank
Sep 13, 2006 / pixtur
View previous 5 versions
 

Attached files

Summary
defaultProcess.gif
defaultProcess.gif
2565 bytes / ID 767 / Apr 9, 2006
Show Details
mantisflow.png
mantisflow.png
8110 bytes / ID 768 / Apr 9, 2006
Show Details
   
 
Need for Approval Management:
  • Testing and Approval options
  • Notifications to testers and managers when ready
  1. observe -->
  2. analyse -->
  3. assign task (to developers) -->
  4. (developers) perform task -->
  5. test result (by the observer [see 1.]) -->
  6. close the observation

The analyses should then also be added to Streber or can the note field be enough? Than the task section; developers should see the actions that have been assigned to them and you even can add the approval (e.g. by the analyser) option to the specific task. After all tasks have been performed (to solve the observation), the observation will be ready for test. According to my opinion the observer should test the result and if it is OK the observation can be closed. If the fix did not solved the observation a testnote should be added and the observation should be analyses again by the analyser (see life cycle).

4 Comments

frank

Apr 7, 2006
Neue Notiz
Retest: dies sind alle diejenigen Bugs, die man in seiner Eigenschaft als Tester gefunden hat und die inzwischen vom Entwickler bearbeitet wurden (d.h. der Zustand dieses Eintrags ist „RESOLVED“ und man ist der „Reporter“ oder „QA-Contact“). Der Tester sollte jetzt das Problem nachtesten und den Zustand des Eintrags auf „VERIFIED“ oder „CLOSED“ (oder evtl. auf „REOPENED“) setzen.


frank

Apr 9, 2006
version 2
Antwort auf Neue Notiz
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
  1. 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.
  2. 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.
  3. 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.
  4. 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):

pixtur

Apr 8, 2006
some comments...
Actually I would think that streber already handles most of this.
  1. observe --> create a new Task or bug-report
  2. analyse --> add a detailed description; attach files and screenshots; add an issue-report if required.
  3. assign task (to developers) --> assign task to another team member. This developer gets an notification mail (provided he entered an email address and enabled notification).
  4. (developers) perform task --> Developer sets the status of the task to completed? (probably by right clicking in the task-list, but not(!) at texts)
  5. test result (by the observer [see 1.]) --> The other team-members see a note in the changelist at projView. They retest the completion of the task and either set the status to approved or to open.
  6. close the observation

Note details should be changed thought:

pixtur

Apr 10, 2006
We are basically talking about the same thing here...
with a few exceptions:
  • the number of states is limited, so...
    • retest -> completed?
    • closed -> approved
    • reopened -> open (the reopened gets clear through its history)
  • tasks that need to be "tested" can be querried from the database and displayed for:
    • the project-manager
    • person who submitted the task
    • project team members with profile "tester"
  • Additionally we can change the assignment to the tester, after a developer` fixed the task.

 
 

Comment / Update