Using Jira. (Pr. Jeera')

Using Jira. (pr. JEEra')

Please be aware this document applies to a Jira set up for Project TNT DE and CH v0.1.

It is still in evaluation and therefore it is constantly under review. Please bear with us if you find anomalies, errors or missing features. Even better report them to the Administrators in the bottom left of the screen.

Also there are many features in Jira which still are not being used. If you stumble across one that you think will be particularly useful then again, please let us know.

Although this user document may seem complex the use of the issue tracker is very instuitive. Generally, if you follow your nose you will end up in the right place!

Logging on.

Jira is here:

Setting up your User Preferences.

After login you MUST change your password by clicking on Profile in the top right and then Change Passwords in the Operations Panel on the left.

You can also change if and how you get emails when you make your own changes and the local language.

Go to Edit Preferences in the left hand panel. In this case locale set to None means English!

Update User Preferences

Update your preferences below to control how JIRA works and looks to you.
Number of Issues displayed per page: /
Type of Mail Message sent to you from JIRA: /
Locale: /
Email me when I make changes: /

Now you are ready to go!

The first thing you probably want to do is create a bug and everyone can do that including developers.

Click on Create New Issue top middle of the screen and then press Next as ‘Bug’ and ‘TNT CH and DE‘are defaulted.

You then get the following screen.

Project: / TNT CH and DE v.0.1
Issue Type: / Bug
* Summary: /
* Priority: /
* Cntry where issue seen: / CH
DE
* Env. where issue seen: / Model Office DEV
Model Office Prod
UAT
Training
Migration 1
Migration Prod
Sand Box
Production
* Component/s: /
Work Stream
Old Mstr Ref: /
Old Stream Ref: /
* Affects Version/s: /
Version where issue is seen
Mod Office Version: /
* Assign To: /
Description: /
Old Bug Doc Ref: /
Attachment: /
The maximum file upload size is 5.00 Mb. Please zip files larger than this.
Fix Version/s: /
Version where Issue will be fixed
Original Estimate: /
An estimate of how much work remains until this issue will be resolved.
The format of this is ' *w *d *h *m ' (representing weeks, days, hours and minutes - where * can be any number)
Examples: 4d, 5h 30m, 60m and 3w.

The ‘quirky’ fields that need some explanation are:

-Priority. If you hit the help icon you get a definition of the priorities. Please note that these are generic definitions. Luckily they pretty much match our own definitions but we are trying to figure out how to change them!

-Component. Choosing ‘Unknown’ will assign it to the Project lead for them to assign. Otherwise it will be assigned automatically to the correct development lead.

-Old Master Log Ref. This is the old reference number used in the master log. It is not required for new entries which are created only in Jira.

-Old Master Stream Ref. This is the old reference number used in the Stream log. It is not required for new entries which are created only in Jira.

-Affects Versions: You should know the version you are testing. It can be found easily at :
If you don’t know it then leave it blank.

-Fix Versions: Only the developer will probably know this. You can leave it blank.You will see that there are unreleased versions e.g, “2S, 2T’ in the drop down as well as the ‘Unreleased Choice’. We are still trying to figure out how this feature works so bear with us and for now Don’t choose ‘Unreleased Version’ wherever possible and choose the correct release number.

-Assigned to: The issue is automatically assigned to the appropriate development lead based on the Component selection eg. Finance goes to Manoj.

-Old Bug Doc Ref Name: Only used if the bug has an old document reference that has not been uploaded to Jira.

-Attachment: You can upload docs into Jira which can be viewed by anyone working on the issue.

-Original Estimate: To be completed by the developer.

Pressing ‘Create’ takes you to the next screen where you can see a summary of the bug.

TNT CH and DE v.0.1

rollback

Created: Today 11:43 AM Updated: Today 11:43 AM / Return to search
Component/s: / Configuration
Affects Version/s: / 02Q
Fix Version/s: / 02Q
Original Estimate: / Unknown / Remaining Estimate: / Unknown / Time Spent: / Unknown
Country where issue seen: / CH
Environment where issue seen: / Model Office DEV
Old Master Log Ref: / 234
Old Stream Ref: / 234
Old Bug Doc Ref Name: / wer
Description
ewrwerwer
All / Comments / Work Log / Change History / Sort Order:
There are no comments yet on this issue.

Not shown here but very important is the Issue Reference Number which can be seen at the head of the left panel eg. TNT-14. This is the issues unique identifier in the database and should be used for reference.

You will notice that now the issue is assigned you cannot edit it but you can Comment on it. Only the assignee can modify the issues basic parameters such as Component etc.

The Assignee.

The issue will always have an Assignee who is the person working on the issue at the time. It is usually either the reporter or the developer.

The general rule is that when you perform an action such as Resolve (e.g. for retest) or Reopen the you must assign the issue back to the person you know needs to work on the issue. This can be done easily when you perform one of those actions by selecting the new assignee from the drop down list.

If you chose AUTOMATIC from this drop down list it will be assigned back to the default ‘component leader’.

When you CLOSE an issue as a tester(the reporter usually) then you should NOT reassign the issue.

From here on in it may be worth printing out this attached Workflow Diagram.

It may help you understand the various Issue States in more detail. The table below also explains the definition of each status.

Status Details / Mode / Workflows / Operations
Open
The issue is open and ready for the assignee to start work on it. / Active / jira / Edit
In Progress
This issue is being actively worked on at the moment by the assignee. / Active / jira / Edit
Reopened
This issue was once resolved, but the resolution was deemed incorrect. From here issues are either marked assigned or resolved. / Active / jira / Edit
Resolved
A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed. / Active / jira / Edit
Closed
The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Administering up a Created Issue.

The issues that are due to picked up for a developer in Open status can easily be seen on the Home Page on the right. ‘Open Issues Assigned to Me’.

For a Tester when an issue has been resolved it will be assigned back to you by the developer and you will get an e-mail. You can also check out the Saved Filter on the Upper Part of the Home Page : Resolved Issues Assigned to Me.

As a developer picking up the issue you will see a more comprehensive left hand navigation bar than a tester.

See diagram below.

Issue Details [XML]

Key: / TNT-21
Type: / Bug
Status: / Reopened
Priority: / Major
Assignee: / Mark Badman
Reporter: / Raj Nair
Votes: / 0(View)
Watchers: / 0(View)
Available Workflow Actions

Resolve Issue
Start Progress
Operations

Assign this issue
Attach file to this issue
Attach screenshot to this issue
Clone this issue
Comment on this issue
Edit this issue
Move this issue
Voting:
You have not voted for this issue. Vote for it if you wish it to be fixed
Watching:
You are not watching this issue. Watch it to be notified of changes
Worklog:
Worked on this issue? Log work done
/ TNT CH and DE v.0.1

Mark...this ones for you

Created: Today 12:06 PM Updated: Today 02:10 PM
Component/s: / Policy
Affects Version/s: / 02Q
Fix Version/s: / 02S
Original Estimate: / Unknown / Remaining Estimate: / Unknown / Time Spent: / Unknown
File Attachments:
Manage Attachments / 1. bug_502.doc(131 kb)
Country where issue seen: / CH
Environment where issue seen: / Model Office DEV
Old Mstr Ref: / 32
Old Stream Ref: / 234
Old Bug Doc Ref Name: / 502
Description
bla bla
All / Comments / Work Log / Change History / Sort Order:
Comment by Mark Badman[06/Jan/05 12:47 PM]
[ Permlink ]
Fixed Raj. PLease retest
Comment by Mark Badman[06/Jan/05 12:49 PM]
[ Permlink ]
fixed again please try!

Again most items are self explanatory or not being used at the moment. Here is an explanation of the quirky items again.

The two most important items:

Resolve Issue
Start Progress

Immediately upon starting work on an issue you MUST change the status by hitting ‘Start Progress’. This shows in the reporting status that you are actively working on the issue. That way the reporter and project lead know not to chase you! You can of course have multiple issues In Progress at one time but generally you should have not more than a few open as you only have one pair of hands! Start Progress has NO time tracking behind it. That is done in the work Log.

Resolve issue. This changes the status to resolved and basically means that you want to hand the issue back to the reporter. When you go to Resolved you are asked to enter a Resolution Reason and you MUST also enter a new Assignee (usually the reporter). The reporter is found at the top of the list to make this easier.

The Resolution Reason is one of the following:

Name / Description / Order / Operation
Won't Fix / The problem described is an issue which will never be fixed. / / Edit | Del | Default
Duplicate Issue / The problem is a duplicate of an existing issue. / / Edit | Del | Default
Incomplete Description of Issue / The problem is not completely described. / / Edit | Del | Default
Cannot Reproduce / All attempts at reproducing this issue failed, or not enough information was available to reproduce the issue. Reading the code produces no clues as to why this behavior would occur. If more information appears later, please reopen the issue. / / Edit | Del | Default
Resolved awaiting retest on next normal release / Resolved by developer on TIA dev and is awaiting a retest on its next release or hotfix to GEFI / / Edit | Del | Default
Resolved awaiting retest on hotfix release / Resolved by developer on TIA dev and is awaiting a retest on its next release as a hotfix to GEFI. This will be sent via the GEFI DBA. / / Edit | Del | Default
Closed on next Production release. / This has been tested OK (usually on UAT or Mod Office Dev) and the issue is checked in for the next release to Production. / / Edit | Del | Default

Then you should also enter any comments as needed.

If you forget to re-assign during the actual operation you can re-assign from an option on the left hand panel.

You can of course Resolve an issue whilst it is In Progress.

Edit Issue. This edits the original submissions form. You should only edit the original issue if you know that the Reporters initial information is incomplete or incorrect. Otherwise you should Add a Comment.

Attach screen Shot: As we cannot run active X controls, this unfortunately will not work.

Log Work Done: This is the developers area where you can leave developer type descriptions of what has been done rather than leave them in the more ’functional’ Comment area. This also gives you the chance to add worked time for the issue.

Watching: As an assignee to this issue you do not need to watch it. You will be notified of changes anyway.

FOR HOTFIXES.

For hot fixes a developer should attach the hotfix instructions (in the Work Log) and necessary objects(attach multiple files) as documents to the issue and reassign it using to the Work Bench coordinator. The developer should then ‘Resolve’ Choosing ‘Resolved by hotfix awaiting Work Bench booking through’ from the drop down and reassigning the issue to the Work Bench Coordinator.

The work bench coordinator should then book the item through WB and then resolve the issue using ‘Resolved awaiting retest on hotfix release’ He should then reassign it to the GEFI DBA who will do the hotfix.

THE GEFI DBA can then pick up the hot fix

and apply it. When they are done they should resolve the issue and assign it back to the reporter who will test it.

Issue Linking.

Issue linking enables you to link issues together. You may want to do this for several reasons but the most obvious is that either the issue is an exact duplicate of another issue or that the issue is NOT an exact duplicate but it will be fixed by the same resolution as another bug.

These two scenarios are allowed for using the issue liking feature and both developers and testers can link issues as needed.

Example workflow scenario 1 - The same bug reported twice.

1) You create a new issue in Jira.

2) The developer realises that this is an exact duplicate of another issue they are working on. That is, the same bug has been reported twice.

