View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003698 | mantisbt | feature | public | 2004-03-29 05:35 | 2017-01-18 09:58 |
Reporter | drdoctor | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | always |
Status | new | Resolution | open | ||
Summary | 0003698: Approval Management | ||||
Description | Need for Approval Management:
| ||||
Tags | No tags attached. | ||||
Attached Files | |||||
To me this sounds as a good extension to the current functionalities of Mantis. But only adding testing and approval option to Mantis is not enough. According to my opinion the above point are related to an 'observation tool' and not specific to a bugtracker and than you will get a complete different life-cycle, like: a.) observe --> b.) analyse --> c.) asign tasks (to developers) --> d.) (developers) perform task --> e.) test the result (by the observer [see a.]) --> f.) close the observation The analyses should then also be added to Mantis Bug 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). |
|
What I'm missing from Mantis ATM that it is not capable the handle Verification, which is the last stage in the life cycle of the bug. The process of verifying includes a review of the resolution information and confirmation of the resolution. The review of the resolution is to ensure See the attached picture for the workflow. It's important that the verification is independent from the developer or the reporter! If these verification activities demonstrate that the SPR has been successfully resolved, the SPR is changed to state Verified and appropriate verification information is added. It would be a configurable option, this feature could be enabled/disabled by a variable. |
|
Added a powerpoint presentation (and image to give an impression) in which I more or less describe the situation of the first note (by me) for this observation. |
|
On our tracker system (we are trying to migrate to mantis) we have policies in place to say that developers can only put bugs into "in test" and only our lab techs are allowed to move a bug from "in test" to "closed", but this is all just policy and there is nothing in our current system that would enforce this. It would be really great if mantis could do something like this. |
|
Redcom - you're right, now in the Mantis this can be done only if you insert a status between resolved and closed: tested or verified and only allow the developer to resolve a bug and give "manager" access (higher level) to lab techs (so they can put the bug into tested status) - but this solution is not really optimal... Blaat - still I don't understand what is the benefit of the proposed 'observation tool'... |
|
Why an observation tool? I think this has more to do with the fact that I look at Mantis from a testers point of view and than even more at the FAT (Functional Acceptance Test) of an application or product which has been build. If you are performing e.g. the FAT Test scripts and something is not inline with the expectation, you can name it a bug or an incident. But these words sound negative, therefore we use the term 'observation' (which is also advised by the ISEB). After we put the observation in the tool it can then (as you see in the flow) be analysed by an analyser (e.g. the writer of the functional specifications) and makes a conclusion. This can e.g. be:
If it is the 1st you and your customer can talk about implementation, costs, etc. Once the developers perform all their tasks and mark them as finished in the tool the observation is then ready for the laboratory testing. If this is then internally accepted the observer (during FAT, thus the customer) can then rerun the test script and accepts the observation, so it can be closed in the tool. Why register tasks in the Tool? As you are already finished with building your product according to you specs and you are now in a new phase. Therefore all tasks for the developers are now registered in the observation tool as the building phase is finished. Furthermore you can make more tasks as the observation is only an observation and no tasks are defined in that. |
|
Thanks for the detailed description, now it depends on the developers. |
|
I was reading another bugreport 0002710 (or observation) and there are also some notes which can be combined with this specific bugreport. Maybe a sort of combination can be made by the developers? edited on: 07-30-04 02:21 |
|
Reminder sent to: mohammed hi mohammed, this is a check mail |
|
This could be achieved by standard Mantis by creating a project for each such request. This would lead to many projects (big problem or not?). |
|
Attached a plugin for version 1.2 and above which allows for adding additional tasks to an issue. |
|