I'm using HP QC to manage defects (just started) and had a question regarding the various defect status types....
We have:
New - new defect
Open - ??
Active - defect is being investigated
Fixed - dev team have issued a fix-need retest
Ready For Test - self explanatory
I know there are other status' but I'm not entirely sure of the meaning of open in particular...
I.e in what instances is a defect open
In a well organized defect management system different (user)roles are defined.
Each step in the process is maintained by a certain role.
Open means that the defects is checked by a senior and can be assigned or picked up by a solver.
For example:
A developer/tester logs a defect -> status becomes new.
The developer/tester can't change the status to open/active or whatever. The defect just sits there waiting.
A testmanager (or defect coordinator/senior tester) checks the defect. (completeness, validity, duplicate etc). When the defect is ok, he changes the status to open. He can also assign a solver.
When a solver starts on working on the defect, he changes the status to active. Everyone can see who is busy working on this defect (investigating or solving).
Solver fixes defect and changes status to fixed.
Testmanager collects all fixed defects and assigns testers to them. Status change to Ready for (re)test.
etc.
Related
I am looking for a smart value for Jira automation, that would auto-assign an issue when its status is changed to DONE to the user, who worked on this issue - a user who moved the issue from sprint backlog and changed the status to Work In Progress.
Any advice would be highly appreciated.
Thanks!
I tried smart value {{initiator.displayName}}
I hoped it would assign the issue once DONE to the user who moved the issue to WIP, but it returned an error after the first test
Assign issue
Error assigning issues
ISSUE NUMBER: (Specified user does not exist or you do not have required permissions)
I do have the permissions as it is not my first automation rule in the given project.
I think you should create new custom field 'Developer' (or any other name you like) and store there a user, who changed the status of the issue to Work In Progress. Once you triggered 'status changed' event to DONE, assign the issue to the user stored in 'Developer' field.
I have the setting to show Red for a blocked task and although many people have a blocked task, only one person is showing red for their blocked tasks.
Please check the following to narrow your issue:
Make sure the rule are set to Task board not Backlog Kanban board.
Make sure you are seeing the same team project.
Check those uses could see blocked tasks created by others.
Try that just set one Rule criteria(Blocked=Yes) without other criteria using some values like #me, #Today,#Current***. Check if others could see those blocked tasks.
In the Task board, make sure the Person setting is chosen to All.
We are using JIRA to work with a team of Developers and a QA team. Currently the 'Dev Team Leader' creates a 'Task' ticket, assigns it to the development member, who work on that ticket and then informs the JIRA ticket number to the QA team, who create a separate QA ticket for testing it. And of the test is pass or failed they inform the DEV team, who either fix it or change the ticket status to 'In Deploy'.
My question is as follows:
Should they create single ticket and use that to do the Development and Testing ? (ie. shift the ticket between the DEV Team and QA Team)
Should the DEV team create a Parent TASK ticket for Development and then assign it to the QA team, who will create a Sub-Task for the Testing and link it to the Parent Development ticket?
Issues:
We need to identify which team member worked on the development
task?
Which team member worked on the Testing ?
How much of tie spent on Development as a whole?
How much of time spent on Testing as a whole?
What is the best way of doing this ?
You only need one ticket or an Issue in JIRA context. Your Project should have a workflow with, for example, the following Statuses: To Do -> In development -> In testing -> from here, the Issue can go in two directions, back to In development if the QA is not satisfied or Done.
When the Issue is moved to the next step, it will/should be assigned to the proper person, i.e. in To Do it's assigned to your project lead or whoever distributes the tasks, In Development it's the developer, In testing the QA, etc.
This is the most widely-accepted way to use JIRA as a ticket tracker. Each transition will be recorded in the Issue Activity Log with the corresponding datetimes, Assignees, etc. You will have access to all the information you've asked for.
It sounds to me like the workflow is in need of granular tracking of development work and testing, where a single ticket (suggested idea) doesn't satisfy.
I found the following design useful:
1. Create a USER STORY that has a set of criteria that needs to be met.
2. Sub TASKS can be created as children of the STORY especially if they need to be worked on by different people.
3. Once all tasks are completed, the USER STORY can be moved to TESTING / IN TESTING (whatever the workflow defines).
4. The QA/QE Engineer then can create TESTS / TEST CASES (children) for the User Stories and and execute them accordingly. Similarly, defects can be filed as BUGS as children of the story.
Ultimately in this workflow the story must meet a set of criteria and level of quality (based on what is acceptable to pass the story for the business) in order to be considered "completed" or ready for release.
In TFS 2015 using the Agile process template, the board for the "Stories" backlog shows only stories, and the board for the current iteration shows all tasks under stories. This makes sense for most teams.
We are breaking down our work into smaller than usual stories and thus avoiding task breakdown, so very few of our stories have tasks. Is there a way to show stories on the current iteration board instead of tasks, so that it looks similar to the higher-level stories board but with only the stories in the iteration?
In the end, I want to avoid a useless board like this:
Have you considered just using the Kanban/Backlog board?
My team don't use tasks at all, all our work is tracked on the Kanban board, we never use the Sprint Board.
Some teams add a "Sprint Backlog" column to show what is planned for the current sprint. Then you can collapse the "New" column until the next planning session.
I'm trying to create a timesheet in Netsuite programmatically through API calls but I get "Timesheet featured is not enabled" error even though I checked possibly all timesheet related checkbox features under Setup-->Company-->Enable feature are checked. Anyone has seen this before?
Thanks.
Process of enabling Timesheets feature
Published 04/22/2014 11:20 AM | Updated 01/29/2015 12:41 PM | Answer Id: 38014
1) Customer requests enabling of Timesheets feature via technical support ('Two Administrators' or an 'Administrator and a Primary contact' or an 'Administrator and a Decision Maker' should sign off in writing that they understood the repercussion of enabling this feature. And they would want this feature to be enabled on their account.)
2) Checkbox for Timesheets is available on Enable features page
3) Customer (Admin) enables the feature
- Notification appears with checking of the box:
4) Customer saves the preferences
5) While migration takes place, Time Tracking box is checked
- It is not possible to change feature setup during migration, following notification pops up if someone tries to do so:
6) When migration is complete
a) Timesheets box is checked
b) E-mail is delivered once migration is successfully complete
Subject: The Timesheet feature has been enabled
Body: The Timesheet feature has been enabled and the system has finished updating your Time Tracking custom fields and time transactions.
- if migration fails, e-mail is also sent, notifying admin about failure
As for the estimated time, it depends on amount of data that are migrated. To give you at least some rough estimate, we are talking about hours here. Small customers can be migrated within hour, larger ones couple of hours. If the process of enabling/disabling the feature takes 2 days or more, please contact NetSuite Support.