3) The developerchooses 'Link Issue' in the left hand navigation barand chooses ' duplicates and will be fixed by...'

4) You can link to multiple issues if needed either by Typing TNT-XXX, TNT-YYY with comma separated references, or from the pop up using 'Multiple Issues' option.

5) The developer then should also 'Resolve' the issue using the 'Duplicate' reason. This ensures that the issue is not double counted as Open status.

7) The reporter can then choose if they want to close the bug immediately or if they are not 100% confident that the duplicate issue will fix their issue they can leave it in its current 'duplicate resolved' status and track the closer of the other issues. This is easy to do as they are now linked......

Example workflow scenario2 - Two or more bugs with one resolution.

1) You create a new issue in Jira.

2) The developer realises that this isNOT a duplicate of another issue BUT the fix for one issue they are working on will also fix this issue.

3) They choose 'Link Issue' in the left hand navigation barand choose 'will be fixed by same resolution as...'

4) You can link to multiple issues if needed either by Typing TNT-XXX, TNT-YYY with comma separated references, or from the pop up using 'Multiple Issues' option.

5) The developer then should also 'Resolve' the issue using the 'Duplicate' reason. This ensures that the issue is not double counted as Open status.

6) The reporter will then most likely track the other issue and wait for the fix to be put in place for the linked issues before testing and closing the original issue.

On the flip sideof the two above scenarios if a developer realises that the issue they are actively working on will fix another issue they should:

Choose 'Link Issue' in the left hand navigation bar and choose 'duplicates and will also fix..' or ' will also fix' and then enter the issue that it will fix.

They should also then declare that issue as Resolved with the 'Duplicate' reason.

There is no 'cross-notification' of e-mails sent for linked issues, but you can see the status of the other issue clearly from the original issue and you can also ask to 'watch' that issue if you want.