View Issue Details

IDProjectCategoryView StatusLast Update
0003698mantisbtfeaturepublic2017-01-18 09:58
Reporterdrdoctor Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status newResolutionopen 
Summary0003698: Approval Management
Description

Need for Approval Management:

  • Testing and Approval options
  • Notifications to testers and managers when ready
TagsNo tags attached.
Attached Files
untitled.gif (16,375 bytes)   
untitled.gif (16,375 bytes)   
mantisflow.ppt (28,672 bytes)
mantisflow.png (8,110 bytes)   
mantisflow.png (8,110 bytes)   
Tasks.101.zip (10,038 bytes)

Activities

blaat

blaat

2004-03-29 06:24

reporter   ~0005280

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).

drdoctor

drdoctor

2004-03-29 06:46

reporter   ~0005281

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
that the information is complete, accurate and complies with this process. Confirmation of the resolution can be done by performing an independent test or by reviewing existing information.

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.

blaat

blaat

2004-03-30 08:18

reporter   ~0005290

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.

redcom

redcom

2004-03-30 12:47

reporter   ~0005291

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.

drdoctor

drdoctor

2004-03-31 02:58

reporter   ~0005293

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'...
Observation=Monitoring(?)
Do you want to create different tasks for the developers if a bug is inserted into the Mantis?

blaat

blaat

2004-03-31 04:34

reporter   ~0005301

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:

  1. It is build inline with Functional Specs (but if you really need it we can build it);
  2. It is a duplicate of another observation;
  3. It is nothing so cancel.
  4. Is an incident/bug.

If it is the 1st you and your customer can talk about implementation, costs, etc.
If it is the 2nd you need to wait before the other observation (tasks) is solved to test the outcome of this observation
If it is the 4th the analyser needs to make tasks for the development team (or teams when you are working with different sub teams) and assign the tasks to the teams/members to solve the incident/bug.

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.

drdoctor

drdoctor

2004-04-01 03:27

reporter   ~0005311

Thanks for the detailed description, now it depends on the developers.

blaat

blaat

2004-05-13 17:33

reporter   ~0005498

Last edited: 2004-07-30 02:21

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

mohammed

mohammed

2005-09-21 05:55

reporter   ~0011414

Reminder sent to: mohammed

hi mohammed,

this is a check mail

cas

cas

2010-05-10 05:59

reporter   ~0025446

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?).
Within 1.2 with its plugin system there is another option.A plugin that allows adding additional tasks to other developers within an issue could be a nice feature. It could also be used to assign co-workers to the same issue.
Fields to be used would be:
Initiated by
Date of creation
Due date task (before due-date of issue)
Role (executer or co-worker)
Handler
Request
Response
Complete Y/N
Date completed

cas

cas

2010-05-11 09:10

reporter   ~0025465

Attached a plugin for version 1.2 and above which allows for adding additional tasks to an issue.
Every tasks has :
Handler
Creation date (automatic)
Change date (automatic)
Due date (to be set once)
Finished date (to be set by authorised person)
Title ( 50 characters )
Description ( 150 characters )
Response ( 150 characters )
Once a task has been reported complete, it can only be deleted by authorised staff. Maintenance is no longer possible.
Upon adding a task, the person you assign it to wil receive an email in case plugin is configured to do.
Equally from every change, History records can be created in case plugin is configured to do.