QA How To


Table of Contents

Use the WebDriver Keyword Automated Testing Framework


How to file a bug report...

What is JIRA?

JIRA is a web-based bug and issue tracking system developed by Atlassian Software Systems. Atlassian also develops Confluence, the enterprise Wiki software used by the Sakai Project. Both packages are made available, free of charge, to not for profit organizations and open source projects.
To get started, point your browser to:

http://bugs.sakaiproject.org/jira/

You can browse issues without creating a JIRA account, but you cannot contribute to the community. If you do not yet have a JIRA account, click the 'Sign-up for an account' link above the  'Login' button. Otherwise, enter your user name and password and click 'Log In'.

How do I file a bug report? or How do I open a new JIRA ticket for an issue that I've found?

The first step in creating a new issue is to make sure that that issue doesn't already exist somewhere in JIRA. Redundancy isn't 100% avoidable; duplicate issues do pop up from time to time. It is considered good practice, however, to search through the current issues before submitting to keep issue redundancy to a minimum.

Once you have confirmed that your issue is unique, take the following steps to add your issue to JIRA:

1. Click 'Create New Issue' in the top navigation bar. This link is accessible throughout your JIRA session, but you must log in to see it.

2. Select the appropriate settings for the issue using the 'Project' and 'Issue Type' drop boxes.

NOTE: The majority of the bugs submitted will belong to the 'Sakai' project. This project encompasses all of the tools (provisional or otherwise) that come with Sakai's source code. Contributed tools (Page Order Helper, Site Stats Tool, etc.) have their own projects in the drop box.

3. Fill in a brief description of the issue in the 'Summary' text box. This is what will appear as the issue's title.

4. Select the issue's priority in the 'Priority' drop box. Here is a summary of the different priority severities:

  • Blocker - Blocks development and/or testing work, production could not run without this feature working correctly.
  • Critical - Crashes, loss of data, severe memory leak, need functionality ASAP in production.
  • Major - Major loss of function or need for functionality in production in the near future.
  • Minor - Minor loss of function, problem where easy workaround is present, or functionality which would be nice to have.
  • Trivial - Cosmetic problem like misspelt words or misaligned text, or functionality that it might be nice to have at some point.

5. If appropriate, select the issue's component(s). These are the parts of Sakai that the issue affects. You can select more than one component if necessary.

6. If appropriate, select the version(s) of Sakai that you know are affected by this issue in the 'Affected Version/s' drop box. Your issue may affect several versions of Sakai, but you only have to know one version where it occurs. If your issue affects other versions of Sakai, they will be added later in the tracking process by those that are more familiar with the software.

7. In most cases, you will not know if or when your issue has been fixed. It is acceptable to leave the 'Fix Version/s' drop box set to 'Unknown'.

8. In most cases, an issue is assigned to an individual who is familiar with the components affected by your issue. If you are not sure who should be assigned to your issue, just leave the 'Assign To' drop box set to 'Automatic'.

9. If appropriate, give details about the environment in which the issue occurs. Usually, contributors will give details about their operating system and browser. This is not necessary in all cases, however. Sometimes, the operating system and browser that you were using when the behavior occurred is inconsequential.

10. Write a verbose description for the issue in the 'Description' text box. This should usually include a very detailed analysis of the situation. Giving the developers as much evidence as possible makes it easier for them to fix the problem.
In most cases, you should add a step-by-step process by which a tester can reproduce the issue. Feel free to include error messages or short Java backtraces here, if appropriate.

11. Attach any appropriate text files using the 'Attachment' text box. Examples of appropriate attachments include exceptionally long Java backtraces or excerpts of log files.

12. Click the 'Create' button to add your issue to JIRA.

After You Submit

There are many operations that you can apply to your issue once it is posted. These operations are all located on the left menu of your JIRA ticket:

If at any time you need to change the content of your ticket, click the 'Edit' link.

You can add screenshots to your issue by clicking the 'Attach Screenshot' link.

Make comments on your issue by clicking the 'Comment' link.

I have verified that an issue has been fixed. How should I close the ticket?

