Note: You are currently viewing documentation for Moodle 2.9. Up-to-date documentation for the latest stable version of Moodle may be available here: Tracker.

Tracker: Difference between revisions

From MoodleDocs
No edit summary
Line 1: Line 1:
[[Image:MoodleTracker_logo.JPG]]  
[[Image:MoodleTracker_logo.JPG]]  


Bug tracking is a very important part of a continous quality control process.  Unlike most proprietary software programs, Moodle bug reporting and bug tracking information is open to everyone.  Moodle's bug tracking system  is called '''[http://tracker.moodle.org Tracker]'''.   
Bug tracking is a very important part of a continous quality control process.  Unlike most proprietary software programs, Moodle bug reporting and bug tracking information is open to everyone.  Moodle's bug tracking system  is called '''[http://tracker.moodle.org Tracker]'''.  Tracker is a slightly customised version of Atlassian's product [http://www.atlassian.com/software/jira/ Jira].   


If you're a new Tracker user create a user account [http://tracker.moodle.org here].  It is strongly suggested your Tracker username is the same name you use at Moodle.org.  If your Tracker login account doesn't work, try recovering the password.   
If you're a new Tracker user create a user account [http://tracker.moodle.org here].  It is strongly suggested your Tracker username is the same name you use at Moodle.org.  If your Tracker login account doesn't work, try recovering the password.   
Line 52: Line 52:
==Tracker process for fixing bugs==
==Tracker process for fixing bugs==
*Bugs are assigned by developers or Component Leads.
*Bugs are assigned by developers or Component Leads.
*After a bug has been fixed, that is to say the code has been modified and checked back into CVS, add appropriate comments and update status in Tracker to '''Resolved'''.  To do this use the "Resolve Issue" button. When resolving bugs also indicate what version the change is destined for by selecting the appropriate Moodle version in '''Fix Version/s'''.  The only exception to not moving a bug to Resolved is if a developer believes there is no value in testing the issue, in which case the bug status can be changed to Closed.
*Developers modify or add code and check into CVS.
*Testers test bugs with Status=Resolved.  Global filters have been created based on upcoming releases (eg 1.7 Resolved).   
*Appropriate comments are added in Tracker. The bug's status is changed to '''Resolved''' by using the "Resolve Issue" button.  
*Testers flag that they are the person testing the bug by entering their name in the '''QA Assignee''' field.  It's a good idea to add your name to the watch list for this bug (see "Tracking bugs reported by others", below.)   
*You must indicate the version of Moodle in which the change has been made. Do this by selecting the appropriate Moodle version in '''Fix Version/s'''.   
*If the bug passes testing, close the bug using the "Close Issue" button.  It's important to add appropriate '''comments''' describing your testing methods, any issues that were found, etc.
*The only exception to not moving a bug to Resolved is if a developer believes there is no value in testing the issue, in which case the bug status can be changed to Closed.
*If the bug fails testing or if you feel the fix is incomplete, '''reopen''' the bug using the "Reopen Issue" button.  Ensure the bug is assigned to the correct developer.
 
==Tracker process for testing bugs==
If you are interested in becoming a member of the Moodle Testing team send a request to <tba>.
*Testers test bugs with Status=Resolved.  Global filters have been created based on upcoming releases (eg 1.7 Resolved) to make idendification simple.   
*Use the '''QA Assignee''' field to identify yourself as the tester of a particular bug.  Obviously you should have the skills and knowledge to sufficiently test the issueExperience is important, but doen't forget there are others in the community that may be able to help you. 
*It's a good idea to add your name to the watch list for all bugs you test. (see "Tracking watch list", below.)   
*If the bug passes testing, close the bug using the "Close Issue" button.  You must add appropriate '''comments''' describing your testing methods, any issues that were found, etc.
*If the bug fails testing or if you feel the fix is incomplete, '''reopen''' the bug using the "Reopen Issue" button.  Ensure the bug is assigned to the correct developer.  Work with the developer to find a mutually agreeable resolution to the bug.  
*A release will be deemed ready when all bugs fixed for a particular version have been closed.
*A release will be deemed ready when all bugs fixed for a particular version have been closed.
==More about Tracker functionality==
*The Tracker "Dashboard" is flexible and customisable depending on your area of interest.  For instructions on configuring the Tracker dashboard click  [http://www.atlassian.com/software/jira/docs/v3.6.3/dashboard.html here].
*The Tracker Issue Navigator is used to find and filter bugs.  For instructions on configuring the Issue Navigator click [http://www.atlassian.com/software/jira/docs/v3.6.4/navigatorcolumns.html here].
*Tracker's "Quick Search" capability is explained [http://www.atlassian.com/software/jira/docs/v3.6.4/quicksearch.html here]


== Tracker groups and permissions ==
== Tracker groups and permissions ==
Line 66: Line 78:
'''Testers''' [groupname=moodle-testers] - Testers can do everything a Developer can do.
'''Testers''' [groupname=moodle-testers] - Testers can do everything a Developer can do.


== Priority levels ==
== Tracker priority levels ==


Bugs can be assigned to one of five priority levels. Here is some guidance as to which one to use:
Bugs can be assigned to one of five priority levels. Here is some guidance as to which one to use:
Line 81: Line 93:
:Something is wrong, and should be fixed eventually when someone has the time, but it is not a big deal to live with it.
:Something is wrong, and should be fixed eventually when someone has the time, but it is not a big deal to live with it.


== Versions ==
== Tracker versions ==


There are 2 version fields in Tracker:
There are 2 version fields in Tracker:
Line 93: Line 105:
You will receive email reports of updates to bugs you report.
You will receive email reports of updates to bugs you report.


==Tracking bugs reported by others==
==Tracker watch lists==


You can monitor, or "watch" bugs reported by others.  To do this, open the bug, then select "Watch it" from the left hand navigation panel.
You can monitor, or "watch" bugs reported by others.  To do this, open the bug, then select "Watch it" from the left hand navigation panel.

Revision as of 06:31, 20 September 2006

File:MoodleTracker logo.JPG

Bug tracking is a very important part of a continous quality control process. Unlike most proprietary software programs, Moodle bug reporting and bug tracking information is open to everyone. Moodle's bug tracking system is called Tracker. Tracker is a slightly customised version of Atlassian's product Jira.

If you're a new Tracker user create a user account here. It is strongly suggested your Tracker username is the same name you use at Moodle.org. If your Tracker login account doesn't work, try recovering the password.

"Bugs" not only include software problems with current versions of Moodle, but requests for new features (enhancements), changes in functionality, even constructive criticism of existing features is welcome.

The beauty of open source is that anyone can participate and help to create a better product for all of us to enjoy. In this project, your input is very welcome!

General reporting guidelines

The best bug reports contain these elements in the form:

  1. Steps to reproduce. That is, a detailed sequence of steps a developer can follow to see the problem. It is very hard to fix a bug that is not reproducible. If possible, provide a URL so we can see the problem with one click.
  2. What I expected to happen. Again, provide as much detail as possible. Your expectation might mean that our instructions need to be improved or our interface should be changed.
  3. What actually happened (with detail).

Here is an example of a good bug report in browse view, and here is another.

  • If you have an error message, or information in your PHP or web server logs, copy and paste it into the bug report. If you can, turn on "debug" in your Admin configuration page and reproduce the problem to get the best possible error message.
  • Screen shots are very helpful for some bugs, but please write a textual description of the problem too.
  • Make sure we know everything we need to know about your setup including operating system, database, etc. If you run out of room in the environment section, add more detail in the description. The full set of information that might be relevant is:
    • Server operating system type and version number
    • Web server type and version number
    • PHP version number (and whether you are using an accelerator)
    • Database type and version number
    • Moodle version (there is a dropdown menu on the top of the form, if that does not have what you want, add it in the description)
    • Client-side operating system type and version number
    • Web browser type and version number

You don't need to give all those details all the time. For example, for a layout rendering problem, you need to give only the client-side OS and browser info, and if it is a server-side problem you only need to describe the setup there. Use your judgment. Here are some examples:

I see this bug with the latest Moodle HEAD running on PHP5.1.2/Apache 2.2.3 on Linux. My database is Postgres 8.1.
This rendering problem happens using Internet Explorer 6.0 on Windows XP.

In summary stick with facts and present enough facts so someone else can duplicate the problem.

Report a bug

  • Login to the Tracker
  • Select "Create New Issue" from the menu under the Moodle Tracker logo
  • Step 1, from the dropdown menu select the "Issue type": Bug, New Feature, Task or Improvement
  • Step 2, you will see a series of dropdown and blank content areas
    • Summary: A headline summary of the problem. Try to make it as precise as possible without making it too long. "It doesn't work" is completely useless. Think about keywords people might type into the search box if looking for this issue, and try to include them.
    • Components: Use the Ctrl key with a mouse click to select one or more areas in Moodle. For example, you might have found an issue with a question that impacts: Lesson, Quiz and Question components
    • Select the Version but if it is not listed, put it in the description
    • Environment is for Operating Systems and other stuff. See general guidelines below
    • Description tells what is the issue. See general guidelines below for the best description
    • Database, if it is not listed put it in environment with its version number

Tracker process for fixing bugs

  • Bugs are assigned by developers or Component Leads.
  • Developers modify or add code and check into CVS.
  • Appropriate comments are added in Tracker. The bug's status is changed to Resolved by using the "Resolve Issue" button.
  • You must indicate the version of Moodle in which the change has been made. Do this by selecting the appropriate Moodle version in Fix Version/s.
  • The only exception to not moving a bug to Resolved is if a developer believes there is no value in testing the issue, in which case the bug status can be changed to Closed.

Tracker process for testing bugs

If you are interested in becoming a member of the Moodle Testing team send a request to <tba>.

  • Testers test bugs with Status=Resolved. Global filters have been created based on upcoming releases (eg 1.7 Resolved) to make idendification simple.
  • Use the QA Assignee field to identify yourself as the tester of a particular bug. Obviously you should have the skills and knowledge to sufficiently test the issue. Experience is important, but doen't forget there are others in the community that may be able to help you.
  • It's a good idea to add your name to the watch list for all bugs you test. (see "Tracking watch list", below.)
  • If the bug passes testing, close the bug using the "Close Issue" button. You must add appropriate comments describing your testing methods, any issues that were found, etc.
  • If the bug fails testing or if you feel the fix is incomplete, reopen the bug using the "Reopen Issue" button. Ensure the bug is assigned to the correct developer. Work with the developer to find a mutually agreeable resolution to the bug.
  • A release will be deemed ready when all bugs fixed for a particular version have been closed.

More about Tracker functionality

  • The Tracker "Dashboard" is flexible and customisable depending on your area of interest. For instructions on configuring the Tracker dashboard click here.
  • The Tracker Issue Navigator is used to find and filter bugs. For instructions on configuring the Issue Navigator click here.
  • Tracker's "Quick Search" capability is explained here

Tracker groups and permissions

Standard Users [groupname=jira-user] - This is the default group. New user accounts are placed in this group at the time of creation, and users must be a member of this group in order to log into Tracker. Members of this group can browse bugs, create new bugs, comment on bugs, create attachments, create sub-tasks, create filters, watch bugs, and vote for bugs. Members of this group can also resolve bugs, which is primarily a way of closing bugs that are no longer relevant (eg duplicates, or logged in error). Standard Users can configure their Tracker workspace by using the "Configure your Issue Navigator" button. This feature allows users to view watch and voting lists and to manage preferences, profile, and password.

Developers [groupname=jira-developer] - Developers can do everything Standard Users can do. In addition they can clone bugs, close bugs, edit bugs, link bugs, and assign bugs. Members of this group can also use the Bulk Edit function which allows bulk updated to multiple bugs.

Testers [groupname=moodle-testers] - Testers can do everything a Developer can do.

Tracker priority levels

Bugs can be assigned to one of five priority levels. Here is some guidance as to which one to use:

Blocker
This bug completely breaks Moodle, and the next release must be considered "blocked" until this is done.
Critical
This bug is causing data loss, serious visible errors for uses, or major parts of Moodle to cease to function.
Major
Something is broken and there is no way round it, although it is not a serious as a Critical bug, we can't live with it for long.
Minor
Something is wrong, but it is possible to live with it for a while, maybe because there is a workaround.
Trivial
Something is wrong, and should be fixed eventually when someone has the time, but it is not a big deal to live with it.

Tracker versions

There are 2 version fields in Tracker:

  • Affects version - this is the version in which the bug has been found. It is entered by the person logging the bug, and normally only 1 version is specified.. This information will help developers and testers identify where the problem is occuring.
  • Fix for version - this is the version the bug was or will be fixed in. This field is completed by the developer when the bug has been resolved. Normally only one version is specified in this field. It identifies the first version of Moodle where the change will be seen. For instance, the bug affecting 1.6 and 1.6.1 might be fixed in 1.7.


Tracking progress of bugs you have reported

You will receive email reports of updates to bugs you report.

Tracker watch lists

You can monitor, or "watch" bugs reported by others. To do this, open the bug, then select "Watch it" from the left hand navigation panel. To add others to the watchlist for your bug, open the bug, select the option "Watching" from the left hand navigation panel. These people will receive email notification when updates are made to this bug.

Developer comments

"What’s the hardest thing about a bug report?" Most of the time fixing the problem is the easy part, the hard part is reproducing the bug. The developer needs to see how it is broke to be able to fix it. If they can't reproduce the error you can be sure they won't be able to fix it!

Good bug reports contain as much detail as possible and are specific. Don't generalise or leap to conclusions.

For example, a bug report that only says "The RSS feed doesn’t support UTF-8" is not helpful. The developer knows that UTF-8 and RSS feeds are compatible. The developer has no idea of what the person sees and why they reported this bug. In this case more time and effort needs to be expended to determine the problem.

Consider a bug report which says that the descriptions for the specific RSS feed XYZ@abc shows unrecognisable characters rather than expected characters.

See also