Currently My workflow with the defect module is fairly simple. I personally see no need in making defect entry and workflow complicated.
5 status values and the developers cannot close a defect is the only rule. There are some workflow around reasons based on status. Only a small number of required fields. There are three rolls BA/QA/Developer. Simple.
So now we are being going to a standard template within the defect module for the company - all teams and projects have to conform.
The flow as gone from simple to complicated. The flow is directed and role based From 5 different values in status to 9. The fields appear based on status and only certain rolls have access to certain things and values.
As the QC admin for the team I am having a hard time keeping up with the 9 different rolls and who can do what.
Question is - How beneficial is it to have the defect directed down the workflow where only certain rolls can update certain things in a certain order? I really think it is designed to treat professionals like children as if they cannot be trusted to pick the right thing. A simple workflow get defects fixed just as much as a complicated painful one. My management only cares about New and open defects during testing cycles. Don't need 9 status values to tell them how many defects have not been closed. Does the directed workflow give any more benefit beyond making sure someone picks the correct status or reason code?
Depends on the needs of the organization. I mean we have some projects that require strict compliance with seperation of duties. SOX compliance or HIPPA compliance can create a "requirement" for possibly more stringent adhearance and realtime documentation of the process flow.
I agree with you in keeping the process minimal. However, that has to be balanced with need of the project. If you have external auditors breathing down your neck, a solid process workflow can be a warm fuzzy secure place to be.
In your case it is better to use groups division. In this case you could create order in which your users (from different groups) could change defect status and you could define data hiding filter (for each group) to prevent visibility of the extra fields.
You could find group settupping in the Tools->Customixation->Groups. There you should create new group and press "change" button.
From security point of view it's better solution than using workflow because, as I know, all described actions takes place on the server side, but workflow actions takes plece on the client side (and there are some ways to turn off workflow at all).
As a QA lead, I am currently redesigning a robust workflow to handle multiple project components. The fields I am choosing to base the workflow off of are fairly simple. However, because of the structure of the organization and dev teams, robust (some might call it complicated) workflow has to be utilized.
Plus, in a larger organization, it cannot be assumed that everyone is familiar with defects reporting, or with Quality Center for that matter.
I believe it is highly beneficial to tie certain roles to certain permissions to change certain fields. It's not designed to treat anyone like children - rather, it is designed to keep the entire organization on the same development lifecycle path. For instance, developers should never be setting priorities on defects/enhancements - the business should to that.
I don't think a simple workflow would work in my case. Anyways, if you want to share any info offline, I work in CT and my e-mail address is firstname.lastname@example.org .
I dont agree with the "children" comment either, but with such a large organisation as I am dealing with having things only affected by certain groups does mean I am answering support queries on items that should be self explanatory if the users took the time to review the simple defect flow chart.
Unfortunetly I don't live in a world where users read the WHOLE email, or document I provide them, just the first sentence [img]/images/graemlins/laugh.gif[/img]
While I have been working for Businesses that are Vendor partners with HP, IBM and Microsoft, my opinions and advice is my own.
The solutions provided are either sourced from my own scripting libraries or from a quick Google Search.