Issue verification is the time period in the quality assurance process where rectified issues are tested rigorously by the QA team. After a QA team member tests an issue, he or she can take one of two actions: close the issue (verify as fixed) or reopen the issue (issue has not been fixed).

After you have rigorously tested an issue and verified that it has been fixed, follow this process to close its ticket:

1. Click 'Close' on the issue's ticket page.

2. On the next screen, it is appropriate in most cases to leave the name in the 'Assign To' drop box alone.

3. In the 'Comment' text box, add the circumstances under which you tested the issue as appropriate. In most cases, the tag or revision number and the server name on which you tested is satisfactory. This information can be found in the footer of any Sakai page on the QA servers.

4. Add any supplementary information that you feel is necessary (e.g., if the issue was related to a certain browser, you could add the version(s) for which you tested the issue).

5. In most situations, you shouldn't need to change the 'Viewable By' drop box.

6. Click the 'Close Issue' button to complete the issue closing process.

After testing an issue, I have found that it has not been fixed. How do I reopen a JIRA ticket?

Issue verification is the time period in the quality assurance process where rectified issues are tested rigorously by the QA team. After a QA team member tests an issue, he or she can take one of two actions: close the issue (verify as fixed) or reopen the issue (issue has not been fixed).

After you have rigorously tested an issue and verified that it has not been fixed, follow this process to reopen its ticket:

1. Click 'Reopen' on the issue's ticket page.

2. On the next screen, it is appropriate in most cases to leave the name in the 'Assign To' drop box alone. It should populate automatically with the individual's name who has been assigned to the ticket. If it does not automatically populate with that person's name, leave it as 'Automatic' and it will be assigned to the proper individual.

3. In the 'Comment' text box, add the circumstances under which you tested the issue as appropriate. Be sure to include the tag or revision number and the server on which you tested. This information can be found in the footer of any Sakai page on the QA servers.

Make sure that you fully describe your reason for not verifying the issue. This will help the developers when they take another look at the issue.

4. Click 'Reopen Issue' to complete the issue reopening process.

How do I generate unicode (non-roman) characters?

Here's one easy way to generate unicode characters

1) Go to Google's Language Tools at http://www.google.com/language_tools?hl=en
2) Type "Helo"
3) Select "Translate English to Chinese (Simplified) Beta
4) Cut-n-Past the translated text into Sakai as appropriate

Configurations for testing Sakai.

I don't see a tool listed via Site Setup. How is it possible to add this tool to my site for testing?

Some tools distributed with a release are not enabled by default as they are still considered provisional. To add in tools that have been stealthed, please follow these steps:

  1. log in as admin/admin (or with appropriate pw)
  2. Use Sites tool and search on site id (ie, c0c7d943-e0c7-49e5-8086-7154988740ef)
  3. Click 'Pages' button
  4. Click 'New Page' link
  5. Enter in tool name (ie, 'Roster') in title field and click 'Tools' button
  6. Click 'New tool' link
  7. Choose tool and click 'Save' button

How do I add multiple users for testing purposes

There are three ways many users can be added for testing
1) requesting each user account using the Account tool on the home page
2) > 2) Log in as the admin (admin/sakaigers) and use the users tool on the Administration Workspace.
3) When the server is in demo mode
For any site with demo set to true, which I think is most of the QA
sites, 300 plus student and instructor accounts exist OOTB. All you have
to do is log in, create a course site and attach the available rosters.
Unless you are specifically testing the account creation process or need
a greater number of users than those automatically provided, you don't
have to run selenium scripts to create users and then add them to a
course site. The pre-populated users are already included in one or the
other of the OOTB lecture course rosters ( SMPL101 Winter 2008: Lecture,
SMPL202 Winter 2008: Lecture) that are available as part of the course
creation process. Futhermore, the various rosters, when added to a site,
automatically create sections/groups that you can test with in all of
the group aware tools. Site Info lists the users and which
sections/groups they are enrolled in. Again, you don't need to manually
create users or groups to do testing unless that is the specific
function being tested.

The password for each of these users is

sakai

Some examples of users you can log in with before you ever create a user
or a site:

student0001
student0002
student0010
student0011
etc.

instructor
instructor1