Child pages
  • Sakai 10.4-RC01 Testing

Logging In

You must have a valid JIRA Account to create a ticket.


You can create an account by selecting  the Sign Up link underneath the Username login box.

The Dashboard

Once you’re logged in you will be taken to your Dashboard.

         For new users you will see the default Dashboard. This is configurable but that will not be covered by this tutorial.

Started at the left side of the Dashboard users will see a navigation bar with drop down menus for  Dashboards, Projects, Issues and Agile.


We will be focusing on the Issues drop down.

         The drop down menu gives you options to Search for Issues and Create Issues. It will also list out tickets you’ve recently accessed as well as the Filters you most commonly access. You will also see here an option to Manage your filters.


There is also an option right here on the Dashboard to Create an Issue without having to use this drop down. You will find this directly under the Quick Search textbox in the upper right-hand corner.


Selecting this Create Issue option will open up a menu allowing the user to choose the Project and Issue type for the ticket they wish to create. Either option to Create an Issue that is chosen will require a Project and an Issue type. Lets first take a look at the Project options.


When creating an issue it is vital that it is put in the correct Project. There are 11 Sakai Projects, these represent Core Sakai. There are also 65 other projects including over 50 Contrib projects. The Sakai Test Instances you will be working on are running Core Sakai. If you do not see a project for the tool or functionality in which you found an issue please log the issue under the main Sakai project. ( During the issue creation you will be able to select the component in which the issue was seen .)






Now lets take a quick look at the different issue types and what they represent. Taken from Sakai   Confluence

Bug - An error in design or implementation which directly impedes a user from achieving their expected result.

Tag - A new capability being added to Sakai.

Feature Request - A desired capability, for inclusion in a future release of Sakai; ideas that come with resources interested in implementing them are more likely to be developed than those offered with the hope that someone else will step forward to do the work.

Branch - An experimental branch of code, which may or may not be merged back into the main code after the experiment completes; identified in SVN by a branch named with the Jira Key.

Contributed Patch - A community-contributed patch to a particular version of Sakai. The origin of such issues may lie in Bugs or Feature Requests which Sakai has not yet evaluated for implementation. Under such circumstances a linked issue is generally created by cloning the original issue in order to track Sakai's work on the issue. [Use at your own risk!]


For our purposes we will be creating a Bug Issue in the Sakai project (which comes up by default).

Creating an Issue (Ticket)


Before any Issues are created the tester should do a search of current Issues to ensure that they are not creating a duplicate issue.

         If the issue you are creating has an existing issue in JIRA that is Closed you may just need to Re-Open the original issue.

         If the issue you are creating has an existing issue in JIRA that is Open do not open another ticket.


Select the project for the tool or functionality where the issue was seen and then select the Bug option from the Issues drop down.

You will now be redirected to the Create Issue screen. The following fields on this screen need to be filled in. Taken from Sakai   Confluence


         A brief statement summarizing the issue. (Field is limited to < 255 characters.)


The Priority field in Jira is used by Sakai to reflect a combination of issue characteristics, including:

         Number of users affected

         Resources required to resolve

In practice, the Jira Priority field is utilized by Sakai at two times: during prioritization of feature requests/branches/contributed patches for implementation or merging, and when making decisions on what will actually appear in a release. Initial priorities, when an issue is first reported, may be changed to reflect needs as a release moves forward and priorities evolve.


As a release date approaches, priorities will also be adjusted - and lowered, if necessary - to reflect the decreasing availability of time and resources.


Definition for Sakai


Release will not be completed until issue is resolved.


Issue will most likely be resolved for release.


Issue should be resolved for release.


Issue may be resolved for release.


Issues that might be resolved before a release.


         The particular part or parts of Sakai related to the issue.

Affects Version

         Version(s) in which an issue is observed , and should be a released version of Sakai.

         The verson of the code the test instance is running should be displayed in the Footer of the web page (Highlighted).


         For QA participants this is a good place to note on which test server the issue occurred ( e.g. , MIT Stable HSQL, MIT Stable Oracle, MIT Stable MysQL, Nightly)


         A detailed description of the issue, including the steps necessary for reproducing the issue.



         You can also add attachments, including screen shots to help illustrate the issue.


*** These are the fields that are expected to be filled in by QA Testers. Please do not attempt to set a Fix Version , Security Status or Merge Status .


Follow Through

Once the JIRA Issue has been created it will automatically be assigned to the proper Developer or Tool Manager. The tester will be updated to any changes in the ticket via email including the resolution of the ticket.

Once the ticket has been marked Resolved and the 2.8.x Status: has been set to Resolved the fix for the issue will be in the next build where it can be verified.